So you unfortunately missed the deadline on this module…only joking, how far did you get with the ‘Satanist’ module would love to play around with it, if you need a tester I can have a go and give you feedback on it.
Hi all,
using complex panels is possible, but you need some special handling to get it working. For me it was a lerneng process - I used to have some “used” look (patina) on my panels which looked pretty cool but the big drawback was that all the small details blew up SVGs size resulting in heavy rendering times in Rack. So my first approach was to use bitmaps, but in order to get it look good it had to be oversampled at 4x which unfortunetly resulted in huge file-sizes.
Now I rewrote the SVG rendering logic with an own SvgWidget class which has the ability to draw using a OpenGL frame buffer object like it is used in FramebufferWidget. So you could use really complex graphics; in my new project I have a panel SVG which is about 1.8MB - using this with the traditional method is nearly unusable. Of course this has also some drawbacks, it uses more RAM, but CPU time is much more expensive than memory in that domain.
I created an experimental version of Rack mainly for researching written to run on M1 Mac’s. It uses a new rendering engine which always caches static SVGs in FBOs which gives a big performance boost especially on zooming etc. I also fixed some issues with gradients which were not rendered correctly, but anyway you could look into the code and just use that technique if you want.
Hope that helps gentlemen 
Cheers, Patrick
1 Like
Thanks Patrick! I really appreciate the information. I’m not sure if I have time to dig that deeply into buffering SVGs as raster graphics right now. I only spend a few hours a month working on modules, so have to I pick my battles. My front panel weighs in at 361KB, which is pretty heavy. I intend to run some timing tests. One option is that I could go back to Kirt, who designed the graphics on the panel, and negotiate for something simpler. 
I thought the VCV panel object does buffer the rendered panel in a frame buffer. Is that wrong? I thought that you had at one time made an animated panel, and that was the thing that was using too much CPU.
It does buffer the panels in a frame buffer as long as the zoom level is not changed but I experienced the same behavior before: many small details on a panel make Rack behave sluggish. It is ok as long as you stay on the same zoom level but changing zoom is really no fun.
Ah! yes, that makes sense. And, yeah, making a panel that can’t be zoomed isn’t so hot. Is there a way to “know” you are being zoomed so you could render low-fi until the zooming stops?
The actual zoom level doesn’t matter, SVGs being vector graphics are always re-rendered into a frame buffer after the zoom level has changed, Rack v1 is not very smart in rendering the module panels.
FramebufferWidget::dirty is used whenever the frame buffer needs to be rendered again.