Some questions have come up about how to have a high resolution/color osd without having to sacrifice the speed of the osd. VDPAU users have noticed that when using a high resolution theme in yaepghd, it can take 5+ seconds for the osd itself to even be displayed.
Per Klaus, VDR's position is this: "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."
Some suggestions by Rnissl have been: -Similar way the eHD handles it -Allow osd areas to overlap and put such images into separate areas -Extend the osd api for scroll commands
I thought this was important enough of an issue to post to the mailing list. Hopefully those with knowledge on the subject will participate and a good method can be established. We're finally getting the truecolor osd, just have to make sure it's usable and doesn't suffer from massive slowdown! :)
Please, discuss!
Regards, Derek
On 06/13/09 17:31, VDR User wrote:
Some questions have come up about how to have a high resolution/color osd without having to sacrifice the speed of the osd. VDPAU users have noticed that when using a high resolution theme in yaepghd, it can take 5+ seconds for the osd itself to even be displayed.
Per Klaus, VDR's position is this: "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."
Some suggestions by Rnissl have been: -Similar way the eHD handles it
Can you (or somebody else) summarize in a few words what special handling the eHD does?
-Allow osd areas to overlap and put such images into separate areas
I was aiming at having just one big area. The various areas that are used now are just a makeshift solution for the low memory that was available on the FF DVB cards. I would expect a "modern" hardware to have enough memory to handle a full screen, 32 bit OSD.
-Extend the osd api for scroll commands
Ok, that sounds like a good thing to do. VDR would still draw into its local OSD memory and do the scrolling there, but would not need to actually send the entire scrolled area over to the hardware and instead tell the hardware to perform exacly the same scrolling in its copy of the OSD memory.
Klaus
Hi,
Klaus Schmidinger schrieb:
On 06/13/09 17:31, VDR User wrote:
Some questions have come up about how to have a high resolution/color osd without having to sacrifice the speed of the osd. VDPAU users have noticed that when using a high resolution theme in yaepghd, it can take 5+ seconds for the osd itself to even be displayed.
Per Klaus, VDR's position is this: "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."
Some suggestions by Rnissl have been: -Similar way the eHD handles it
Can you (or somebody else) summarize in a few words what special handling the eHD does?
I cannot tell, what these OSD function do internally, but it looks to me like they are meant to avoid copying large memory blocks to the eHD over and over:
virtual void SetImagePath(u_int imageId, char const *path); virtual void DrawImage(u_int imageId, int x, int y, bool blend, int horRepeat = 1, int vertRepeat = 1);
-Allow osd areas to overlap and put such images into separate areas
I was aiming at having just one big area. The various areas that are used now are just a makeshift solution for the low memory that was available on the FF DVB cards. I would expect a "modern" hardware to have enough memory to handle a full screen, 32 bit OSD.
VDR 1.2.x could have overlapping windows and my vdr-xine supports it. For convenience, I've implemented VDR 1.3.x tAreas the same way.
The idea is to put a background image into one window and the displayed text into another one (which appears is in front of the other), the window with the background image isn't changed while moving through the text.
Think of layers.
-Extend the osd api for scroll commands
Ok, that sounds like a good thing to do. VDR would still draw into its local OSD memory and do the scrolling there, but would not need to actually send the entire scrolled area over to the hardware and instead tell the hardware to perform exacly the same scrolling in its copy of the OSD memory.
In case a fancy OSD implementation puts a background image behind the OSD text, scrolling in the above sense doesn't is no benefit without separate layers for foreground and background.
Bye.
On Sat, Jun 13, 2009 at 11:51:02PM +0200, Reinhard Nissl wrote:
Can you (or somebody else) summarize in a few words what special handling the eHD does?
I cannot tell, what these OSD function do internally, but it looks to me like they are meant to avoid copying large memory blocks to the eHD over and over:
virtual void SetImagePath(u_int imageId, char const *path); virtual void DrawImage(u_int imageId, int x, int y, boolblend, int horRepeat = 1, int vertRepeat = 1);
That was the old way... At the beginning, I haven't found the magic/undocumented bit for accepting PCI bursts to the DeCypher memory, so the write bandwidth was only about 10MB/s. A raw framebuffer access would be very slow and flickery.
So the drawing commands were sent via a command pipe to the DeCypher. The hdplayer there did an interpretation of the commands and worked on its framebuffer. To accelerate the "fancy" stuff, there is a font and image cache in the hdplayer, so they need to be transferred only once.
BTW: The framebuffer itself is overlayed in the hardware over the video depending on the 8bit alpha value for each ARGB-pixel. There's also a mode with only a global alpha and "regular" RGB-pixels available, but that doesn't look that nice ;-)
However, all the alpha blending of the fonts and backgrounds were done in SW on the DeCypher. As it's only a 166MHz MIPS CPU, this was relatively slow.
Now it's done different, as PCI bursts are possible and the bandwidth is greater than 30MB/s. The hdshm kernel driver on the host linux implements a framebuffer driver (which also can be used for X). The reelbox-PI draws all its stuff in a shadow buffer and copies only the changed rectangle to the framebuffer.
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?
Cheers,
Udo
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
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@cadsoft.de To: vdr@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.
Klaus
vdr mailing list vdr@linuxtv.org http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
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.
-
Georg Acher -
Klaus Schmidinger -
Reinhard Nissl -
Timothy D. Lenz -
Udo Richter -
VDR User