knob tooltips

[aombk]

with every new technique, new problems appear.

this is a nice solution but it reintroduces the performance hit when the gui is large. even if i replace mouse moves on with the isInMousePoint ruby method. so i think i will settle with the info area on the gui rather than mouse following tool tips.

thanks

[Nubeat7]

yeah, it seems that the mouse move is not very practical in bigger guis..thats really sad..

[tulamide]

I'm sorry that I don't have the time to go into detail or even present a schematic, but both of your solutions use Ruby code that is highly unoptimized, and probably the reason for the issues when used several dozen of times.

For example, in the draw (!!) code of the knobs (from both, aombk and Nubeat) I found this:

Code: Select all

# Calculate the angle based on the 0-1 current value
   angle = @value*@sweepAngle + @startAngle
   while angle < 0 do angle += 360 end
   while angle > 360 do angle -= 360 end

A while loop to clamp a value! And in the draw method! No calculations belong in the draw method! While loops are the slowest of all loops in Ruby. And there are simpler ways to restrict the angle range (like angle = angle % 360). And that's just one example. Using speed optimized code on the knob will increase the cpu headroom for tooltips by a lot, and is for sure worth the effort.

EDIT: And for the tooltip, you want just one, updating its tip according to the knob its at. The tooltip can reside in its own view and you just move the view with .setViewSize
If it was programmed as I assume then you save all the hassle of redrawing, Flowstone will handle it and hopefully only redraw the view area of the tooltip. But that is just a guess, I didn't try it yet.

[Nubeat7]

yes tulamide, i know i just did take the stock knobs, but i think the problem really lies in the big performance hit the mouse move needs, it also looks like it is depending just on the size of the window..

here i did a pretty well optimized version, all view triggers are reduced to max.25 ticks and also optimized ruby knobs..
you can see that it is working good like it is but if you enlarge the window which contains the knobs and the label and the front panel it starts to be worse, and more with more knobs..

maybe there is more room to optimize a bit, but i'm pretty sure that the mousemove function should be optimized by the FS devs (wasn't there a thread about once?)

on the other hand i still think it is not a good idea to pack 448 knobs on one page because this alone eats loads of cpu also with optimized knobs, FS has not an optimized fast graphics API, you have to live with what it is giving so there will be points you have to decide between userbility and fancy shit..

[tulamide]

Nubeat, I agree to the statement of putting that many knobs on one page. It just is wasting a lot of CPU time.

But, I don't think it is the mouse move tracking per se, that's slowing things down in this situation. It is the fact that you always redraw the whole main view area, and not just the part that really needs updates. That's why it gets slower when you make the view larger.

I know we are all used to the redraw method as is and call it everywhere. But redraw can be called with optional connectorReference and optional redrawArea. That some functionality is also available as a prim "RedrawA". Consequently, in your example schematic (with indeed optimzed knobs!) I would replace the Redraw Prim with an RedrawA Prim in the info label module. It should at least prevent redrawing all knobs on each tooltip move, instead only those affected by the area you call.

[Nubeat7]

Consequently, in your example schematic (with indeed optimzed knobs!) I would replace the Redraw Prim with an RedrawA Prim in the info label module. It should at least prevent redrawing all knobs on each tooltip move, instead only those affected by the area you call.

you are right, the problem is that the whole area needs to be redrawn because the "old label" will stay on the old position if i only redraw the "new label" on its new position...

so the whole area needs to be redrawn to clean up the old position..

the main problem is that it is still not possible to extract view positions (or did i miss this?).. this would make things like this much easier, you just would need to bind the label to the knob position in its parent view..

[tulamide]

No, you would call redraw area with the old area of the tooltip first, then call a redraw in the new area!

There's getViewPos and setViewSize (the latter changes the position as well). getViewPos only available in >3.0.6, but if you track the position in dedicated variables, you should be able to make use of setViewSize to move the tooltip.

[Nubeat7]

There's getViewPos and setViewSize (the latter changes the position as well). getViewPos only available in >3.0.6, but if you track the position in dedicated variables, you should be able to make use of setViewSize to move the tooltip.

yes, i just saw it the get ViewPos is avaliable from 3.07, still on 3.06

and yes the setViewSize works, but i'm not sure if it makes much difference then doing it directly at the mGui primitive..
i'll try to do the redarw with area..

but all this is more or less senseless when you could use the getViewPos methode! anyone who uses 3.07 or higher wants to make a try?

[Nubeat7]

and btw. whats up with the setShowInParent methode?? this was introduced in 3.05 but 3.06 doesn't know it!?
so i cannot use this one too...

[Nubeat7]

ok, in this version only the label component should redraw, but it doesn't change anything, i also further reduced triggers on the label...

you can clearly see if you are over some knobs the scope goes slower if you are in "empty areas" the scope runs smooth