(long) Transparent IDE elements and other problems

Frank Leahy 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 
> about
> 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 
> displayed
> at any given time, Rev should be doing everything it can to optimize 
> display
> 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 
> *isn't*
> 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.

-- Frank

More information about the use-livecode mailing list