surge 🚀 - Sliders move very slow in VST (VST3 in REAPER also) on Linux (all tested hosts)

The COscillatorDisplay and CLFODisplay has a downsample for the big vector graphic which are those displays. If Cairo through vstgui is lagging that would probably be the first place to look

baconpaul on 4 Sep 2019

Is the slow sliders in VST something only I am experiencing?

mortfell on 5 Sep 2019

I do my basic testing in carla and bitwig and reaper in an ubuntu 18.04 stock VM. VST3 in Reaper in my ubuntu seems fine.

It does seem, though, like the classic mouse mode is a bit more "draggy" on linux than on windows and mac. When I set it to "exact" (in the menu under mouse or some such) though everything feels super responsive. I wonder if there is some scaling factor on linux which is de-amplifying the drag?

baconpaul on 5 Sep 2019

For me on VST3 REAPER they all seem a little laggy.
And i mean this computer is oooold it's an AMD CPU from like 2008 or something, but still
the LV2 Surge is very snappy on this same system. Wonder what I could be.

mortfell on 5 Sep 2019

If redrawing is responsible for the slowness, then can we mitigate it by redrawing after a well-adjusted short delay?
It should be a single tick retriggerable timer which schedules a redrawing to the event loop.
I think, by a strategy like this, you don't pile up redraw calls to be made in very short time frames.
I haven't examine code as of yet, just suggesting an idea.

jpcima on 5 Sep 2019

Yeah we could; but can we profile it to make sure that's the problem first? It's a bit of a pain to do only-every-other-redraw (but not that bad; basically at the top of COscillatorDisplay and CLFOGUI ::draw you put a counter and skip every n of m redraws; but when you skip you have to mark yourself invalid so you get a chance at the next refresh. If this ends up being needed I could add it easily in an #if LINUX block).

baconpaul on 5 Sep 2019

Alright, as backup solution then. So that I get my linux profiling, I think it will go about something like this:

manage an optimized build like release, but containing debug symbols
run it in a minimal host with libprofiler from gperftools (jalv, carla-single), by using the environment LD_PRELOAD
move around one of CLFOGui's sliders for some seconds, and save it

jpcima on 5 Sep 2019

From my experience on mac, a full profiler was basically impossible; I had to use "instruments" (which is their time sampling profiler) to get the thing running and profiled. And I had to profile the release version to get anything useful.

I'm not sure what the linux sampling profiler is. Has dtrace made it to your kernel yet? I am 99% sure that's what the mac stack is built on.

baconpaul on 5 Sep 2019

I'm pretty sure the Linux profiler (well gperftools if it can be called that, I don't know of others)
is based on user space sampling from reconstructing the call trace.
I think the dtrace-like of Linux is SystemTap, I've not used it, nor do I know of potential profiling abilities regarding it.

jpcima on 5 Sep 2019

Ok! My expertise on Linux profiling is a decade or so out of date. Just sharing what worked on Mac!

baconpaul on 5 Sep 2019

It's what I have obtained from the profiling currently.
Nothing of too great use, because I don't have a complete call stack record of it.
I've never had too much luck about extracting significant info off this software. I will retry with debug system libs and check more docs on it.
profile.pdf.gz

jpcima on 5 Sep 2019

A super easy test to eliminate the problem
if COscillatorDisplay::draw and CLFOGui::draw both just return immediately does the problem go away?

baconpaul on 5 Sep 2019

A super easy test to eliminate the problem

That yeah, it does, I did this try in CLFOGui before that I suggested a timer, problem was gone then.

This is the version of the profile just remade, more detailed, after setting up debug cairo.
profile.pdf.gz

jpcima on 5 Sep 2019

OK. We can easily downsample more aggressively in the LFO display. There's already downsample code there.

If here https://github.com/surge-synthesizer/surge/blob/6c8dcd12471a4a13582b666bc8a8e90b68d20c07/src/common/gui/CLFOGui.cpp#L201 you do a #if LINUX averagingwindow *= 4 then it should get immediately faster.

baconpaul on 5 Sep 2019

Confirmed !! At 4 it remains laggy a bit but way better, doubling again then it gets almost flawless.

jpcima on 5 Sep 2019

👍1

OK cool. So basically "linux through vstgui doesn't have the same vector capacity as mac and windows do". Why don't we, for now, put in a #if linux *8 and open a separate issue to do less frequent draws when dragging that we can get to after 1.6.2 ships.

