(long) Transparent IDE elements and other problems
frank at backtalk.com
Sat Mar 27 14:03:19 CST 2004
On Saturday, March 27, 2004, at 07:01 PM,
use-revolution-request at lists.runrev.com wrote:
> From: "Ken Ray" <kray at sonsothunder.com>
> Subject: RE: (long) Transparent IDE elements and other problems
> To: "'How to use Revolution'" <use-revolution at lists.runrev.com>
> Message-ID: <006a01c41423$b4817390$6601a8c0 at precision340>
> Content-Type: text/plain; charset="us-ascii"
> I've been watching this thread with some interest, and decided it was
> time I jumped in.
> 3) I agree with Frank on the memory management/rendering side of
> things, and
> that is that if you have 3000 objects in a group, but only 100 are
> at any given time, Rev should be doing everything it can to optimize
> and not load all 3000 objects into memory or render them until they are
> needed to be rendered. Now having said that, I don't know that Rev
> doing this already. The test would be to take 3000 (or whatever
> amount) of
> small objects/images and display them all onscreen at once, with no
> overlapping (this would most likely require a large resolution).
Time to show 190 photos in a scrolling list -- under 3 seconds on my
Time to show 294 photos in a scrolling list -- about 8 seconds.
Time to show 1124 photos in a scrolling list -- about 60 seconds. But
only 728 fit in the scrolling list (32000 pixel limit).
Degradation? Yes. Graceful degradation? Well...maybe not.
I was sure that the bottleneck was reading the photos from disk, as I
could hear the disk being hit a lot, so I commented out the "set the
filename" line. Result? Essentially no speed difference.
So then I commented out the code that sets *any* information in each
group (title, etc.), so all that's happening is the photo groups are
being created and positioned. Result? The 1124 photo version dropped
to 15 seconds.
Hmmmm. As Wouter said it looks like there's some room for improvement.
More information about the use-livecode