Module browser caching

VCV Rack
1

I asked the following recently but it was either overlooked or ignored.

@Vortico are there plans to incorporate module browser caching into the official release and if so when? Reluctant to move on from the modified 1.1.5 by @diimdeep as the browser full screen on 4K is just too sluggish, my system though not new is not slow, others must suffer with it too. This remains, for me, by far the most irritating thing about VCV.

1 Like
2

I know there were some concerns regarding crashing Rack because of an overflow of the GPU RAM. Check Rack Issue #1474.

1 Like
3

Thanks, just had a look. Don’t really see the issue, they don’t need to be stored in GPU RAM like textures for a game would be.

The version I’m running generates module thumbnails on first browser access, thereafter they’re displayed instantly, if I type filter for instance there is then zero delay in displaying everything tagged with filter. Now I’ve got used to that I find going back almost impossible, I frequently find myself looking for a module but by the time they’ve rendered I’ve forgotten what I was doing, don’t want to go into details but my brain can be awkward like that.

I’ve not looked at the browser source code, not back up to speed enough yet, however it appears that to create module thumbnails the ModuleWidget constructor is called for each module installed (I’ve code that exploits this, if *module is null, to display one of my modules differently in the browser to how it appears when running in the rack), it also appears that the official release does this every time the browser is invoked, whereas the version I’m running does it once only.

1 Like
4

You might want to join the conversation on the GitHub pull request thread instead of here so your voice is heard by the right people. Personally, I also enjoy this modification and cherry-picked it (in addition to a few more patches) to my local repo which is used by me to build Rack for myself. I think you should take a closer look at the browser source code. The official release renders thumbnails at a 60 frame chunk size, i.e. it renders 60 frames, fills the FrameBuffer with them, and once you scroll, it clears out the preview and reloads a new FrameBuffer. The “cache” patch simply disables clearing the preview as you scroll, so the buffers keep on filling with rendered thumbnails. This way you’ll pay the render penalty only when you do scroll first time. Afterwards, the scroll action is done at the FrameBuffer GPU RAM, but it is clear that keep on filling the FrameBuffer RAM unchecked can lead to instability.

1 Like
5

Thanks for the insight, appreciated.

Right, I see it now. I’d suggest rendering thumbnails to disk once on library update, then read back & populate the frame buffer as & when needed, not re-generate every time.

I think I should too, thanks once more.

1 Like
6

Would be nice to have that as an option in settings-v1.json

7

Good news… @Vortico just merged an update that removes the gradual preview clear section in the browser. This is basically the same as the caching patch, just removing all the redundant code. I’m not sure what happened that made him change his mind regarding possible buffer overflows, but this works great and should be available for all in 1.1.7 (or right now if you build Rack yourself)

2 Likes
8

Cloned, built, tested, great. However, back to ten rows when browsing full screen 4K, too small, seven rows was better, I’d prefer six. Picky eh? Awkward eyes.

[5 minutes later]

~/Rack/src/app/ModuleBrowser.cpp line #135

static const float MODEL_BOX_ZOOM = 0.8f;

provides six rows.

Thanks to all involved :slight_smile:

9

The hell are you talking about?

10
11

I see no mention of buffer overflows. Are you confusing this term with running out of GPU RAM?

12

I am… Meant running low on GPU RAM and eventually crash.

1 Like
13

Different screen sizes have an optimal zoom level then there is user preference :roll_eyes:

14

Indeed, would be nice to have it in settings.

2 Likes