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.