gnash-dev
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Gnash-dev] BitmapData


From: Benjamin Wolsey
Subject: [Gnash-dev] BitmapData
Date: Wed, 25 Aug 2010 10:55:03 +0200 (MEST)

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



reply via email to

[Prev in Thread] Current Thread [Next in Thread]