main logo
Subject: Re: V4MD Picture type, less stressful on ram when loading pics
Author: Marcus Bointon
Posted: 2002/05/30 06:04:17
 
View Entire Thread
New Search


on 30/5/2002 12:51 pm, mb at modage at attbi D.O.T com wrote:

> At 2K for each thumb I never expected there to be such a memory problem.
> I actually am doing all the drawing via imaging lingo already. I never
> considered pulling images on the fly from Valentina because I thought it
> couldn't be faster than loading them internally, and why introduce a
> possible speed hit. Now that speed hit (if there is one) might
> definitely be the lesser of evils =)

I would not have bothered using imaging lingo here. Just setting
member.picture is a one-liner that's plenty fast enough and very simple, and
it means that you never have to worry about interactions between multiple
behaviours. I have a policy of never setting absolute sprite pixel positions
in code if I can avoid it (relative is fine). Makes things much more robust
and goes with the grain of what Director's expecting.

> I don't get what Director is doing. I even brought all 6000 2K each
> thumbs into an external cast and this cast is now 220MB (after save
> compact, etc)! I'm referring to the file size on disk. Am I missing a
> special lingo method like cleanUpFatGarbage() ? =P I just didn't expect
> these type of problems when I started =)

No, it's just that director expands imported bitmaps on import. If you save
your cast as a shockwave cast, it will compress back to JPEG (you can choose
compression settings per member) and things should get much smaller. There
is a way to have it that Director expands on import, but then reuses the
external files to build the shockwave cast, can't remember how though. It's
probably in help.

Marcus
--
Marcus Bointon
Synchromedia Limited: Putting you in the picture

marcus@synchromedia.co.uk | http://www.synchromedia.co.uk
 
©2002 Marcus Bointon
<-- Prior Message New Search Next Message -->