[vdr] Truecolor osd and speed.
Timothy D. Lenz
tlenz at vorgon.com
Sat Jun 13 21:43:18 CEST 2009
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 at cadsoft.de>
To: <vdr at linuxtv.org>
Sent: Saturday, June 13, 2009 9:49 AM
Subject: Re: [vdr] 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.
> vdr mailing list
> vdr at linuxtv.org
More information about the vdr