On the use of hardcoded text widgets vs SVG texts

I generally prefer the idea of using hardcoded text widgets for port names and such, rather than writing the text on the SVG directly and making it a path. It allows more flexibility, at least in an early development stage.
However, I’m wondering about the CPU overhead of this solution. Does anyone has some data? I expect the graphics engine will be more optimized in drawing an SVG path rather than processing my custom code based on nanovg.

1 Like

At this time, Label calls nvgText every frame. SvgPanel on the other hand renders to a FramebufferWidget and is as fast as it’ll get.

1 Like

@leodardo I also find it really hard to work with SVG rather than nanovg but as @Vortico says you have to put things in framebuffers.

For the sets of plugins I wrote, I found myself writing a little widget which is a FramebufferWidget and has a transaparentwidget and a lambda.

This means you can do something like

addChild( new BufferedWidget(pos, size, [](NVGcontext *vg) {
      NvgRegt(vg, 0,0,10,10:
      // etc...

And your code only runs when the UI invalidates. This lets you very easily prototype custom UI components in C++ code and also get minimal repaints.

Hope that helps.

1 Like

Thanks for the answers.
I thought about something like a buffered widget but haven’t had the time to experiment myself. Very cool.

Cool. Well the surge-rack code is all GPL3 (as is the BaconPlugs software where I did the first version of that technique) so if that’s compatible with your license, feel free to just copy it directly into your codebase. If not you can at least look at it and figure out how to do something “similar”.

@Vortico: I’m taking this thread to mean that it’s a bad idea to use a lot of Labels. And “somebody should” write a Label that uses a FrameBufferWidget. yes?

1 Like

The approach I took in BaconMusic was to make a single FB-wrapped widget for my background and then if you add children to that FB-wrapped widget they ride along with the FB-ness.

In surge-rack i didn’t even bother with that and just do everything with draw lambdas. But I wrote surge-rack way more recently.

Sure, that’s great, and it’s great people can take your work and use it. But I’m going to guess that maybe half the VCV devs are like me - into DSP and optimized coding, not really into writing UI code. I tend to use the stock UI widgets 90% the time, and use a lot of Labels. Again, not everyone does that, but I think many do.

Yeah right. I and it is clumsy to always remember to add a frame buffer if you don’t remember. I didn’t at first and always worry I will forget one. It did feel a bit odd having to make that pattern

Maybe if there was a function like addchild which injected the fbw that would be best. Such a function is trivial to write in a plugin but may be hard to position in the codebase. I can imagine the argument that addchild is in widget and widget doesn’t know about framebuffer.

But nothing stopping you from making addbufferedchild in your plugin which takes a widget makes a framebuffer adds the widget to the framebuffer with pos reset to 0 sets the size of the framebuffer size to size and pos to pos then adds the framebuffer instead - which is what it seems you are after.

Having a graphic designer makes the panel workflow easy, but even if you don’t work with one, you can be your own designer by switching to strictly “design mode” for a bit. I believe this design-first approach (and finalize the design before writing your first line of code!) gives fantastic results and is far more efficient than merging the design and implementation processes.
Doing this allows you to bake the text into the panel, which looks better and gives a more polished look with your own choices of fonts, size, etc.

1 Like

I 100% agree with you. And the new version of my modules and the surge rack modules both had this workflow. (With surge rack we had the code ahead of the modules because we were adapting an existing synth).

Just I find emacs is a way easier way to output the nvg commands I want rack to run than Inkscape! I think that’s where the need comes from.