Hi Ian,
Some of what I'm seeing is that quite a few of the swfs that I happen to
be loading contain their own internal scaling functions. Most typically
I'm seeing are swfs that automatically scale to stage.stageWidth and
stage.stageHeight. This is for the most part easy to detect, but there
are some timing issues -- the scaling doesn't happen right away.
A different issue that I'm seeing is with the videos on YouTube. The
expectation is that end users will want to appropriate YouTube videos in
their own content. Here are two randomly selected addresses parsed out
of the embed tags:
url = 'http://www.youtube.com/v/PbeMwl_PA6A&hl=en&fs=1'
url = 'http://www.youtube.com/v/Jag7oTemldY&hl=en&fs=1'
When loaded into a parent swf, these both have loaderInfo.width/height
of 640x480. This differs from the width and height specified by the
YouTube provided embed tags of 425x344, but that's not the problem.
Here's the problem, when I load these into a parent swf, with absolutely
no scaling (I've checked, scaleX and scaleY are 1.0), the visible
dimension of these videos is 480x385. This size seems to have no
relationship to the size of the parent stage at all, whether it is
100x100 or 1000x1000.
This is the method that I am using to bring in the swf:
var loader:Loader = new Loader();
var request:URLRequest = new URLRequest(url);
loader.load(request);
addChild(loader);
Here's the function I use to determine the opaque rectangle of a loader
object.
function getLoaderRect(loader:Loader):Rectangle {
// start with a bitmap big enough for the end loader
// note: it needs to be at least as big as the stage,
because some swfs will automatically size to the stage
var w:Number = 2*Math.floor(Math.max(stage.stageWidth,
loader.contentLoaderInfo.width));
var h:Number = 2*Math.floor(Math.max(stage.stageHeight,
loader.contentLoaderInfo.height));
var widgetBmp:BitmapData = new BitmapData(w, h, true,
0x00000000);
// copy the loader into the bmp
widgetBmp.draw(loader);
// get the rectangle around the non-transparent pixels
var rect:Rectangle = widgetBmp.getColorBoundsRect(0xFFFFFF,
0x00000000, false);
return rect;
}
This function is not at all fool-proof because at any given time while
playing, the opaque area can change. As we all know, it's not uncommon
for there to be stray bits lying off to the side of the stage. It's
also typical for projects to contain only a small "loading" animation at
the beginning.
From what I can tell so far, arbitrarily loaded swfs will fall into one
of three categories:
1) swfs that have their own internal scaling functions that vary
depending on the size of the parent swf.
2) swfs that "correctly" reflect the nominal w and h of their loaderInfo
object.
3) swfs like the YouTube examples that are none of the above.
Ian Thomas wrote:
But to add to the SWF header debate etc. - I believe the
loaderInfo.width and .height gives you what's in the header, so I
don't think there's much point in actually parsing the header, because
you'll get the same info. Andrew - I suspect there's something else
going on in terms of scaling or some such, because I believe that
loaderInfo.width and loaderInfo.height should be giving you valid
results -- it may be that for some reason you're interpreting them
incorrectly. Wwrong frame of reference? Ignoring the scaling of the
Loader class? Try loaderInfo.width*loader.scaleX, for example...
_______________________________________________
Flashcoders mailing list
Flashcoders@chattyfig.figleaf.com
http://chattyfig.figleaf.com/mailman/listinfo/flashcoders
