I've committed code to trunk that implements BitmapData.draw and BitmapData.loadBitmap. I'm not sure there will be a commit message because a commit mail was bounced to me due to its size, so here's a summary of the changes:
BitmapData.loadBitmap is implemented; it's renderer-independent. The testcases for this require ming head. The function behaviour is incorrect in a very minor detail, namely that it should not create a BitmapData object if the BitmapData.loadBitmap is used other than as a member function of a simple object. I haven't spent the time to work out exactly the circumstances under which it should fail. BitmapData.draw is implemented for agg only. I think cairo wouldn't be too hard to add, but I'm not planning to do it. Various tests in the testsuite will fail if there is no agg renderer present (though I think this was the case before in misc-ming.all). The gprocessor utility now initializes a 1x1 renderer if available. It performs no rendering to the screen, but actionscript execution depends on the presence of a renderer for BitmapData.draw. As part of the draw implementation, all DisplayObject::display() functions take a transform argument. This is an aggregate of matrix and color transform, and allows us to specify a base transform and concatenate further transforms as needed, instead of using the recursive and inflexible world matrix and world cxform functions everywhere. DisplayObjects therefore have a Transform data member to reduce copying. Masks are still incorrectly handled in some cases for BitmapData.draw. The draw function takes a custom matrix and cxform. It appears that the translation part of the custom matrix is handled in the core, while the scaling is done afterwards by the renderer. This difference is only noticeable when a dynamic mask is involved. The mask is always positioned using its current transform. Gnash currently handles the whole matrix in the core. Additionally there seems to be a bug with mask invalidation, or possibly DisplayObject invalidation. Mask display is now handled outside the DisplayList using a DisplayObject::MaskRenderer in appropriate DisplayObject types. BitmapData.floodFill is implemented, but the algorithm isn't particularly fast. BitmapData properties are now native functions, as they are expected to be. Image iterators have undergone yet another change, this time to separate them from the GnashImage class. Some classes were renamed in accordance with coding style. Parsing code is moved outside the class, using newly provided constructors. This makes the code much clearer with negligible cost (and potentially some gain through better compiler optimization). All new code is extensively tested with new testcases (and some old ones), and I've been testing this incrementally for a few weeks, which picked up some bugs that the testsuite missed. Still, there may be regressions, particularly with DisplayObject transformation, so keep an eye out for it! Note that other BitmapData functions, such as copyPixels() or scroll(), can now be implemented relatively easily, so let me know if anyone is interested! bwy _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
