[vdr] Truecolor osd and speed.

Georg Acher acher at in.tum.de
Sun Jun 14 00:28:00 CEST 2009

On Sat, Jun 13, 2009 at 11:51:02PM +0200, Reinhard Nissl wrote:
> > Can you (or somebody else) summarize in a few words what special
> > handling the eHD does?
> I cannot tell, what these OSD function do internally, but it
> looks to me like they are meant to avoid copying large memory
> blocks to the eHD over and over:
>     virtual void SetImagePath(u_int imageId, char const *path);
>     virtual void DrawImage(u_int imageId, int x, int y, bool
> blend, int horRepeat = 1, int vertRepeat = 1);

That was the old way... At the beginning, I haven't found the
magic/undocumented bit for accepting PCI bursts to the DeCypher memory, so
the write bandwidth was only about 10MB/s. A raw framebuffer access would be
very slow and flickery.

So the drawing commands were sent via a command pipe to the DeCypher. The
hdplayer there did an interpretation of the commands and worked on its
framebuffer. To accelerate the "fancy" stuff, there is a font and image
cache in the hdplayer, so they need to be transferred only once.

BTW: The framebuffer itself is overlayed in the hardware over the video
depending on the 8bit alpha value for each ARGB-pixel. There's also a mode
with only a global alpha and "regular" RGB-pixels available, but that
doesn't look that nice ;-)

However, all the alpha blending of the fonts and backgrounds were done in SW
on the DeCypher. As it's only a 166MHz MIPS CPU, this was relatively slow.

Now it's done different, as PCI bursts are possible and the bandwidth is
greater than 30MB/s. The hdshm kernel driver on the host linux implements a
framebuffer driver (which also can be used for X). The reelbox-PI draws all
its stuff in a shadow buffer and copies only the changed rectangle to the

         Georg Acher, acher at in.tum.de         
         "Oh no, not again !" The bowl of petunias          

More information about the vdr mailing list