Efficient Drawing

Started a new post here so avoid hijacking my other post :wink: reply to @k-chaffin

I am far from an expert at NVG drawing, VCV widgets, etc… I’ll tell you what little I know.

There is one “hammer” that VCV uses to make drawing efficient, and that is FrameBufferWidget. Almost every widget in VCV uses this. What it does is keep a bitmap representation of a widget, and when it needs to draw the bitmap is used. When the widget needs to update its appearance, it sets FrameBufferWidget::dirty to true, causing the “real” drawing code to get called.

Almost every widget in the VCV SDK uses FrameBufferWidget. A classic use is for the panel itself. These often have complex SVG, and the buffering make the use of complex graphics almost free (if they are static).

So for my widget that displays a score I used FrameBufferWidget. I’ve only used it once before, for the waveform selector in EV-3. That uses a bunch of SVG for the pictures of waveforms, and seemed to be causing a problem.

Several times I’ve made widets and not worried about it. I’m not super interested in drawing performance, and don’t tend to do anything about it unless there’s an issue. Also, I have found it to be slightly tricky using FrameBufferWidget - it takes me like an hour of hacking around to get it working. Maybe if I did it more I’d get better at it.

In the case of the score display in Harmony I made an exception to this rule. It just “felt” like something that might be heavy. The notes, in particular, are all vector fonts, so it seemed heavy. Very un-scientific.

The good thing about FrameBufferWdiget is that if you fall info the sweet spot it’s super effective and not that difficult to use. For me the sweet spot is:

  • Existing thing is already a widget.
  • Existing widget is a pig.
  • More often than not the visual doesn’t have to change.

In the case of a super complex UI like Meander - I don’t know. It could be complex, or if you are lucky there is just a small amount of stuff that could benefit from re-coding.