[haiku-development] Re: Text rendering

Claudio Leite wrote (2007-06-18, 20:50:16 [+0200]):
> * Stephan Assmus (superstippi@xxxxxx) wrote:
> <snip>
> >
> > 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.
> 
> I had previously looked over this and looked again today, and while I
> think I have a better idea of how things are tied together (thanks for
> the explanations) I note that "cover" is defined as uint8. I'll need at
> least 24 bits to do this, but of course don't want to break the rest of
> the rendering engine by changing anything. I suppose if I make
> cover_type uint32 and change it where it is set to 8 bits it should just
> keep using those 8 bits when it doesn't need the extra information--so,
> would this break anything?

Actually I am not sure, you could be right. I'd just try it. If it turns out 
it cannot work, one thing you can do is to simply use a separate "pipeline". 
I have done this for another project where I reused Painter. In this project, 
I am supporting different colorspaces in Painter, and I made sure that every 
use of the rendering pipeline is tunneled through _StrokePath() and 
_FillPath() where the correct pipeline is chosen for the current colorspace. 
We could do the same in the Haiku version of Painter.

> I copied over DrawingModeCopyText.h to DrawingModeCopyText24.h to start
> implementing my own pixel format. Do I need to implement any more
> methods than the ones defined here?

No, just the methods defined there. The pixel format implementations from 
Maxim define more methods, but they are not used when the rasterizer is used 
as I am doing in Painter. (Since this is working via templates, the compiler 
would complain if they were used.)

> Thanks again, and sorry for my annoying questions!

No, they are not annoying! Don't get that idea! :-)

If I sound annoyed at all, it is only because I want to help you as much as I 
can, but don't have enough time at the moment to dig into this with you 
together... :-)

Best regards,
-Stephan

Other related posts: