Thanks Paul. I will dig into it.
Hey Paul. I found your code. What is your opinion as to whether I could grab loadImage() in the ModuleWidget constructor only if the module is null and then use this cached pointer in the ModuleWidget::draw() function only if the module is null, and not worry about the context possibly changing? Is that what you were suggesting above?
No, still need to invalidate the cached loaded image whenever the context changes that you expect to draw that image in.
Thereās an issue though with what I wrote working from memory: You arenāt given a nvgContext on module widget construction ā only draw. I donāt know if the browser uses the same context as the main window (APP->window->vg). If it does, then you can use the same hack and grab the context from there. You may get a new one each time the browser is opened (I havenāt checked). I think youāll get a new one at least whenever the zoom level changes. The browser has its own zoom level separate from the app, which might imply a different context.
What you can do in the absence of the nvgContext at construction time is to pre-load the raw image data from the file and use nvgCreateImageRGBA to add the image to the vg context. This will isolate the file I/O from draw.
To load raw image data:
#include "stb_image.h"
...
_data = stbi_load(_path.c_str(), &_width, &_height, &_components, 4);
Before doing all that, first thing to check is if it is actually the image file I/O that is causing the problem (by using tiny images, just for diagnosis).
1 Like
Well, that is not trivial. I did it, but by only changing the PNG file size, the browser tiled the panel with a bunch of the smaller textures. That probably once again has to do with how I render the panel in the browser. I will look at it more tomorrow.
Thatās all I meant - a quick and easy way to minimize the file I/O (which is one of the slowest things you can do in a plugin).
Did that help with the issue?
It is inconclusive. I probably need to do the same for my other two modules. The problem is that the problem is not always repeatable.
Well, I have definitive news, but Iām not sure if it is good, bad or neutral news. The stalling of the browser when all 3 of my modules are in the current render frame at higher FPS settings is not due to the PNG panel image loading and rendering. I modified my modules to be able to enable and disable this entire piece of code and the stalling still occurs in exactly the same way.
Here is a screen grab of the test. As you can see, the PNG images are not being rendered and I get the expected panels with only ports and knobs, which is expected. Those actually render in addition to my PNG images normally and I have to be careful when I am capturing the panel PNG images to make sure the knobs and ports are aligned or I have some doubling artifacts.
So, what is the source of the current browser stalling? I do not know yet. It seems to be something to do with the browser graphics frame buffer render and what all must render in a given frame. As mentioned, the problem seems most likely to occur when all 3 of my modules are in the current frame to render and is sensitive to panel sizes, sort order, zoom, FPS setting, etc. In my tests, I can always scroll the browser down and once my 3 modules are not on the screen, the browser will un-stall and render subsequent modules correctly. If I scroll back to have my 3 modules on the screen, everything still works okay. This is an important workaround for anyone who encounters this issue.
I will continuing trying to understand this issue. If anyone has any ideas of what might be happening here, I welcome the input.
2 Likes
And my previous statement that it does not show itself when hiding 2 of the three modules is also not true
But while I was typing and pasting this very slowly more Vult modules became visibleā¦ 
1 Like
Meander does take a long time to draw. I notice if I insert a copy into a patch that if I zoom in so that Meander fills the screen that the frame rate in the upper right goes down a bit. I wonder if itās modules that take more than a frame to draw. I also wonder if it does take a long time or if Iām mistaken.
I remember my EV3 used to take a long time to draw. Turned out to be all the SVG I was drawing for waveform switches. Used the transparent buffer and that went away. But, again, may have nothing to do with the problem in the browser.
2 Likes
Well, being procedurally generated, I think they will take longer to draw in the Rack window, but, that should not affect the browser where the procedural generation does not occur. I can imagine it being something related to panel size. But, who knows at this point. The more ideas the better.
Just testing on a complex patch with Meander in it. The FPS is all over the place and varies dramatically with zoom. Just changing the zoom causes a drop in frame rate for a second or two and then it returns to a higher rate.
yeah, I notice that the two second drop happens with all modules. Probably all the transparent buffer widgets forcing re-draws on a zoom. But I think with āwell behavedā modules the fps goes back to normal and doesnāt go all over the place?
Itās a complex system. The Rack frame rate drops by about 1/2 when the browser window is open
When I said all over the place, I meant all over the place while zoom is being changed. Otherwise the frame rate stays fairly constatnt.
ok. when it settles down is it back up where it would be for an empty patch? On my system itās 60hz - donāt know if thatās a rack default or if itās based on your monitorā¦
1 Like
What frame rate are you running Rack at?
I run two monitors, a 24" HD at 60Hz and a 40" 4K which will only do 30Hz. Rack defaults to 60, Iāve set it to 30 as I almost always run it full screen 4K. The problem manifests on either screen at either frame rate here (linux).
1 Like
60Hz
1 Like
So,the frame rate is set in the Rack View menu. When I set it to 60Hz, for my 2 monitor system, the Rack window with an empty patch is showing 40-50 FPS. I normally run at 30 Hz though. My complex patch is showing 49-55 FPS. Zoom drops it down to 27 FPS and when I stop changing zoom, it fairly quickly returns to ā¦ 56 FPS.
If you change it to a lower number, does the browser still stall?