Klaus Schmidinger wrote:

On 05/27/07 19:11, Torgeir Veimo wrote:

...

On 27 May 2007, at 17:49, Klaus Schmidinger wrote:

...

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.

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.

I'd support resolution independency, as I run VDR xineliboutput at the native resolution of my LCD TV, i.e. 1366x768.

This has nothing to do with the question of dropping the pixel fonts. And since there is no actual DVB card available, yet, that could display any OSD on HDTV (let a lone HDTV at all), I'll cross that bridge when I get there.

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 05/28/07 20:59, Thomas Wehrspann wrote:

On Sunday 27 May 2007 18:49, Klaus Schmidinger wrote:

...

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.

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.

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

On 05/29/07 18:40, Torgeir Veimo wrote:

On 29 May 2007, at 17:16, Klaus Schmidinger wrote:

...

Anti-aliased freetype fonts really do look good ;-)

Have you tried either of the soft output methods (libxine, softdevice), or are you still running FF cards only?

I'm only running a FF card (with 4MB memory, so I can display the OSD with 256 colors).

Klaus

On 05/29/07 22:05, Reinhard Nissl wrote:

Hi,

Klaus Schmidinger wrote:

...

...

...

Anti-aliased freetype fonts really do look good ;-)

Have you tried either of the soft output methods (libxine, softdevice), or are you still running FF cards only?

I'm only running a FF card (with 4MB memory, so I can display the OSD with 256 colors).

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()?

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