[haiku-appserver] Re: fonts & rendering state

  • From: Stephan Aßmus <superstippi@xxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Sun, 06 Nov 2005 22:46:40 +0100

Hi Axel,

sorry for the late reply!

> 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?

This is already happening. See


The caching is usually based on bitmaps rendered by freetype, except for 
somehow transformed fonts (rotated or sheared), in which case vector data 
is cached and rendered by AGG. This distinction happens in 

> 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?

This translates to "one Painter instance per layer" which would be quite 
heavy. I have also thought about this when I worked on it more. I would 
think it is best to have one Painter instance per ServerWindow object. That 
is why the underlying HWInterface object is a MultiLocker. Multiple Painter 
objects would share the same HWInterface instance. Since drawing cannot 
overlap, the function needing a WriteLock() are only the hardware 
accelerated ones unless I missed something.

> 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?

Other than what I wrote above and what is said in the comments in 
Painter.h, nothing. Note though that the heavy stuff is already taken care 
of: The font is not reloaded each time unless necessary, and the clipping 
is set via a BRegion pointer. These are the two things that would otherwise 
take time when switching the DrawState. I have timed this stuff and the 
actual switch, while it would be nice to remove it, is not taking that much 

> 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 :-/

:-) It still crashes quite often for me. And some stuff that previously 
worked is now broken again:

* enforcing BWindow size limits
* preventing layer placement at fractional offsets (see BAlerts)
* syncing the client and server about layer placement (only works sometimes)
* coordinate conversion through the hirarchy for scrolled views

But the progress is there again! Nice to see everybody working on 

Best regards,

Other related posts: