David Craig writes:
> Just to elaborate a bit more we will have to convert RGB values to Y
> (luminance), and Cr + Cb -> UV values (chrominance). Which makes up the YUV
> display framebuffer (also called CIE Luv).
>
> The trickiest bit is that Y and UV values which make up each on screen pixel
> are stored in two separate (but contiguous) planar framebuffers. Ie
> 720*576*8bit pixels of Y values, followed by 720*576*8bit UV values. We will
> need dev/fb to be in this bi planar format which means GGI framebuffer/pixel
> operations will need operate on both Y & UV planes simultaneously as well as
> converting the (RGB <-> YUV) formats. Does/could GGI support any such multi
> plane operations through one single config point?
A special drawing sub-lib will need to be written. Something like
libggi/default/planar but for your YUV format. What sort of planar is
it, bit-planar or interleaved-lines or interleaved-words ? (Or did
you just mean that Y and UV are separated ?).
> Ie will I need to implement custom fb read/write procedures for lots of
> framebuffer access routines or maybe just putpixel & getpixel.
Just having putpixel and getpixel will get it working, plus the color
mapping routines. You'll get better performance by implementing the
other drawing routines too (drawhline, puthline etc), but that can
come later.
Cheers,
__
\/ Andrew Apted <[EMAIL PROTECTED]>