baconpaul on 5 Sep 2019

Is the multipler supposed to go after the following loop? on second look, I assume this would be the case, right? (as I did without thinking, I wrote the statement before)

      while( drawnTime / averagingWindow > 3.0 ) // subsample at longer times
          averagingWindow ++;

At 100% zoom, 4x will be actually perfect there.
At 175% zoom, my screen maximum, any value I put in there, it remains slow. It can be up to 128x where the sine is made to look bad like a triangle-ish, it will draw slow regardless under the scaling.

jpcima on 5 Sep 2019

Oh that's really interesting.

It must be something else in the vector drawing API. With averaging window of 128 it's just a small set of lines! And the fact that it worsens with zoom makes me think vstgui may be doing something quite inefficient internally.

Lets leave this alone for now; maybe there's a better way like doing an offscreen draw. I'll try and take a look next week.

baconpaul on 6 Sep 2019

Or if you want to look: You can see where I construct the vector and do the draw. We can do things like "don't draw the final path at all" and see if that does it (data structure vs render); or draw to an offscreen context; or as you said draw less frequently.

baconpaul on 6 Sep 2019

wow that performance at high zoom is indeed terrible

the zoom doesn't change the number of vector points. Something must be super wrong inside vstgui. I'll see what I can see.

baconpaul on 6 Sep 2019

Not sure I can be of excellent help here regarding the graphics.
I understand what you mean by the structure/render dichotomy so yeah, probably I'll be able to tell if the problem is isolated to the rendering part.

jpcima on 6 Sep 2019

I just did some profiling by hand.

Of the 12ms spent doing a draw in my VM, 11.5 were spent in the drawGraphicsPath routine for the LFO curve.

More concerningly, this time seems to increase with zoom linearly even though the number of points and so on don't.

So I'll have to dig inside vstgui. I think this one will be one I have to find.

baconpaul on 6 Sep 2019

Well yes, I've had this function under my eyes exactly as you mention it.
It's because of noting a particular thing: when I disable #if LINUX special cases of the CLFOGui files, which exist for reasons I don't entirely understand, it then draws at zoom 100% a super blocky sine, but then it's fast. (at the higher zooms, it draws nothing)
I've suspected because it sets a different transform matrix for the path, possibly it's the beginning of a track to find the slowness origin.

In all cases, I get too tired to look at this, so I will sleep :smiley:

jpcima on 6 Sep 2019

Yes that's exactly right

Basically vstgui -> cairo draws in integer space for some reason. So I zoom out 100x then shrink back 100x.

And that seems to be the problem.

All the time is spent in cairo_stroke in vstgui/lib/platform/linux/cairocontext.h

so I need some cairo expertise. What's making the path integral (which is why I do the 100x hack and transform back). That's what I really need to figure out!

baconpaul on 6 Sep 2019

More notes to self

vstgui pixel aligns all paths basically way too early with the call to pixelAlign in the cairopath.cpp inside kLine. If you make pixelAlign just return self then you can at least remove the #ifdef LINUXes

So this is clearly something about vstgui linux cairo implementation not doing the same thing as windows and mac with paths.

baconpaul on 6 Sep 2019

Sigh ok so these would be bigger changes for a release

This weekend I’m going to do one of two things

1: draw every 4 frames on linux or
2: restore the old bitmap code on Linux

@jpcima I’m happy to do this but don’t want to dampen your contribution. So if you want I bet you can’t figure out #1 just as easily as I could.

but #2 would be way easier for me than you.

My theory currently is vstgui mis integralizes so I make too large a virtual drawing area and that explodes resources quadraticalky in Cairo somewhere. But I can’t find a safe fix hence the above approach

baconpaul on 6 Sep 2019

About cairo, and pixel alignment: the pixels are not by default aligned on integer coordinates.
It needs to apply a +(0.5,0.5) offset to land on exact pixels, that's the official recommended way.
So, if it's desired that integer must be on pixels, one could simply apply a global translation +(0.5,0.5) at the beginning of drawing. It's my guess.

Now, I believe I found another item of better interest.
In CLFOGui, when you substitute the draw mode setting with: dc->setDrawMode(VSTGUI::kAntiAliasing|VSTGUI::kNonIntegralMode);

