I’m running into serious lag issues with very simple animations, I’m wondering what the best way to structure myself is. I have a simple sequencer component I’ve built, with a timer that repaints itself at 30fps when a user presses play in order to animate the timeline. This alone, with no other components in the plugin causes a HUGE spike in lag, way beyond what I would expect for moving a line across the screen. Clearly it’s hogging the message queue as even my DAW and google docs repaint slowly while it’s animating.
I’m worried that I won’t be able to do much else in terms of animating the gui with this kind of performance. Am I doing something wrong? Is there a much better way to structure this to reduce the lag?
Have a think about how you’re repainting everytime you move the line. If you’re repainting the entire window then that’s a bit overkill for just painting a line. I’d recommend only repainting the bounds that the line is occuping.
Be aware though, that your whole paint() routine will be executed regardless of what you want to paint. Setting a clipping rect will just mute the actual paint calls, but all your loops and clipping in software will run regardless.
(n.b. have a look at the AudioThumbnail implementation, that cleverly loops only over the area the clippingRect is actually showing)
OK so setting a clipping rect might help the FPS? I’ll look at AudioThumbnail. I was thinking maybe i should take the plunge into OpenGL as well but im worried since its a sequencer window with child components representing tracks and sounds its going to be annoying to manage…
Partially. Like I said, the whole paint() routine will be executed.
If half of the paint calls got clipped, that was all in vain. So it is useful to design your loops to start only at the visible borders, like here:
This makes sure the drawChannel is only iterating over visible min/max pairs.
Your whole paint() method will be called, but the number of pixels being drawn to will be reduced if you’re drawing only a portion of the Component, right? Which, depending on the complexity of the drawing, will reduce the drawing time, no?
There is something to be saved. But the bottleneck are not the actual draw calls. The overhead is traversal of your data to call the draw primitives, potential rasterisation like PathFlatteningIterator (all circles, curves, round rectangles etc.) and the clipping. All in software and all happening regardless of the clipped area.
The bit you save is marginal compared to what is definitely executed.
Btw. that is a good argument to use multiple Components instead of putting complex scenes all in one Component.