On 06/13/09 18:34, Udo Richter wrote:
On 13.06.2009 17:31, VDR User wrote:
"VDR renders its OSD into an array (of 8 bit indexes into a palette right now, and of full 24(rgb)+8(alpha) bit color values for truecolor) and its up to the device implementation how it transfers that array (or parts of it) to the actual display hard- or software."
To keep compatibility and to be less limited for a new OSD architecture, I would strongly suggest to keep the current OSD as it is, and introduce a secondary OSD2 interface for true color display.
The interfaces of cOsd all use a 32 bit tColor, which is perfectly suited to support true color. The underlying palette/bitmap stuff is only necessary for the "old" OSD types, while new ones will just use one big array of tColor values. I see no need for an OSD2 interface - the current interface (maybe with a few touchups and extensions, like the scrolling API) should do just fine, with full backwards compatibility.
From the performance point of view, would it be possible to directly render OSD into the graphics memory instead of copying an (possibly 1920x1200x32 = 9Mb) memory OSD to the surface?
I'm often told how simple it is for "modern hardware" to decode h.264 in software - I would assume that copying a 9MB block of data should be peanuts for such hardware ;-) Besides, most of the time (especially with the proposed scrolling API) it wouldn't even have to copy the entire block - only those parts that have actually changed, just like it's done already in the current OSD.
Of course a particular derived cOsd object can render its data in whatever way it pleases.
Klaus