Original post:
@Yeager reported an issue with my PurrSoftware plugin V2.0.32 release to the Library last night. The symptom is that in the module browser in Rack at various zoom settings, sometimes the remainder of the modules on the same row (or perhaps page) as PS and in particular ModeScaleProgressions only render as the panel outline of the modules. Scrolling seems to force a refresh and everything is okay until the next Rack session and the problem shows up again. I have confirmed this in Win11.
Does anyone know what might cause this in the browser. I have seen weird browser render speed issues before but never was able to determine what might cause them. Doing a forum search reveals several browser issues over the years with some speculating that this was perhaps due to FrameBuffer GPU memory issues when scrolling through hundreds of modules in the browser.
Since the problem resolves temporarily by slow scrolling, I don’t think this issue is due to a PurrSoftware plugin bug, but it may be due to the fact that my modules are large panels and render in the browser via PNG files that distribute as resources with my plugin.
Thanks to anyone who has any experience with this or educated speculation.
Since this issue (see previous post for an example) has come up again as reported by a user, I will ask again if anyone has any ideas of how the display of modules might get semi-messed up in the browser? The symptom is that at some magnifications and sort orders, sometimes the modules that should appear to the right of my PurrSoftware modules have blank spaces with the Rack background showing through. Usually a scroll will fix things up and things will be good for that Rack session. The problem sometimes comes back upon the next Rack launch.
Since scrolling will usually fix the problem, it seems that most likely this is a timing issue or perhaps a render buffer resource or timing issue.
The Voxglitch modules have recently been reported doing something similar, but also affecting the view inside Rack.
Both PurrSoftware modules and Voxglitch modules make use of procedural panels with the SVG file just being used to set the panel size and provide a background image. I make use of PNG resource files to draw the module image in the browser. Voxglitch uses jpg and png files for similar purposes (I think).
As reported recently, the Unity module can similarly misbehave if the dark panel is kludged for this deprecated module. The question is whether my modules are misbehaving in dark mode, or something like that, but I see it for light and dark themed PurrSoftware modules in my browser.
My modules are relatively large and I have wondered if that may cause some problem in the browser with render frames or some such by having to take 1-2 rows to display my 3 modules, at some magnifications.
here all your modules as well as Voxglitch ones in both light and dark modes behave fine. Never seen a glitch. I do remember seeing the occasional glitch (not sure anymore which modules) when running Rack under Rosetta, but since switching to the arm64 version all has been buttery smooth and glitch-free here, so not sure what would be causing those.
I’ve hidden both the other plug-ins but Meander in the json file, and I’ve not seen the problem for a long time, so it has to do with something in the other two.
Thanks. I will look back through my new modules’ code and see if I can see anything. Of course it could still be something about the combined panel space of my 3 modules… maybe. I will take a close look at global variables.
In my experiments I find that if I start rack and load a patch and launch the browser at 71% zoom I have to scroll about halfway through the list to find my PurrSoftware modules and if I am going slowly, the 3 modules will be rendered but the remainder on the screen page will not until I scroll the 3 PurrSoftware modules off the top of the screen and then immediately the missing modules render fine. So, I still think this is some type of frame or render buffer issue in the browser.
But, this did not repeat on the next launch. It did repeat on the next launch
if the problem originates with my modules, my suspicion is that the issue is how I render the panel PNG file when in the browser without a module. In my ModuleWidget draw() function, I do a loadImage() each call in order to follow the Rack V2 changes for things like SVG files and font files cannot be cached as the render context is not guaranteed to be persistent. It could be that an loadImage() consumes too much time in the browser or that my 3 modules together consume too much time.
Edit: I only do the loadImage() in the ModuleWidget draw() if the module is null.
Interestingly, this problem is video frame rate sensitive. I usually leave my frame rate at 30 FPS. If I lower it to 10, I do not see the browser problem. If I raise it to 60, I see it more. I do not see it at 20 FPS.
Why can’t you draw procedurally like you do normally, instead of loading pngs?
I do a mix of procedural and svgs, and in one I load a png. That one I do cache the image, and manage invalidating it on context change, which there’s an event for (which had a related Rack fix in 2.41 for forgetting to include the context in the event).
I’m guessing it may be an issue with trying to access large pngs from disk at draw time. Just as a test, try using tiny pngs. If you still have a problem, then it’s not simply the disk access causing the draw to fail completion in one frame.
I switched to using PNGs in March of 2022 as my first revision to my Meander V2 port. It took a lot of trial and error to get this working. If I remember correctly, the main reason I made this change was that I was unable to get a totally procedural panel to work in the browser. There were things that would not render in the browser. So my answer is that I tried very hard to get that to work completely but could not. Of course it took me an equal amount of trial and error to come up with a PNG panel image display in the browser.
pachde:“I do a mix of procedural and svgs, and in one I load a png. That one I do cache the image, and manage invalidating it on context change, which there’s an event for (which had a related Rack fix in 2.41 for forgetting to include the context in the event).”
Can you tell me which of your modules do this and I will look at your source code to see how you do this?
It is still using a hackish workaround (under #ifndef TRUST_RACK_CONTEXT) for the bug in onContextCreate and onContextDestroy that was fixed in Rack 2.4. I plan to remove the hack the next time I update the pachde1 plugin. I left it in for folks that don’t update their Rack very quickly.
My plugin has particular needs for images, including generating an image completely in memory (for the Copper color picker), and keeping access to the image bits when loaded from disk, since Imagine analyses the image data and doesn’t just draw it. Nanovg doesn’t provide any access to the image data once it’s loaded.
The published pachde1 Imagine that uses this class doesn’t load an image for the browser yet, but the code at HEAD in the main branch does (and I haven’t seen any problems).
Not sure that this will help your issue, if it turns out to be just the overhead of disk IO during draw(), but if you can preload and cache it in moduleWidget construction (when no module) before the draw instead of in the draw call itself, it might help.
In any case, it might provide some ideas and options for you. Borrow anything you like.
