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.


vdr mailing list

Reply via email to