setBufferedToImage on components not (yet) appearing


I'm trying to optimize the scrolling of my DAW tracks by having a thread repaint their loops with setBufferedToImage(true). Unfortunately, it seems to only work for the components (loops) visible, so it defeats the whole purpose. 

My components are fully opaque. Is there a simple way of "forcing" them to repaint (and therefore create the cache image) or do I need to create my component image on my own and assign it with setCachedComponentImage?

Thanks for any hint on this.


I think if you were going to do that kind of thing, you'd need a special class of cached image that renders beyond the edges.. But making it work with threads sounds like a nightmare, all that stuff was written only to run on the message thread!

Ok, thanks for confirming the current behaviour. But then would creating the image on my own and assigning it with setCachedComponentImage be a possible alternative? Or would I be facing a similar problem?

Don't know, depends exactly what you're caching. But threading like that will always be tricky.

with a bunch of images typically 4 times the width of my paint area. Whenever i scroll the daw track I check (in my paint function) if any of the image cache images covers the area. If it does, I use it with g.drawImage(image, xPos, yPos, width, height...). If not I paint the usual way.

The image cache is held fresh with a Timeslicethread whose usetimeslice() constantly checks the track position. If it discovers the image cache is *beginning* to run dry, it creates a new Image like image = slice->createComponentSnapshot(Rectangle<int>(xPos, 0, 4 * vpWidth, slice->getHeight()), false);

I had some occasional hickups deep down in the the paint undergrowth, but that was cured with a ScopedLock preventing the normal paint thread Timeslicethread accessing my paint function simultaneously.

Before, my daw had to redraw every (visible) track whener I scrolled even a single pixel (if I didn't use any native scroll functions, which I got tired of for other reasons). Now it just splats part of an image to the screen. Much faster...


Thanks for the feedback. Your idea is good, but I prefer a little more granularity. I intend to use the default viewport mechanism that works fine for me, but instead of painting the loops details (that includes drawing the audio signal, text, etc...) I want to replace it by a pre-computed image. This should hopefully save a little CPU on scrolling.

I already have a working thread that crunches down the audio/MIDI signals to be displayed for each loop at the given zoom value and then repaints it (using MessageManagerLock) and that works great. I just want to push it a step more with this cache image. Of course, when the loop is selected, we can switch back to normal repainting. 

I'll try to use the setCachedComponentImage functionality, but if that doesn't work I may simply add an image to my loop class and toggle between that and normal display.