[Top][All Lists]
[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
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- [Gnash-dev] BitmapData,
Benjamin Wolsey <=