I'm currently implementing support for Freetype fonts in VDR 1.5 (based on Alexander Riedel's patch) and would like to completely drop all the pixel font stuff.
Just to make sure there won't be somebody who absolutely needs the pixel fonts, please let me know if this is ok. Since probably most of you will be running VDR with UTF-8 anyway (once it is supported, which will be very soon), my guess would be that the pixel fonts are really obsolete.
Klaus
On 27 May 2007, at 17:49, Klaus Schmidinger wrote:
Have you given some thought to how to do OSD with HDTV? I guess one could either have a few supported resolutions, 480P, 720P and 1080P, or just go completely resolution independent.
Klaus Schmidinger wrote:
I'd support resolution independency, as I run VDR xineliboutput at the native resolution of my LCD TV, i.e. 1366x768.
Unfortunately I'm not too confident that there will be any new DVB cards with built-in decoders with HDTV output interface with OSD.
It seems to me like in the future HDTV picture would be output via DVI/HDMI of graphics adapter (or integrated one). I think some DVB cards with hardware HDTV decoding support could appear, though.
On Sunday 27 May 2007 18:49, Klaus Schmidinger wrote:
The extrecmenu-plugin uses pixel fonts to display icons. Some unused character numbers are assigend with those new "characters" to display a symbol of a dvd, directory,.... This looks very nice and is a great usability enhancement.
So i think something similar (integrating icons in the OSD) should be possible also in future VDR versions.
Greetings Thomas Wehrspann
On 05/28/07 20:59, Thomas Wehrspann wrote:
This wouldn't work with Freetype fonts, anyway.
So i think something similar (integrating icons in the OSD) should be possible also in future VDR versions.
I agree.
So I guess it's safe if I drop pixel fonts altogether. Anti-aliased freetype fonts really do look good ;-)
Klaua
Hi,
Klaus Schmidinger wrote:
vdr-xine can handle 16 fullscreen OSD areas with independent 256 color palettes. The only drawback is, that some of xine's video output devices only support overlays with 16 colors.
I hope that there will be an option to still get the "plain old" 16 color STNG OSD. Or will it depend on the result of cOsd::CanHandleAreas()?
Bye.
On 05/29/07 22:05, Reinhard Nissl wrote:
Here's how it will be handled:
osd = cOsdProvider::NewOsd(Setup.OSDLeft, Setup.OSDTop); tArea Areas[] = { { x0, y0, x7 - 1, y7 - 1, 8 } }; if (Setup.AntiAlias && osd->CanHandleAreas(Areas, sizeof(Areas) / sizeof(tArea)) == oeOk) { osd->SetAreas(Areas, sizeof(Areas) / sizeof(tArea)); osd->SetAntiAliasHint(9, 7); } else { tArea Areas[] = { { x0, y0, x7 - 1, y7 - 1, 4 } }; if (osd->CanHandleAreas(Areas, sizeof(Areas) / sizeof(tArea)) == oeOk) osd->SetAreas(Areas, sizeof(Areas) / sizeof(tArea)); else { tArea Areas[] = { { x0, y0, x7 - 1, y3 - 1, 2 }, { x0, y3, x3 - 1, y4 - 1, 1 }, { x3, y3, x4 - 1, y4 - 1, 2 }, { x4, y3, x7 - 1, y4 - 1, 2 }, { x0, y4, x7 - 1, y7 - 1, 4 } }; osd->SetAreas(Areas, sizeof(Areas) / sizeof(tArea)); } }
There's a global Setup.AntiAlias option through which the user can turn off anti-aliasing. In that case it immediately falls back to 4bpp. If Setup.AntiAlias is on, it tries to use 8bpp and falls back to 4bpp if that's not possible.
osd->SetAntiAliasHint(9, 7) tells the OSD how many colors will be used at all, and how many color combinations will be used with anti-aliasing. That way the OSD can evenly distribute the available palette entries to the various color blends by limiting the number of color levels per color combination.
Klaus
-
Anssi Hannula -
Klaus Schmidinger -
Reinhard Nissl -
Thomas Wehrspann -
Torgeir Veimo