loading members at runtime 2004-02-28 - By NoiseCrime
Back
-- -- Original Message -- --
From: "Lucas Meijer" <lucas@(protected)>
> The FUD in the helpfile regarding the importFileInto command, is not
> because the importFileInto command is leaking, and MM doesn't fix it. It
> is because a memeber than has been importFileInto'd, cannot be unloaded.
> It cannot be unloaded, because director has no way to reload it
> afterwards. This is why the help says memory can be taken up quicly. If
> you just .erase() the member after you've used it, there' no problem at
all.
Ah that would make sense, i guess its too much to ask Director to read my
mind and know that i wouldn't want it loaded again ;)
> The .filename= approach doesn't suffer from this AFAIK, so in your case,
> this would be probably the best thing todo, altough importFileInto could
> actually be just as good.
Well my intial tests appear to have the same memory consumption, and at
stopmove all memory appears to be cleared. Besides if it does casue a
problem, its a simple case to change back to importfileinto and erase
members as you suggest.
More of a problem is there appears to be no way to determine if a bitmap
member has an alpha!
Am I missing a function?
Haven't tested importfileinto to see if it automatcially sets the usealpha
property (which member.filename doesn't). If it did then that could be used.
However I got a workaround based on filetype of the bitmap. If its JPG it
can't have an alpha, if its tif, png, or something else, then it can have an
alpha chanel, and will be deemed as such. To be honest I think this works
better as all non-alpha bitmaps need to be jpeg'd to reduce filesize, but it
would still be nice to check if a bitmap actually had an alpha.
Noisecrime 2004
__ ____ ____ ____ ____ ____ ____ ____ ____ ____
Dir3d-l mailing list
Dir3d-l@(protected)
http://nuttybar.drama.uga.edu/mailman/listinfo/dir3d-l
|
|
