[haiku-appserver] fonts & rendering state

Hi there,

I am starting to find my way into the app_server again, and relieved 
the crashing bug #1 quite a bit - I might still have missed some 
incorrect uses of the FreeType library, though.

FreeType only has one glyph slot per FT_Face - and we used it 
everywhere without any locking whatsoever. I've introduced a per 
FT_Face lock, but it's not quite nice.
A possible solution to this problem would be to copy the FT_Face for 
every drawing context using it - but since FreeType was obviously not 
written for a multi-threaded use (it has a very dumb and basic API, and 
I really wonder who came up with this stupid indenting style as 
well...), we would need to create new FT_Faces from the font file or 
some cached font data (which would take lots of memory). Due to those 
problems, that doesn't look exactly like a good solution to me.

What I would prefer is to move the FreeType usage one layer deeper: we 
could move all of FreeType below our font class - if anyone needs 
anything from FT, it would go through that class which can handle the 
locking properly. That would make sure we really catched all uses of FT 
functions. Another advantage however, would be that we can cache the 
size and glyph data (possibly in rastered bitmaps?). We would then need 
one font per font size used.

I am not yet sure how we can integrate this into AGG, as I still have 
almost no clue about this library. Would it be possible to have the pre
-rendered glyph bitmaps around, or should we better cache the glyph 
data itself? What makes more sense regarding speed?

Also, the rendering context of the painter, and the one that is used by 
AGG is set manually for *each* drawing operation. I don't think this is 
how it should be done, as we could make better use of the DrawData 
object than we do right now. But that also depends on how AGG works: 
would it be feasible to have a per view drawing context for AGG that is 
encapsulated by a DrawData derivate?
IOW could we have a DrawData subclass that also manages the AGG 
context? That way, it could directly be used in the painter methods, 
and wouldn't have to be set each time.
Are there any plans floating around about this already?

BTW the app_server is much more stable now, but still crashes very 
often. Unfortunately, the best way to let it crash is by winning 
Minesweeper - which I can only do natively :-/

Bye,
   Axel.

Other related posts: