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.
--
Dipl.-Inform. (FH) Reinhard Nissl
mailto:rnissl@xxxxxx
_______________________________________________
vdr mailing list
vdr@xxxxxxxxxxx
http://www.linuxtv.org/cgi-bin/mailman/listinfo/vdr
