redraw behaviour

[stw]

I stumbled over a strange redraw behaviour while testing my actual plugin.
Maybe someone can verify that on his system or maybe better give an explanation on what's going on here?

The fsm contains a gui with some bitmaps. These are redrawn with a simple bool input.
The strange thing is if the bool is changed by a bool prim the redraw is done at once without any noticeable delay.
If the bool is changed by a selector the redraw occurs visibly with some delay from top to down.
Even more irritating is if the same selector is triggered externally from a bool prim the delay is gone.
So my guess is that the mouse capture has some influence on how a redraw is done (BTW it doesn't matter if the mouse capturing happens in ruby or with FS prims). I think that shouldn't happen and consider it as a bug.
Any opinions?

redraw test.fsm

(33.66 KiB) Downloaded 785 times

[tester]

Confirmed.

But if you click on switches, then during the gui change - there is also second interaction going on, related to mouse event. Have you tried to use an old SM switch (not on ruby), and played with redraw area / redraw prim inside it?

My guess is, that in prim case and in switch case - different redraw method is in the game (however I don't know yet why; ruby related). Prim = redraw whole, switch = redraw area one by one. I had similar cases in SM, when I used multiple leds; I had add the "redraw area" to global panel instead of single leds.

[Nubeat7]

i recognized that there is the same delay in both situations, you can see that when turn trun off & on again very fast, it needs the same time to show all again, i think the difference is using a gui element like a switch is the normal behaviour like it would act as vst or standalone in realworld, while switching directly on the primitive a FS refresh is triggered..

it is like when you forgot some redraw prims the redraw happens when you click somewhere in the FS window but it wont do that when using the app in the real world

[tester]

So just make one green redraw (last wire to trigger) routine for the whole area that contains sub-guis instead of using redraw within singluar ruby modules. Let me know if this works.

[Nubeat7]

here is a simple schematic which explains this, it is just a filled rectangle with a multiplexer to show it or not , but i "forgot" the redraw primitive

so when using a gui element it doesnt do the redraw but clicking after the guielement action somewhere in the schematic, it does! because fs refreshes the schematic, i think.

using a boolean primitive it does the "refresh" properly..

[RJHollins]

yes ... this is a strange action, and one that I've been caught by.

Since both the LED and the BOOLEAN send a 'trigger' into the module, something else must be going on here.

Just as strange ... wiring the LED out to the Boolean IN and sending that to the module still does not kick a re-draw.

It must have something to do within FS and the way any mouse function has to operate ... but the schematic has its' own signal flow.

I also remember reading about triggers and the use of 'selector' and 'multiplexer' PRIMS. Seems they need special attention to work as 'assumed'

[Nubeat7]

It must have something to do within FS and the way any mouse function has to operate ... but the schematic has its' own signal flow.

it just have to do if you use a gui controller or a primitive, if using a gui element things act like in real world if you use a primitive (which you cannot use in the realworld) you are acting on the FS surface which refreshes your schematic and all parameters..

you could see it in layers, primitives are on the developing ground and gui controls are above so when you touch a gui cntrl the developing ground isnt touched it just sends its values, but when touching something on the developing ground everything gets refreshed and updated also when just click on the empty ground

[stw]

it is like when you forgot some redraw prims the redraw happens when you click somewhere in the FS window but it wont do that when using the app in the real world

You're right with your assumptions but that's not the issue here.
The point is there's a triggered redraw on a defined area. It shouldn't matter where or how the trigger was initiated as long as there're no corresponding triggers or calculations anywhere else.
The actual redrawing should be always the same. However the triggering (by bool prim) definitely is faster than the triggering by any other source. This becomes obvious if you test it on a slower CPU.
The new example fsm proofs my first idea of a mouse capture relationship wrong. If you activate the ticked toggle you see the same behaviour as with the switch.
I don't see any reason for different treatment of a redraw and i guess that the bool triggering actually shows how fast a redraw could be done.

redraw test2.fsm

(10.81 KiB) Downloaded 820 times

[Xtinct]

Adding a dethreader to the switch changes its graphics instantly (no waiting for the rest to show first) but still a lag on the rest