gnash-dev
[Top][All Lists]
Advanced

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

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


From: Udo Giacomozzi
Subject: Re: [Gnash-dev] shape_character_def fill/line styles
Date: Sun, 20 May 2007 12:08:06 +0200

Hello strk,

Monday, May 14, 2007, 9:50:42 PM, you wrote:
s> I already raised a warning about this in the past, suggesting to store 
pointers
s> to real fill styles in the gnash::path class, for consistency. Udo said it 
wasn't
s> worth it, but can't remember why.

Because AGG (the lib) uses numbers too and I see no real benefit in
using pointers. (Don't fix it if it ain't broken).


s> What I know is that it's not only easy, but it's actually happening that the 
indexes
s> end up referring to unexistend elements of the vectors.

What causes this? I guess the root problem is another one..



s> When trying to ensure consistency, I found that the *inconsistency* is needed
s> for glyphs. When parsing a DEFINEFONT or DEFINEFONT2 tag, we're going to read
s> shape definitions that contain a left-fill offset of 1 (first element of
s> the array), but we never create that array.

Hmm, *probably* because glyphs always use solid fills (ie. don't use
real fill styles).


s> Hackish handling of this is in the renderer classes, that create an ad-hoc 
style
s> when dealing with glyphs.

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


s> Unfortunately, discarding the fill and line style indexes in these cases 
(which is:
s> whenever they refer to an unknown/unexistent element) breaks the rendering: 
glyhps
s> are no more shown.

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> So. Udo: any idea about fixing this ?

Before fixing anything we'd need to understand the problem first. Why
should there be a problem with fill style IDs (instead of pointers)?
More interesting would be to know why referenced fill styles stop
existing at some point (this is what I understood from your mail).
After all, there is nothing that changes fill styles.

Of course, drawing API is a different story...

Udo





reply via email to

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