Forum

GUI Refresh (and Sluggish)

RABBLE RABBLE RABBLE!
srsly tho, i agree with what was said here :)

ad vux 1)
thats bugger nr.1 since beta1 and as far as we debugged it it is not in our code. we had a bad half-workaround in place a while ago where we’d simply trigger a repaint-all whenever the mouse entered any iobox. while that kinda reduced the appearance of those buggers it also happened too often and reduced overall performance too much thats why removed it again a while ago. but i think on that end we can still do some more testing and find a better time when to call the redraw… will report to this thread when there is a new alpha to test.

ad vux 2)

  • regarding the in times almost unbearably slow dragging of multiple nodes:
    with b29 we had to update an external/closed-source component (AddFlow) vvvv uses for drawing its patch in order to get everything running on x64. we had a back and forth with the developer who finally confirmed the problem of his new versions much slower drawing but said he’ll not do anything about it. bummer.

what we noticed on some laptops is that drawing speed is improved quite a bit when you set all pc-power-options to maximum (instead of energy-saving). so it seems that the component is waisting quite some cpu-cycles… and while this is not a solution it may help some to reduce annoyances in some situations.

  • regarding ioboxes:

now that is new to me. and i couldn’t attribute that to the components problem because drawing of ioboxes we do ourselves. so can you be a bit more specific (best with a demopatch) of whats going on there? possibly even in a new thread?

also it would be interesting to hear if there is really a difference between b29 and now. because as i mentioned above the big change (which is not in our hands) came with b29. so if you can pinpoint specific UI-degradation since that would be interesting to hear.


and as to why we never came to simply replacing that component shall remain a non-topic for this post but only a hint is given by adding that the chosen adjective “simply” simply is not suitable to describe the kind of such an undertaking specifically if it is not the only thing you want to do.

in short:

  • we should be able to at least improve the situation with ioboxes losing their face
  • we have no way to tackle the problem of overall node-dragging speed without rewriting the whole drawing
  • if there are other issues than those 2 just mentioned it would be very helpful to get specific instructions on how to reproduce the issue and best also name a vvvv version where it was better and now is worse.

Attached simplest patch in the world.

Change value on iobox/double click it, and toggle the toggle value and you can see on the minimum output of the bounds node that drop is rather significant (specially as it’s here a minimum patch, it’s a consequent drop).

Also about slow dragging, I just retested (on b30.2 x86), just dragging the 3 iobox around, minimum fps goes to circa 20-40 fps, in b32.1 can easily go down to 10 fps, so maybe the move to dpi aware also increased that.

Timing.v4p (5.7 kB)

“we debugged it it is not in our code.”
get rid of delphi, trash it, it slows things down

what kind of windows do you use and what kind of OS look and feel do you have? i am on win7 64bit and have disabled all windows GUI fancy stuff, it looks like win 95 but both, 30.2 and 32.1 behave exactly the same for me, the drops go down to about 40 when i drag around the 3 IO boxes.

win 8.1 here, just standard look and feel.

win 8.1, same as vux.

I am not as much annoyed by the drop of framerate (got a few years to get used to that ;) ), but the IOBox issue is just aweful for patching.
also stuff like zdjhnzrg happens way too often now, especially when scrolling a patch.

ahhhhm,

today:
beta32.1_x86 on a fresh and cleaned win7 64bit installation on
a dell dualcore notebook 2Ghz with Nvidia go7900 gs
… like me a quite old machine

a quite simple patch with essentially

video in (ps3eye running 75 fps)
mainloop raw fore- and background set to 150 fps
text (ex9) rendering both framerates.
freeframe colortracker
2 instances of that AIIR i upped yesterday
aaaand
2 iobox value -show slider for monitoring 2 outlets with slicecount= 1

now read carefully:

!!! 1. both Ioboxes visible in GUI
videotexture stable around 75 fps
mainloop somewhere between 20 and 40 fps depending on whats visible in the patch

!!! 2. resized patch window very very small
(searching sth. on desktop :D )
videotexture stable around 75 fps
mainloop immediately hits 150 fps (± 2 frames…raw)

!!! 3. patch scrolled so far that no nodes visible anymore.
videotexture stable around 75 fps
mainloop blends from that 20something fps to 150 fps the less ioboxes are visible.
inverse proportionality in perfection.
it almost felt like dragging the switch inlet of an input morph with the mouse


of course in none of those scenarios any UI interaction happened beyond resizing patchwindow and beyond patchscrolling.
neither selected nodes nor hovered pins.

well i know my chicken…

this behaviour is definitely introduced with b32 or b32.1 (well, i skipped 32 anyway…) and confirmed me 100% in skipping b32.1 also.

b31.2 is wonderful for me although i liked that multiple mice/keyboard thing…

The patching gets harder the bigger the patch… experience the same here.
Also live manipulation issue was for me always a problem - could that not be uncoupled from the main process?

I would like to throw in a rather blasphemic point:
Mr Zauner from the VVVVJS project made a patch editor that is able to read patches that have been made with the regular vvvv.
This editor is actually better then the original one for some reasons (although it lacks some functionality in some other points):

-It is not loosing anything or lagging at any point.
-It is open source - So anyone can redesign it to the own needs
-The lack of right click in the patch have lead to the use of the mouse wheel scroll to change values in a pin - and I adapted to it better then the right click - having always problems to changing back to right click (off topic but wanted to say it)
-shader editor looks actually better or at least equal to the exisiting one -> so could be propably also used for plugins.

As you devs are in the process of testing browser based guis (timeliner) you might consider consulting sagishi.

From what I learned in the last months investigating this, it is possible to render the patch editor not only in browser, but in a standalone application using the everywhere available webkit (or similar name) plugin.

This way it would be possible to patch vvvv on android, ios via network while the program is running on the windows machine.
Would just require some cooperation and interfacing. Propably with the experience from Posh and years of networking not a problem at all.

IMO faster then a rewrite from delphi.

And there is really not a problem with javascript at all (obviously)

for comparison:

http://www.symbioticcube.com/index-SC-PlayerOn.html#edit/patches/SC-PlayerOn.v4p

patchig on adroid mmmmmmmmmmmmmmmmm
this could be wonderfull while working with kinect

in my oppionion…

probably too many contruction sites right now to cope with. not sure if the big big update is just too much and takes too long. i’d prefer a more iterative process like changing the UI first, release it, test it, refine it…and then maybe implement a new language paradigm and all the neat things which have been promised.

i’m totally with u7 here! :)

Yes, +1 u7

+1 u7… no text …

+1 for u7angel

agree, +1 u7

I do not agree, that this is good grounds for a fundamental critique like that.

Please wait for that till the fat lady stopped singing (which should be no earlier than April, no?)

What most of the latest bugs are about is strictly GUI related, it does not really touch any of the other stuff. They were introduced, when the devs took up the challenge of the dpi-awareness, a much-requested user feature.

Now the IOBoxes are way heavier, the gui slower, etc. This is pretty bad, yes, but not grounds for asking the devvvvs to change their basic roadmap.

@devvvvs:
That said, please fix the fking gui! :D

dear velcrome, the emphasis is on “my oppinion” and “i’d prefer”…right? devs will know if this is a valid review or not…and if not, its fine to ignore it ;)

April, will come an alpha, I would guess, and maybe an early alpha at that… Depends how long it takes to fix the gui hehe ;)

@u7
nothing against voicing your opinion. just wanted to say mine when I saw all the +1 ;)