Re: Comparative speed in switching among groups

2023-11-27 Thread ambassador--- via use-livecode 
Alex Tweedly wrote:

> On 27/11/2023 00:02, ambassador--- via use-livecode wrote:
>> 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.

True, there are many other cases where rendering speed will show itself, and 
resizing is one that will come up throughout a session.

My example only covered the transition speed as requested because I don't have 
the time I used to. LiveCode's decline in the market has me building a new 
business.  It's been a long time since I've built a business from scratch; 
turns out it's not much easier than I remember it. :)

The big performance difference here isn't so much the number of groups but 
what's in them.  I'd guess the fields alone are the biggest time sink, 
calculating line wraps for 20k text with no carriage returns.  With six of 
those fields it's almost silly to have that much text rendered below the fold 
at once; showing only the visible portion with a deferred loading of the rest 
would make things much snappier all around.

I've made many layouts with deeply-nested groups. But outside of artificial 
stress tests like this I generally don't see load and save times as long as I 
see with this test stack.


> >  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).

Yes, hindsight is always illuminating. :) But the question would not have been 
posed if the answer was known in advance.

Given how often we use the card model provided, if the delay were this 
significant more often we all would have abandoned the practice long ago.  But 
for most things card-to-card speed is more than adequate, and sometimes useful 
for organzing things during the development workflow.

My own work has used both cards and groups, depending on particulars unique to 
the project. But now I'm also a little more aware of overall perfortmance 
degradation with line wrap calculations and images larger than their displayed 
size. 

Richard Gaskin
FourthWorld.com

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Comparative speed in switching among groups

2023-11-27 Thread Alex Tweedly via use-livecode 


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.
___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Possible enhancement request

2023-11-27 Thread Paul Dupuis via use-livecode 

On 11/2/2023 11:20 AM, Klaus major-k via use-livecode wrote:

Hi friends,

before I post an enhancment request to the "Qualtiy Center", I wanted to hear 
your opinions about this.

Wouldn't it be great if ALL widgets would receive and handle at least a mouseup 
(and mousedown) meassage?
I have always wondered why that is not the case.

This way scripting would be a lot easier for us and we do not have to remember 
the many different messages
the widgets have. Yes, they can be seen in the script editor on the left side, 
nevertheless... :-)

Examples:
PolyGrid -> cellclick
PolyList -> itemclick
Segmentedcontrol -> hilitechanged
Switch Button -> hilitechanged
Radial Slider -> valueChanged
Navigation Bar -> hilitechanged
Line Graph -> receives NO message at all?



It seems to me that for most of these (not sure about Line Graph) that 
'selectionChanged' is the more applicable 'standard' message than a 
mouseUp or mouseDown, although I would wholly agree that every (or 
nearly every) widget should pass mouseUp and mouseDown if they do not.

___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode

Re: Possible enhancement request

2023-11-27 Thread Klaus major-k via use-livecode 
Hi all,

I filed an enhancement request for this with some more examples:


Best

Klaus

> Am 02.11.2023 um 17:01 schrieb J. Landman Gay via use-livecode 
> :
> 
> +...
> 
> I can never keep all those variations straight.
> --
> Jacqueline Landman Gay | jac...@hyperactivesw.com
> HyperActive Software | http://www.hyperactivesw.com
> On November 2, 2023 10:21:29 AM Klaus major-k via use-livecode 
>  wrote:
> 
>> Hi friends,
>> 
>> before I post an enhancment request to the "Qualtiy Center", I wanted to 
>> hear your opinions about this.
>> 
>> Wouldn't it be great if ALL widgets would receive and handle at least a 
>> mouseup (and mousedown) meassage?
>> I have always wondered why that is not the case.
>> 
>> This way scripting would be a lot easier for us and we do not have to 
>> remember the many different messages
>> the widgets have. Yes, they can be seen in the script editor on the left 
>> side, nevertheless... :-)
>> 
>> Examples:
>> PolyGrid -> cellclick
>> PolyList -> itemclick
>> Segmentedcontrol -> hilitechanged
>> Switch Button -> hilitechanged
>> Radial Slider -> valueChanged
>> Navigation Bar -> hilitechanged
>> Line Graph -> receives NO message at all?

--
Klaus Major
https://www.major-k.de
https://www.major-k.de/bass
kl...@major-k.de


___
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription 
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode