Comparative speed in switching among groups

[Alex Tweedly]

On 27/11/2023 00:02, ambassador--- via use-livecode wrote:
> An excuse to benchmark?  Sure, I'll bite. :)
>
:=).  Beat me to it.
> But boy oh boy was I surprised by the difference.
> Bottom line, in millisecs for just 5 iterations on an M1 Mac:
>
> Groups: 141
> Cards: 13619

Wow!


> I suspect most layouts won't encounter this much of a difference. After all, I did choose the elements I could put together quickly with rendering impairment in mind.

But there is another consideration. When (if) you resize the stack, the 
'group' version will need to resize each of the groups (even when they 
are hidden), and if the number of different groups is non-trivial, that 
might make resizing slow.

I took Richard's test stack and resized each of the the text fields  to 
approx 1/3 of the stack width - and that was already painfully slow with 
two groups. So if you aim to have a large number of groups, you may be 
forced to overcome this yourself.

You can do something like

on resizecontrol
    if the visible of me then
       .....
    end if
end resizecontrol

and be sure to add a

    send "resizecontrol" grp tGroup

immediately after you make group 'tGroup' visible again.

> But I suspect the difference would still show itself in lighter layouts.
>
> And now I'm curious: what are you working on where layout transition speed is critical?
>
Hmmm. Doesn't your test case already take 2-1/2 seconds to change card ? 
(13 seconds for 5 iterations).

That's plenty long enough to annoy me. I get frustrated (for example) 
with the forums, because of the 1-3 seconds it takes to transition from 
one interesting topic to the next.

I have no idea what current UI thinking is - and I admit that the 
increasing use of the web and online access has probably increased 
people's acceptance of small delays - but back in the day I was used to 
aiming for sub-second response to complete *most* user actions.

Alex.