Opening and showing 2 times the plugin messes up the graphic screen

[frank1119]

When I open and display two instance of ysfx simultaneously the screen gets garbled big time, where it comes to texts. In Reaper you can detach the plugin-interfaces by double-clicking the plugin.

Problem does not occur when the plugin-interfaces are not being shown at the same time.

Might be related to ui-lib.jsfx-inc https://geraintluff.github.io/jsfx-ui-lib

[frank1119]

Some extra info: It is the combination of ysfx and ui-lib.jsfx-inc. It doesn't occur when the default theme is used, but with theme 'tron' or 'black' things gets messed up. It does not occur when the standard Reaper implemention for jsfx is used.

Edit: It seems to concentrate around the font-functions. The themes use these function. Using the default theme and then changing the font-face, font-size, or making it italic. the behavior starts

[jpcima]

It was worked around in cd8b0ca. It impacts the performance negatively however, I'll come up later with a better fix. This issue will stay open for now. Thanks for finding this.

[frank1119]

1. The patch works, so that is very nice. Thank you for that.

2. Performance. I created a little script to count the fps:

   • On my laptop (I7 from 2020), I can open several screens and I measured a steady 30 fps on all of them.
   • The original ReaJS just 22 fps.
   • The same for Reaper < 6.44 inbuilt jsfx
   • Reaper >= 6.44 inbuilt with 'options:gfx_hz=60' 40 fps

   So the performance is not really too bad. At least std::mutex is a critical section and not as great a performance hit as a Win32 Mutex would be (being a kernel object). As a temporary fix it is not the worst thing to do. I will not impact audio processing anyway, because the UI runs on a separate thread. Of course a better fix will result in a better plugin in the end, especially when you are aiming for higher fps.

I can live with this :-).

Do you want me to close this issue or will I leave it open for you to decide when to close it?

[jpcima]

Keep the issue open please. Thanks for your help with the testing :)

Regarding performance: it's doubtful that fps is a significant measure here. The fps is strongly determined by the timer interval which repeatedly invokes @gfx; both jsfx implementations are using the same underlying graphics code. (also from some bits of code seen recently, Reaper might be making a move from software to GL, but that's merely speculation)

The implementation of the mutex is not likely to make any significant difference either.

The element that makes ysfx VST special is that it runs the @gfx in a background thread. The reason is that @gfx code can be blocking for undefinite lengths of time (eg. gfx_showmenu), and hogging the UI thread would freeze the entire DAW. As I've found out, it was either a background thread or modal loop solution, and the latter is extremely discouraged in juce 6 as it creates subtle bugs.

As of now, each plugin editor is having its own background thread, and as we discovered, calling SWELL from these multiple threads is creating problems.

• the current solution is a quite wide-scoped lock that forbids background threads to access SWELL in concurrency
• the preferred one will be to regroup all editors onto one single background thread

[jpcima]

also I never heard about a gfx_hz option before..

[frank1119]

also I never heard about a gfx_hz option before..

Thanks for your explanation, although I must admit that I don’t know what SWELL means (but I will look that up). The gfx_hz option came with 6.44. https://www.reaper.fm/sdk/js/js.php