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 _______________________________________________ Gnash-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnash-dev
