Preset hander....

[d.healey]

@christoph-hart said in Preset hander....:

well I would recommend enabling it anyways, it gives you a much better UI performance.

Does this affect performance of the compiled plugin too?

[Lindon]

@christoph-hart

not sure what you mean by this :

The timer is only activated when there is a popup visible, which might explain why you thought it was the preset browser. Should happen with any other popup too (try the beatiful HISE controller on the top right).

-- I closed HISE reopened and reloaded the project - opened every possible pop-up in HISE I could think of, and tried the internal settings (top right ) pop up - they made no difference - the UI worked pretty seamlessly, but as soon as I open the preset browser - we are broken again.

[Christoph Hart]

@d-healey In general, OpenGL is better on Windows and worse on macOS (no idea on Linux, but I think that OpenGL is better there because I suspect Apple to make OpenGL deliberately bad in order to push their Graphics API).

This is true for both HISE and the compiled plugins. But unless you have a really really complex interface, the UI performance of a compiled plugin should not be of great concern. It's just that rendering the plugin AND all of HISE around it might make some systems choke.

[Christoph Hart]

@Lindon Send it over, the doctor needs to see the patient...

[Lindon]

@lindon like Dan I have a timer running every second that refreshes the preset name in the main interface(and resets the icons in my case) - but this has been here since Master branch (causing no problems at all), and I removed it at one point and tried to use the pre and post preset call backs - that made no difference at all...

[Lindon]

@christoph-hart sure can do BUT....
its every patient I have thats not tiny....so to be clear its happening to ALL my major projects...

[Christoph Hart]

@lindon Does it also happen with the one you send me a few weeks ago?

[d.healey]

@christoph-hart said in Preset hander....:

This is true for both HISE and the compiled plugins. But unless you have a really really complex interface, the UI performance of a compiled plugin should not be of great concern

Are you able to recreate the preset browser scroll issue on your system with the example project I posted? That has the simplest UI possible.

[Christoph Hart]

@d-healey Nope, super smooth here. We're talking release build here, yes? Debug lags a little bit, but it's like 15fps, so nothing unexpected.

[Lindon]

@christoph-hart said in Preset hander....:

@lindon Does it also happen with the one you send me a few weeks ago?

yep - tho now when I try the one I sent weeks ago - it wont even load presets....

[Christoph Hart]

@lindon Just tried to load your project:

Interface:! Can't reference local variables in nested function body {SW50ZXJmYWNlfG9uSW5pdCgpfDQzMTQzfDEzNTZ8NTk=}
:			onInit() - Line 1356, column 59	{SW50ZXJmYWNlfG9uSW5pdCgpfDQzMTQzfDEzNTZ8NTk=}

Lol this is Log4j level shit...

[d.healey]

@christoph-hart said in Preset hander....:

@d-healey Nope, super smooth here. We're talking release build here, yes? Debug lags a little bit, but it's like 15fps, so nothing unexpected.

Weird, wonder why it's a problem here... I'll investigate more tomorrow when I'm back.

Did you test with openGL disabled?

[Christoph Hart]

@lindon OK, I'm getting somewhere. If I load your project in the Debug version, I get also a delay of about 8 seconds when clicking on a preset category.

So the possible reasons of failure are:

1. Lindon doing something that he shouldn't.
2. Me implementing something wrong.
3. David breaking the preset browser with his crazy customizations.

The culprit? Applying debug master skills and drumroll...

JUCE::AccessibilityHandler. This was introduced in the last JUCE update and allows accessibility stuff (which we don't use), but it causes a update and reads every single preset file to figure out it's name.

I've pushed a change that deactivates this. This totally solves the lagginess in the PresetBrowser (for me), but I'm not sure whether this affects the other lagginess too.

[Lindon]

@christoph-hart - cool - good work .

I would have put money on option 1 myself....

I will try a new build for the latest commit and let you know...

[Lindon]

@Christoph-Hart --That was black belt ninja grade debugging oh master....

fixed.......everything seems to have sped up nicely, and no more glitching...

(but fingers just a little bit crossed)