Then, I'm able to obtain normal drawing without the linux hack. But then also, it gets slow back again. So, presence of linux hack or not, this wouldn't seem to be the actual problem.

jpcima on 6 Sep 2019

Both these notes are very useful

Inside cairopath.cpp vstgui is doing this

                    if (alignTm)
                    {
                        auto p = pixelAlign (*alignTm,
                                             CPoint {e.instruction.point.x, e.instruction.point.y});
                        cairo_line_to (handle, p.x - 0.5, p.y - 0.5);
                    }
                    else
                        cairo_line_to (handle, e.instruction.point.x, e.instruction.point.y);
                    break;

so that 0.5 now makes sense but I think the pixelAlign code is incorrect; it is aligning to integers in transform space not pixels in render space. This may be another instance of vstgui picking the wrong transform. (Most of our bug fixes to vstgui were fixing that class of problem).

But it does make me thing something. I wonder if I make a much smaller area with non-integral if it gets faster. The slowdown-with-zoom makes me think there's an in memory drawing asset that scales with transformed pixels somewhere.

baconpaul on 6 Sep 2019

In this case, relevant functions are cairo_user_to_device and cairo_device_to_user, which I met a few times before. It's possible this conversion is wanted back and forth before applying alignment code.
https://www.cairographics.org/manual/cairo-Transformations.html#cairo-user-to-device

As another thing, I tried running cairo perfomance analysis tools, known as libcairo-trace and wrappers of it. It gives me some trouble to hook it in the plugin though, I have managed to get only segfault.

