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, boolblend, 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.