* 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? 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? Thanks again, and sorry for my annoying questions! -Claudio