
|
[haiku-appserver]
||
[Date Prev]
[11-2005 Date Index]
[Date Next]
||
[Thread Prev]
[11-2005 Thread Index]
[Thread Next]
[haiku-appserver] TextLayoutEngine
- From: Stephan Aßmus <superstippi@xxxxxx>
- To: haiku-appserver@xxxxxxxxxxxxx
- Date: Wed, 16 Nov 2005 21:27:21 +0100
Hi,
I started to work on extracting a class for general glyph processing. It
would use the AGG glyph cache and be a global instance class. Whenever some
app_server object needs to iterate over glyphs, it will go through the
global TextLayoutEngine. This object has a glyph cache on its backend. It
will use a template class "GlyphConsumer" such as this:
template<class GlyphConsumer>
status_t
TextLayoutEngine::LayoutGlyphs(const char* utf8String, int32 length,
GlyphConsumer& consumer);
A glyph consumer can be anything. The TextLayoutEngine expects the
GlyphConsumer template to export a function ConsumeGlyph(const
agg::glyph_cache* glyph);
A GlyphConsumer can be an object which sums up the width of the glyphs
layouted by the TextLayoutEngine. It could be the AGGTextRenderer. The
point is that we would get rid of all this code duplication to iterate over
glyphs at all those places.
The global TextLayoutEngine instance would have two functions for granting
exclusive access to it:
Acquire(const ServerFont& font);
Release();
Between Acquire(), which also configures the font and Release(), The
TextLayoutEngine can be used by just one client. The clients can be
ServerFont objects in their StringWidth(), GetEscapements(), etc calls. But
also the Painter objects, of which I plan to give each ServerWindow object
another instance.
Later, we could also make the caching backend a MultiLocker object. You
would start with a ReadLock() and switch to WriteLock() access as soon as
you need to add something to the cache. But let's do one step at a time.
I think this change would greatly clean up the text layouting code.
Any objections or suggestions?
Best regards,
-Stephan
|

|