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
