[haiku-development] Re: Text rendering

Quoting Stephan Assmus <superstippi@xxxxxx>:

>
> Claudio Leite wrote (2007-06-18, 16:45:28 [+0200]):
> > Hello again,
> >
> >  Maxim replied on the AGG list and advised to implement this on a lower
> > level (below scanlines). But it seems AGGTextRenderer uses scanlines and
> > renderers even when using a FT bitmap. I'm thinking it might be useful
> > to bypass AGG totally in this case--since the functionality is all
> > there in FT--and just blend the FT alpha bitmap to the screen buffer in
> > DrawString() or some new class I create. My question is, thus, where does
> > the
> > screen buffer actually get written, and how could I access its values in
> > order to do the blending?
> >
> >  I must admit I'm proposing this alternative because I'm still having
> > major difficulties figuring out AGG and Painter and where they
> > intersect. You said in the README that you wrote a news article
> > explaining the basics--where can I access this? In any case, it seems as
> > though the relevant parts of AGGTextRenderer boil down to only a few
> > functions, and unfortunately it seems agg_font_freetype and AGG itself
> > are rather committed to the idea of gray8 and mono, nothing else.
>
> I have read the reply from Maxim. Unfortunately, he doesn't really answer
> your question with regards to how the scanline adaptor in the font manager
> works.
>
> I would urge you to trust me on this and take my advice. I know the
> FreeType->AGG->Painter->app_server design best, and I tried to convince you
> of the best approach. Maxim does not know this design, but basically, he
> told you the same thing as I, which is that you have to implement your own
> "pixel format". This is the same thing what I meant when I wrote, you need
> to reimplement the "DrawingMode" classes. I explained this in my first
> email.
>
> The reason why I am suggesting not to bypass the existing framework, is
> that you need to support all those drawing modes that the Be API defines
> anyways. I mean, ok, if you wanted, you could implement it only for
> B_OP_COPY, B_OP_OVER and B_OP_ALPHA at first... to get things started. But
> then you need to check if the drawing mode is one of those, and handle it
> specially, and only when rendering text.
>
> I know how it feels to try and understand an existing codebase, but it will
> be worth the effort. I will try to explain some more in this email.
>
> The Painter class is "attached" to a rendering buffer. It happens in
> Painter::AttachToBuffer(). Most times, this is the frame buffer in the
> graphics card, but it could be a BBitmap prepared for drawing into, or it
> could be a copy of the frame buffer in main memory for doing double
> buffering (which is done when the color space of the frame buffer is not 32
> bits!).
>
> There are several classes involved in the AGG rendering pipeline:
>
> rendering buffer:
>   knows the address and size of the memory allocated for the buffer and
>   keeps a pointer to the beginning of every line of pixels
>
> pixel format:
>   is attached to a rendering buffer, and it knows how to write color
>   information into pixels
>   it needs to implement a certain interface (blend_solid_hline()...)
>
> (The Painter implementation is called "PixelFormat", and lives in
> src/servers/app/drawing/Painter/drawing_modes/... it dispatches the needed
> implementation of each "pixel format" function to a DrawingMode instance,
> which implement the blending for the Be API defined drawing modes such as
> B_OP_COPY, B_OP_ADD, B_OP_INVERT...) In Painter::_UpdateDrawingMode(), the
> PixelFormat is configured so that it uses the correct DrawingMode
> implementation. It even knows if we are about to render text, so you can
> use this information.
>
> renderer:
>   provides the connection between the pixel format and the rasterizer
>
> (Painter uses just the AGG provided implementation, but attaches it to the
> custom PixelFormat implementation above.)
>
> rasterizer:
>   produces "scanlines" of alpha values, based on the coverage of
>   vector shapes over pixels areas and uses a renderer to write
>   these scanlines into pixels
>
> (Again, Painter uses the stock AGG implementation.)
>
> For text rendering, AGG uses a "font manager" implementation. The back end
> for that is the "font engine", for which Painter again uses a custom
> implementation, which is based on ServerFonts, the app_server's font
> representation.
>
> *Somewhere*, Maxim has written a scanline adaptor in the "font manager" so
> that it can _copy_ scanlines from FT_Bitmaps, instead of having the
> rasterizer generate this output. The code must be there, and if I had some
> time, I would go look for it myself. It shouldn't be that hard to find. The
> AGG library lives in src/libs/agg.
>
>
> My article on Painter is called "Painter and How AGG Works", but it seems
> to have completely disappeared from our site. I have no idea why, I know it
> used to be there. :-(
>
>
> As mentioned, have a look at Painter::AttachToBuffer() to see how the
> pipeline is set up.
>
>
> Best regards,
> -Stephan

Don't we have any article on our web site that explains this design already?
If not, I guess one will be welcome.

Beside, we may have to talk in a near future how to adapt this design to take
advantage of advanced GPU support. Going full OpenGL compositing for example
comes to my mind. Aka PicassoGL, except with an haiku-ized name (any japanese
painter celebrety?!) ;-).

- Philippe

Other related posts: