(long) Transparent IDE elements and other problems

Ken Ray kray at sonsothunder.com
Sat Mar 27 12:48:20 EST 2004


I've been watching this thread with some interest, and decided it was about
time I jumped in.

I think the issue boils down to a few fundamental issues:

1) Rev should be able to manage multi-thousands of objects, but at a price -
the more objects you use the slower things get. Just as Brian mentioned, you
don't *want* to load a million records in to a record list of your database,
but that doesn't mean that you shouldn't have the ability to if you want to
pay the price for doing it. If you want to load a million lines of
information into a field you should be able to. Just don't expect the host
program (Rev in this case) to be very responsive. Or if you load 3000 images
into memory, don't be surprised if you need 1GB or more of RAM to handle it.

2) It's not really how much Rev can manage at once (see #1), it's also about
how much is displayed to the user. In your analogy, Frank, of *course* you
should be able to have a 200 page document in Word - just don't show them a
single screen with 200 thumbnails of each page because at that size/etc. you
lose relevancy in the information presented. The *capacity* to hold 200
pages (or thousands of controls) is one issue; what is presented to the user
is another thing entirely. Even though you have an iPhoto library of 3000
images, you're not displaying them all simultaneously on one screen (I would
assume).

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 the
amount of time it takes to redraw the card, then take most of the objects
nad put them offscreen in the scrollable group only leaving about 100
visible. Then time how long it takes to redraw the card. If the times are
the same, Rev needs to optimize this. If the times are different, Rev's
already doing *something* (but perhaps it could do more).

Anyway, that's my 2 cents,

Ken Ray
Sons of Thunder Software
Email: kray at sonsothunder.com
Web Site: http://www.sonsothunder.com/




More information about the use-livecode mailing list