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
framebuffer.
--
Georg Acher, acher@xxxxxxxxx
http://www.lrr.in.tum.de/~acher
"Oh no, not again !" The bowl of petunias
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
