On Saturday, March 27, 2004, at 07:01 PM, [EMAIL PROTECTED] wrote:
[snip]From: "Ken Ray" <[EMAIL PROTECTED]> Subject: RE: (long) Transparent IDE elements and other problems To: "'How to use Revolution'" <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> 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 iBook.
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
_______________________________________________ use-revolution mailing list [EMAIL PROTECTED] http://lists.runrev.com/mailman/listinfo/use-revolution
