[vdr] Truecolor osd and speed.

Reinhard Nissl rnissl at gmx.de
Sun Jun 14 00:16:46 CEST 2009


Hi,

Udo Richter schrieb:
> 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.
> 
>  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?
> 
> However, this depends on how close this could be adapted by the 
> different platforms. How do eHD and VDPAU handle transparent overlays at 
> all? Are they merged with the video in software? Are they overlays that 
> get displayed in hardware? Would page flipping be possible?

In VDPAU you have several layers (up to 4 at the moment) for
video and OSD for example. All layers are independent of
resolution, color space and color depth. For each layer you can
define source and destination rectangles witch align the layers
to the output rectangle. All scaling and blending operations are
done by the hardware. Think of several OpenGL objects, so page
flipping should be possible.

vdr-xine transfers only the dirty rectangle of the OSD to xine
(via pipe or socket), but the initial display of an OSD with the
above mentioned dimensions would indeed need to transfer 9 Mb
from VDR to xine.

BTW: an issue regarding dirty rectangle and text rendering:
wiping the background makes the area dirty even when continuously
rendering the same text which actually doesn't change anything.

Bye.
-- 
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl at gmx.de



More information about the vdr mailing list