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 _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
