What about a simple Option flag? TrueColor yes/no/auto. A setting in the config file with auto detecting if output is via a nexus or other device that can do TC. If auto detect is not possible then just yes/no. ----- Original Message ----- From: "Klaus Schmidinger" <Klaus.Schmidinger@xxxxxxxxxx> To: <vdr@xxxxxxxxxxx> Sent: Saturday, June 13, 2009 9:49 AM Subject: Re: Truecolor osd and speed. > 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 _______________________________________________ vdr mailing list vdr@xxxxxxxxxxx http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
