The problem Link to heading
I was recently working on a group-project as part of my degree where we had to make a program to display various bits of data relating to satellites in space. As part of this, we decided to display the associated nation of each satellite, of which there are many, with a little flag beside it.
Example of flag display
We were coding this with Processing, an offshoot of java with it’s own IDE and various functions to make the development of interactive software easier.
Your first instinct might be to use an array of PImages and draw them with the image() function, but upon trying that, you’ll realise that it greatly increases the time it takes to render all of those flags, resulting in noticeable delays.
But why? Link to heading
Luckily, Processing is open-source, so figuring out the problem might not be difficult: let’s take a quick trip to the github and look around the source code for PImage and image().
Nothing about the image() loading code immediately reveals an easy solution. All the image() functions just do a relatively small bit of math to figure out the arguments to use to call imageimpl(). That function then goes and sets some internal texture image to the PImage you want to draw, defines four vertices (the corners of the image) and uses the beginShape and endShape functions to write everything into the image buffer.
Some research online shows that there is possibly some overhead with decoding different image file formats, and reading the source code of image shows that the specific image() call I was using (one that takes in a section of a larger atlas to draw from, and an area of the screen to draw to), also has a fair bit of calculating involved before imageimpl() is called. So I decided to try eliminate both those factors as a starting point.
My solution Link to heading
Processing’s main graphics and rendering context is the PGraphics class, but you can also instantiate more objects of that class and draw to them using the exact same functions you use to draw to the regular context.
By rendering each flag to an offscreen context in advance, and drawing that offscreen context using the basic image(PImage, int x, int y, int w, int h) function, I can avoid some extra calculations and associated overhead, and also avoid any potential overhead to do with decoding PImage file formats.
This would increase the starting time, but we already had a loading screen implemented, and decided that it was better to minorly increase starting time in exchange for increasing overall performance.
Our big texture atlas was square and ordered such that it was easy to populate a hashmap of PGraphics to String keys. Each PGraphic gets it’s own flag rendered to it’s graphical context on program startup once, and from there you can draw it to the screen anytime.
Results Link to heading
The change was a success, the new flag-drawing functionality no longer had the stuttering and stops that the old one did. Processing makes exact profiling tricky, but I was able to compare the performance by running 3 versions of the code. One without any flag drawing, one with the old flag drawing, and one with the new. The one with the new was identical in performance to the one without any flag drawing, with the exception of slightly longer load times. The one with the old had a lot of extra stuttering and slowdowns.
Overall, it was an interesting problem to end up solving, and I gained valuable information should I ever use processing to do something similar in the future.