User-resizable plugin GUIs are all the rage these days - and a big focus of iPlug2 - but I wonder if there are “side effects” most users don’t consider.
I don’t know how iPlug2 GUI resizes bitmaps but I assume it uses some sort of resampling and/or interpolation algorithm(s). The CPU effort required for that may be insignificant for static images - like GUI backgrounds - but what about dynamic elements like meters, spectrum displays, etc., that need to be redrawn CONSTANTLY? What is the CPU “cost” for continuously resizing these multi-frame bitmaps as the plugin is running?
Most users these days want to run lots and LOTS of plugins where every CPU cycle counts. If having a resizable GUI cuts into that ability then they need to be informed. I tend to think fixed size choices from dedicated sets of bitmaps - rather than infinitely variable interpolated/resampled sizes - is a better option. Yes/no?
iPlug2 uses GPU backends (except for SKIA-CPU) where displaying a texture with a different scale is not very expensive. Also bitmaps are not great for scalable UIs anyway.
Vector graphics may be easy to scale on the fly but if you want “photorealistic” GUIs you need to use bitmaps (raster graphics). No way I know of to make smooth shading, gradients, etc., with vector art.
What I would like to do is have 3 fixed sets of bitmaps, e.g., 1x 1.5x, 2x, and then provide a means to select the scale at runtime. I have something that works in iPlug1 but I am missing the step on how to force a complete redraw. Currently it requires closing the plugin window and re-opening to redraw at the new scale.
you could probably do something with IControl::OnRescale() to choose a new bitmap. But this sounds like premature optimization
“Premature optimization”? Not sure what that means. If I can do something at build time that reduces CPU/GPU efforts at runtime then yes, that is optimizing AFAIK.
I know how to redraw individual controls, text, etc., but is there any command that forces a complete redraw of the entire plugin - i.e., the same result as closing then immediately reopening the plugin window?
just do the normal thing first, then if you find it is too slow, do something clever to optimize it
SetAllControlsDirty() will cause all controls to be redrawn. I believe it calls SetDirty(false) for each control, with false specifying that the control’s ActionFunction should not be triggered (which is good here, since action functions themselves might cause redrawing to occur). This isn’t exactly the same as destroying and recreating the UI, but it will cause Draw to be called for all controls, which would allow you to run your mipmap routine during that function.
I think Oli’s right that this optimization may not be necessary, especially with Skia. Before you try to optimize any graphics processing yourself, try using Skia instead of NanoVG. With NanoVG, the GUI was using 20% of the CPU, and after I switched the backend to Skia, that dropped to almost zero.
1 Like