(it's for this kind of debugging, I really enjoy when the synth framework has a standalone program build, which is much less complicated to debug and instrument)

jpcima on 6 Sep 2019

Right. So I think that "fixing this will be pretty far reaching" so I think I propose plan 2 - namely back Linux (and linux only) back down to the 1.6.1.1 drawing code (which made a bitmap, didn't look great in zoom, but was faster).

I've put together a branch which isn't ready for merge quite yet but is ready for you to test if you want. Can you grab baconpaul/restore-bitmap-linux-1103 branch and see if your performance problems go away?

With this branch you'll get the 1.6.1.1 behavior so the LFO display won't do a release, won't have times, etc... but at least it will be usable.

If that works for you I can clean it up and push it this weekend and then we can fix this once we ship 1.6.2.

Sound good?

baconpaul on 6 Sep 2019

Sounds reasonable.
LFO display is showing different in your branch, which I just built.
I confirm it's very much speedier in this version.

In this LFO GUI, the sine is drawn as lower frequency, as opposed to the master branch where many more periods are visible.

jpcima on 6 Sep 2019

Yeah that was the 1.6.1.1 behavior which is why I fixed it - but it won’t be a regression for Linux users just a lack of the better implementation for now

baconpaul on 6 Sep 2019

OK I merged the change for now, backing down the slow-on-linux draw so we can ship 162.
Lets keep this issue open for post release though.

baconpaul on 6 Sep 2019

The performance on my machine is much better now, but the VST2 and VST3 versions are much slower graphically than the LV2 still.

mortfell on 16 Sep 2019

I am observing very slugglish sliders with version 1.6.2.1 linux 64Bit vst (tested in Reaper and Renoise) still. I have an older AMD radeon card.

Interestingly the sliders move very smooth when controlled via midi but not when click-dragging with a mouse.

ivogrig on 31 Mar 2020

@ivogrig if you upgrade to 1.6.6 I think the situation is substantially improved, and there’s a UI menu which sets mouse speeds. 1.6.2.1 is very old!

baconpaul on 31 Mar 2020

I am running 1.6.6, not 1.6.2.1, apologies

ivogrig on 31 Mar 2020

OK! Well what you have is as good as it gets :) Sorry

baconpaul on 31 Mar 2020

but I will take a look when I next fire up linux! Thanks for the report

baconpaul on 31 Mar 2020

Widgets are still really slow especially on higher than 100% zoom levels when adjusted with mouse.
Tested with: 0.NIGHTLY-2020-05-15-3e09ffc
Ubuntu 18.04 LTS and Ubuntu 20.04
Using Xorg with propriatery Nvidia drivers

Tested on: Ardour pre6 and Qtractor.

However I think I managed to track down where the problem might be:
by doing some experimenting with the code I managed to get everything running smooth even at 300%. It seems that in linux the UI widgets are reading mouse crazy fast (could be 1 drag event per moved pixel or 1000hz, didn't test which though).

Throttling mouse drag event handling on slider to 60 Hz fixed the problem. For this purpose even 60 Hz is bit overkill considering surge interpolates state changes nicely I guess.

Regarding to the patch my hack only fixed it for slider widgets as I couldn't find common drag event handler for all widget types. But based on my findings this should not be that hard to fix for anyone being familiar with the code base.

xard-dev on 16 May 2020

Oh cool can you attach the patch which did the throttle here? Just a git diff

Also might explain why I don’t see it - my vm on my Mac will almost definitely delay events to 60hz or below (I only run Linux and windows in a vm for dev not on an actual machine)

baconpaul on 16 May 2020

Just want to add, I recently set up a laptop with some built-in intel graphics chip and installed Ubuntu 19 and the sliders feel super smooth. As described above, on my older Desktop with an ATI Radeon HD6450 the sliders are super slow when dragging by mouse.

I was guessing the graphics card/driver or maybe something about the distro/kernel version might play into it. But I am glad you were able to reproduce it.

ivogrig on 16 May 2020

Useful that me! if @xard-dev shares their patch I’m happy to add it to the few places we need it (mostly just slider tbh but there may be one or two others).

baconpaul on 16 May 2020

Okay,
Here's the patch for the approach I used:
slider_throttle.zip

WARNING: this code blatantly disregards other platforms and does work only for sliders so for example the black step sequence bars need a separate fix unless this approach is applied above in the widget class hierarchy.

Also I have no idea if using high resolution timers like in the patch is a good idea or not but this is proof of concept fix.

xard-dev on 16 May 2020

Also adding that my mouse is running at stable 1000 Hz polling rate confirmed with evhz.

xard-dev on 16 May 2020

Thank you! I’ll try and take a look this week.

Also: your mouse is pooled a 1khz? Wow. Well yeah I bet we drop “some” of those events in the surge UI!

baconpaul on 17 May 2020

Few more comments on this from @tank-trax and I looking this morning

1: it seems worse at high zooms (so maybe a cairo scaling issue?)
2: it seems worse in classic vs exact mode (so may be a vstgui confusing floats and ints in a scaling path?)
3: it is still hard to really replicate on my vm
4: it is fairly widely reported so we do need to fix it for 1.7
5: in classic mode dragging the mouse slowly is smooth; dragging the mouse quickly is not (leading me to think that @xard-dev is exactly right that it is an update-frequency-of-drag issue)

baconpaul on 22 May 2020

Yup that is definitely it

Basically: A fast mouse move is calling mouseMoveDelta every 5us or so. mouseMoveDelta is calling setDirty which is invalidating the rectangle but, unlike mac or win, that forces an immediate repaint as opposed to queuing a repaint at screen time. Therefore the component is "drawing" ever 5us and it takes a while to update (or more accurately, it is doing a lot of graphics work and dropping it on the floor).

Not sure what the solution is, but throttling something back to a screen refresh rate seems to make sense. Exactly what is unclear though, and doing that we have to be careful to not drop the 'last event' or what not.

We could use something like the idle thread, but on linux that doesn't run when the mouse is down because :shrug:.

So harumph. Some real dev work to be done here.

baconpaul on 22 May 2020

My workaround method downsides are quite easy to notice if the throttling is set too low but mouse up should provided "the last say" in all cases. If there are no weird exceptions where the mouse up does not get fired. (for example losing focus before releasing button etc.)

But at 30Hz I can't really notice any problems in regular slider usage and it's WAY better what it currently is.

xard-dev on 22 May 2020

We shouldn't throttle in the component

The problem is in vstgui. in x11frame.cpp when you call invalid it adds a rect to the dirtyRects. It then on a 16ms timer repaints all the dirty rects

So when I drag the timer quickly I get 30 dirtyrects in the redraw cycle. Slooooow

But those dirtyrects are all the same

So I think the fix is vstgui.surge/vstgui/lib/platform/linux/x11.frame.cpp at line 318, before we do the draw to make the dirtyRects unique.

I don't have time to try that now but I do notice that when we are slow on a slider drag, dirtyrects has size ~30-50 and when we are fast it has size ~1-2

baconpaul on 22 May 2020

Are the dirtyRects only performance consideration here because moving the slider also changes other internal values?

xard-dev on 22 May 2020

The internal values should be OK. lets fix the dirtyrects first which are clearly a problem then look at those next.

but if the internal values were a problem it wouldn't worsen with zoom (which quadratically increases draw time and linearly increases mouse event rate)

baconpaul on 22 May 2020

Very good point!

xard-dev on 22 May 2020

OK so

v.patch.txt

checkout master
save that as vstgui.surge/v.patch.txt
cd vstgui.surge
git apply v.patch.txt
cd ..
build

is it better?

baconpaul on 22 May 2020

i have an even better version ready to merge. I'm rather confident in this fix.

baconpaul on 22 May 2020

👍2

That patch is butter smooth at 300%
Nice work! :+1:

xard-dev on 22 May 2020

👍2

Thanks for your efforts guys, I guess I grab the nightly build tomorrow?

ContemporaryInsanity on 22 May 2020

I need to get it merged. Will update this issue when I have.

baconpaul on 22 May 2020

👍1

OK I just pushed this fix to master. It also allowed me to turn on the vector LFO display, although that still seems to have some bugs which I'm sure we can fix. I also shared my vstgui patch with steinberg.

If you build yourself, pull master and test. Otherwise new nightly up in 30 minutes or so.

And if we can get confirm that the problem is solved I'll close this issue.

Best

baconpaul on 22 May 2020

👍1

Oh and if you build yourself, you will need to submodule update after you pull master of surge.

baconpaul on 22 May 2020

New nightly (2020-05-22-a0bf0b9) is up with this fix in place. lemme know if that does it for you.

baconpaul on 22 May 2020

Pulled the changes with submodules and compiled:
Now at 300% the LFO vector display is much sharper and still reasonably fast (not as fast as before understandably but still) at 300% even with rate set to maximum.

I tested:

Sine
Triangle
Square
Sawtoot
Noise
S&H
Envelope

xard-dev on 22 May 2020

👍2

Cool. @tank-trax reports the same on slack, so lemme close this one. We can reopen it or open a new one if we get other performance problems.

baconpaul on 22 May 2020

Hey for those still reading I found another optimization which is needed when we do a full screen refresh (which we do a lot in surge). In that case surge would repaint about 300 too many rectangles.

Built at bf71d398fdd (remember to do a submodule update) and it should be a lot better

GitHub acting funny so not sure if the nightly will run OK but you are all building yourselves anyway right?

baconpaul on 23 May 2020

👍2

Looks like the nightlies are running OK so should be one with that hash which will make things like patch switches and lfo switches even faster

baconpaul on 23 May 2020

I can't see anymore any difference in speed between 200% and 300% while adjusting sliders: it hits 60 fps while before it was slightly (not measured, general estimation only) below that on 300%. Excellent work!

Also now Oscillator is drawn as a vector. :+1:

Only thing still which the zoom level seems to affect is the time it takes to switch between LFO modes (Sine, Triangle, Square, Sawtooth, Noise, S&H, Envelope and Step Seq). The LFO graph updates at reasonable speed on 300% but the time it takes to switch between these modes is around 1 second where as in 150% there's a small delay but it's hard to estimate without measuring it.

Tested with building from: 9eb686ac0113e19fcd074085ca69f7aca3fd8c7c (had to manually fix src/common/gui/SurgeGUIEditor.cpp:5147:30 allocation error to get it compile though)

xard-dev on 23 May 2020

did you submodule update? I did another fix last night for that lfo swap

Also what's the fix you had to apply?

baconpaul on 23 May 2020

Oh I see. Huh how did that sneak through CI? Anyway about to fix it

baconpaul on 23 May 2020

Oh anyway just did a push that (1) fixes that compile error (sorry - I don't know how that got through CI!) and (2) adds a vector step sequencer display

When you update make sure to git submodule update --init --recursive and make sure you are at the right commit in vstgui.surge/ - with that the patch switch should be very fast.

baconpaul on 23 May 2020

okay, it compiles now again from master (thanks for the fast fix):

Built bada868602c31d57c13823eb1cda1a2238f77da4 with submodules a :
0fa4d4847eb6d5bb0f58da889933c94c37ecb730 libs/lv2 (v1.16.0)
41e450bcd5ba1c0419f69664944434b0abf9d7ba libs/midifile (41e450b)
c1f6e209c16b18b46aa9f45d7e619acf42c29726 libs/nanosvg (c1f6e20)
45be1b4da9a6c6d762a1e6ecc2d0ff548e0bd51c libs/tuning-library (Nightly-20-g45be1b4)
10287bc37bbb34324b8097369e2ec4eb73a51d65 vst3sdk (vstsdk3612_03_12_2018_build_67-1-g10287bc)
d483072902b22357ed3e5af7ae73081a5111df39 vstgui.surge (vstgui4_6-1014-gd4830729)

and the LFO type switch at 300% is quite the same as before unfortunately.

xard-dev on 23 May 2020

OK well that's too bad. For some of us that d48 branch improved draw time on lfo switch a lot.

Question: At 300% is surge entirely on your screen? I wonder if being partly offscreen is thwarting my optimization.

baconpaul on 23 May 2020

I'm going to reopen this too even though it is a lot better so we at least to remember to either not give up on what you see or find out what it is and give up consciously :)

baconpaul on 23 May 2020

what LFO switch are you talking about?

tank-trax on 23 May 2020

Yeah, I use 43" 4k monitor so Surge at 300% fits entirely on screen.

xard-dev on 23 May 2020

OK. Well I will give you a patch for some profiling sometime in the next few days to try out OK?

All VSTGUI optimization ... so lets find out what the next slow bit is.

baconpaul on 23 May 2020

If you give me "coordinates" or patches for debug prints and I'll gladly test them and report results :smiley:

xard-dev on 23 May 2020

OK I have a patch and a theory. The patch doesn't improve anything but I want to know what you see

xard.patch.txt

Save that as vstgui.surge/xard.patch.txt
cd vstgui.surge
git apply xard.patch.txt
rebuild and run with terminal attached

now it will tell you how many rectangles redraw and how long it takes

The interesting thing I see when I mouse down and don't mouse up on an LFO button is

I see a log message with around 80 rectangles that says full is false and time is long
Then immediately I see a log message with 352 rectangles that says full is true and time is short

drawHandler: Sizes dirtyRects=1 newDR=1 isFull=0 time=658 us
drawHandler: Sizes dirtyRects=2 newDR=2 isFull=0 time=1072 us
<< THIS IS WHERE I PRESS MOUSE DOWN BUT NOT MOUSE UP AND SEE THESE IMMEDIATELY
drawHandler: Sizes dirtyRects=89 newDR=89 isFull=0 time=40696 us
drawHandler: Sizes dirtyRects=352 newDR=1 isFull=1 time=5736 us
<<< WAIT
<< PRESS MOUSE UP
drawHandler: Sizes dirtyRects=1 newDR=1 isFull=0 time=597 us
drawHandler: Sizes dirtyRects=2 newDR=2 isFull=0 time=970 us

What do you see in the log with that patch applied?

My bet is that 40696us at 300% is a much much bigger number

I want to know what those non-unique rects are of course. I had a hack for a while that said "if rect count > 30 just repaint everything". Depending on what you see I may give you another patch with that (or if you want, where that patch is applied just change the condition

if( fullWindow )

to

if( fullWindow || newDR.size() > 25 )

a few lines above and see if that helps)

Thanks!

baconpaul on 23 May 2020

All these benchmarks will be at 300%.

Pushing down mouse button and on each button press LFO item gets changed eventually without letting the mouse button up. Selected

LFO items for "Acid Seq3" from top to bottom:

drawHandler: Sizes dirtyRects=90 newDR=90 isFull=0 time=964269 us
drawHandler: Sizes dirtyRects=90 newDR=90 isFull=0 time=956222 us
drawHandler: Sizes dirtyRects=90 newDR=90 isFull=0 time=908684 us
drawHandler: Sizes dirtyRects=90 newDR=90 isFull=0 time=905244 us
drawHandler: Sizes dirtyRects=90 newDR=90 isFull=0 time=1040504 us
drawHandler: Sizes dirtyRects=90 newDR=90 isFull=0 time=883975 us
drawHandler: Sizes dirtyRects=90 newDR=90 isFull=0 time=918669 us
drawHandler: Sizes dirtyRects=90 newDR=90 isFull=0 time=917785 us

xard-dev on 23 May 2020

Wow you never get an isfull=1?

baconpaul on 23 May 2020

And yeah that’s a second of stupid overdraws - why not try and force isfull as I mentioned above. Wonder what those rectangles are - that’s where I will look next

baconpaul on 23 May 2020

After patching following statement:

if( isFullRefresh || newDR.size() > 25 )
      {
         // We only want to do one repaint
     newDR.clear();
     newDR.push_back( fullWindow );
      }

drawHandler: Sizes dirtyRects=90 newDR=1 isFull=0 time=30363 us
drawHandler: Sizes dirtyRects=90 newDR=1 isFull=0 time=51449 us
drawHandler: Sizes dirtyRects=90 newDR=1 isFull=0 time=47727 us
drawHandler: Sizes dirtyRects=90 newDR=1 isFull=0 time=46440 us
drawHandler: Sizes dirtyRects=90 newDR=1 isFull=0 time=48707 us
drawHandler: Sizes dirtyRects=90 newDR=1 isFull=0 time=47605 us
drawHandler: Sizes dirtyRects=90 newDR=1 isFull=0 time=45163 us
drawHandler: Sizes dirtyRects=90 newDR=1 isFull=0 time=45139 us
drawHandler: Sizes dirtyRects=90 newDR=1 isFull=0 time=74872 us

It's fast, it's almost instant compared to before. :open_mouth:

xard-dev on 23 May 2020

Also changing patches now is almost instant. Nice side effect indeed!

xard-dev on 23 May 2020

❤2

wow these tweaks. thanks guys for your diligence, for providing these reports, and for testing

tank-trax on 23 May 2020

Right so good now we know the solution - I resisted that deep a hack so lemme see what’s in those 89 rectangles but if I can’t or if I get bored I will apply that count diff to master

(There is a good algorithm for clustering these draws but it is a pain to code so I may just use a hammer with the threshold)

baconpaul on 23 May 2020

Ahh I see. So basically when you mouse down we refresh each of the sliders - that is insanely inefficient in VSTGUI Linux (and only in VSTGUI Linux).

Can you try one more thing for me and let me know, and then I'll put together a patch

reset to master, including vstgui.surge

git fetch origin
git reset origin/master --hard
cd vstgui.surge
git reset origin/surge --hard

or whatever you prefer

in the surge directory save this and apply it

trythis.patch.txt

build and report back if it is also fixed

if so I will do both that change and the precautionary check at 30 rects in the loop also.

Thanks

baconpaul on 23 May 2020

This wasn't supposed to be part of the test I presume:
/home/share/sources/surge/surge-git/src/common/unitconversion.h:55:18: error: ‘%i’ directive writing between 1 and 11 bytes into a region of size 8 [-Werror=format-overflow=]

xard-dev on 23 May 2020

ahh I don't know why those errors pass CI. Hold on.

baconpaul on 23 May 2020

It's almost if the CI system does not have the format-overflow warning enabled and/or does not fail to them.

xard-dev on 23 May 2020

Nah I think it is that CI is running on ubuntu 18 and the compiler isn't as smart

baconpaul on 23 May 2020

Sorry - ubuntu 16! (I should upgrade that!)

baconpaul on 23 May 2020

it's building here on Debian 10

tank-trax on 23 May 2020

Yeah I think ubuntu 20 has the compiler upgrade that supports that error.

Anyway: this is the right change. Let me push it to master along with the fix OK? Doing so now.

baconpaul on 23 May 2020

OK just pushed to master. Can you try master no patches now 24f7676
And if that works close this issue?
Thanks!

baconpaul on 23 May 2020

Note to self: it seems to take around 10 minutes or more for the patches to be available...

Master build 24f767663883661775734e541d3ca95b6634ddf8 with no patches: back to slow update.
Whoops; forgot to pull submodules: testing again.

xard-dev on 23 May 2020

And after I fixed my mistake the build WITH submodules updated commit 24f767663883661775734e541d3ca95b6634ddf8 is fast again. :+1:
(step sequencer seems to have now tooltips for the set values as well)

xard-dev on 23 May 2020

👍1

Yeah wonderful - so I’ll close this

And yes we are doing lots of work on the step sequencer gui right now!! Those tool tips are 3 hours old :)

baconpaul on 23 May 2020

Surge: Sliders move very slow in VST (VST3 in REAPER also) on Linux (all tested hosts)

Most helpful comment

All 96 comments

Related issues