Forum

GUI Refresh (and Sluggish)

vvvv beta bug
#1

Two major ui issues:

1/Refresh is really bad, keeping on losing IoBox content is REALLY irritating, so it’s quite hard to stay concentrated and productive when you lose half of your patch view constantly.

2/UI is badly sluggish, I can understand moving elements on a large patch can slow down a little bit, but having fps dropping to 4 on a patch with 4 nodes is… Same for any patch action (activating toggle, changing iobox value…). It’s been reported quite a while ago, but seems to get worse and worse instead.

#2

This what I “shouted” about recently. I’m insanely happy with the amazing updates over the last few weeks, but vvvv has a couple of fundamental issues that need some attention.

The way I get around the IOBOX issue is by having my patches tabbed, I then have to jump to a different tab before going back to the patch I was working on so that I can see the IO content again.

It’s best described as a brain fart, as I literally have stop my train of thought and start again!

Still love vvvv though, goes to show how awesome it is even with these issues!

#3

can’t agree more with MrVux and MrGriffiths, when I see how many function vvvv has and how many plugin etc… it’s a bit hard to see how bad is the UI.

Bugs are here yes, but also the way we manipulate the nodes could be improved so much… really devs I promise :)

With simple improvement and bugs fix we could patch and code at least twice faster. All the ideas are already in this forum, and some of them for several years.

#4

Yeah, i sadly have to agree on this. UI is (and has been for a while) really in a bad state right now. I’m not using vvvv on a touch device or retina style high-dpi screen so i didn’t benefit from the improvements in those regions, but the overall feel is at an all time low for me. When i first started to pick up vvvv in 2008 it felt supersnappy and i quite enjoyed live patching at vj gigs. Nowadays even slight touches/adjustments to the patch cause massive framerate drops which look really bad in a live performance environment.

#5

I have also noticed this problem https://discourse.vvvv.org/t/11985
Totally agree with Vux

#6

I have to say I’ve never seen the vvvv gui as a live gui, I always make dx interfaces, and have spent countless hours doing so, I’m hoping that I can keep adding to my kontroleur gui, for exactly that reason! The ioboxes are pretty bad at the moment, maybe its win8 which I’m mostly patching in at the moment, I havent tested the latest beta in win7.

#7

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

#8

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.
#9

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)

#10

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

#11

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.

#12

win 8.1 here, just standard look and feel.

Random weird display bug
#13

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.

#14

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…

#15

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

#16

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

#17

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.

#18

i’m totally with u7 here! :)

#19

Yes, +1 u7

#20

+1 u7… no text …

© vvvv group