Re[2]: [Gnash-dev] shape_character_def fill/line styles

[Udo Giacomozzi]

Hello strk,

Sunday, May 20, 2007, 9:55:00 PM, you wrote:
s> The problem was using a fill style index as an offset
s> to the corresponding *EMPTY* shape_character_def style vector.
s> It's intrinsic in the current model, as style change is read
s> for glyphs (usually always 1) but no style info are present
s> in the SWF.

Don't know if you're aware of this, but fill style 1 is the first one.


s> Agg was blindly trusting the caller to have provided consistent
s> data instead.

AGG *internally* uses an internal fill style to render glyphs.
See draw_glyph() in render_handler_agg.cpp. You see that it sets a
temporary fill styles list "m_single_fill_styles" to the requested
color. However, *no* shape_character_def fill styles are involved!


s> When I tried to use a style offset of '0' AGG simply did NOT
s> render the glyphs (ie: transparent fill?).

Fill style "0" means "no fill" in the Flash world. That would be Gnash
index -1. That's not the same like specifying fill styles 2 or greater
which indeed cause *rendering* of transparent pixels.

More precisely:

Fill style 0 is handled at rasterizer level (ie. pixels are not
touched).
Fill style 2+ are handled by agg_style_handler which should fail an
assertion (when "is_solid" is called by the AGG lib).


s> So my solution was providing a dummy fill style entry
s> in the shape_character_def when reading glyphs, and warning
s> about malformed SWF when any other index is used for style
s> change (it seems 1 is what is required to be there by specs).

Again, when rendering Glyphs the shape_character_def fill styles are
*not* being used. Should be true for non-AGG handlers too, see
triangulating_render_handler::draw_glyph()



>> Remember that the fill color of the glyph is also defined ad-hoc.
>> draw_glyph() has a "color" parameter..

s> I wonder if we can add the "color" parameter to the dummy fill style and 
remove
s> that parameter from the draw_glyph() call.

draw_glyph() initializes the dummy fill style.


s> But I'm afraid we can't as glyphs
s> can probably be rendered in different colors based on instances.

Indeed.


s> Maybe
s> the dummy style would be a solid white fill and the draw_glyph() should take
s> a color transform or so...

The dummy fill style is a proteced member of render_handler. It's up
to draw_glyph() what it does with it.


>> AGG uses a fully transparent "color" for inexistent fill styles. Just
>> to avoid critical errors. Maybe it's not a clean design (using
>> hardcoded fill style IDs) but I see no real problem in this.

s> You mean for fill style indexes == 0 here, right ?

No, I meant for indexes not within [1..NUMBER_OF_FILL_STYLES]. However
this applies to agg_style_handler::color() only, but AGG calls back to
is_solid() before asking for the color() and so my statement was not
right -- it will fail the assertion in render_handler_agg_style.h:300


>> Before fixing anything we'd need to understand the problem first. Why
>> should there be a problem with fill style IDs (instead of pointers)?

s> There would be a problem if it's not clear what do the indexes point to.
s> There would be problems if pre and post conditions are not defined.

The indexes resemble what's found in the SWF. For normal shapes they
point to a fill style list of the definition.

Glyphs obviously have no fill style list as they are always solid and
the color depends on whatever the glyph uses.

So it seems fine for me that glyphs use the "one any only fill style
available". Furthermore, glyphs use two fill styles, "0" and "1", to
define where pixels need to be drawn and where not. Once again, "0"
means "no fill" and does not reference any fill style.


>> More interesting would be to know why referenced fill styles stop
>> existing at some point (this is what I understood from your mail).

s> No, you didn't understand. Or *I* didn't.
s> Anyway, what I'm saying is that the referenced fill style *never* existed.
s> The shape_character_def::read is called with the parameter 'with_style'
s> == false (which is do not read any style info).

Of course, because glyhs have no fixed fill style. You could not even
use a pointer for that as it has nothing to point to.


>> After all, there is nothing that changes fill styles.

s> Nothing created it for glyphs.
s> See my commit of 2007-05-14 for shape_character_def.cpp, with
s> commit log:

s>         * server/parser/shape_character_def.cpp (read): when parsing
s>           DEFINEFONT tags provide a dummy solid white fill style to
s>           act as a placeholder for consistency checking.

What relies on that fill style? The render handler does *not*.


Udo