Re: Fix for visible OSD corruption

su, 2020-07-12 kello 14:48 +1000, [email protected] kirjoitti:
> > > When C-i is used to view stream information via OSD then often
> > > corruption appears after the "Audio:" prefix.
> > 
> > Made a better fix (I think). Thanks.
> > 
> 
> On the same topic, having a timeout on OSD display for
> seek position makes sense when one performs a seek.
> But when one deliberately chooses to display OSD, especially
> stream information, then that really should be an on/off
> toggle totally controlled by the user without any timeout.

Agreed.

Another nice idea I saw was using some effects when showing and hiding
the OSD (like, moving it in/out from outside of display, scaling from
Z-direction, fading out, ...).

> Also, scaling of OSD has a lot wrong with it, especially
> in fullscreen mode.

I think scaling the OSD should be avoided when ever possible. OSD
should use output display resolution.

I've been thinking about extending xine-lib OSD code with some kind of
basic "widgets" layer. Then OSD could be re-rendered when output size
changes (ex. window<->fullscreen). It could also hide physical pixels
and use relative sizes (or scale coordinates before rendering). Low-
level OSD implementation could be hidden from upper levels (=ARGB,
palette-based, unscaled, ...).
I even tried extending the idea with user input, and implemented simple
mouse-controllable seek bar prototype using this approach. But I'm not
a GUI designer so it is more or less a technology demo / prototype :)


Similar relative size fix should be applied to text subtitles ; sizes
"small", ..., "large" should be scaled to match output resolution. Even
the largest size is quite small when rendered on top of 4k video. And
it is very annoying if the size does not scale automatically when
changing between window/fullscreen or even between different resolution
videos.

And, if someone has extra time to spent on this, DVB/... bitmap
subtitles could use different scaling algorithm. It should be possible
to use some simple edge-detecting algorithm that doesn't blur subtitles
...

>  And unscaled is not the right fix because
> it renders poorly.

For better quality one could use argb layer OSD with output display
resolution. But it is not available with every output plugin. On the
other hand, OpenGL should be quite widely available nowdays, so I don't
know if we should use lot of effort for older output methods ...

Maybe xine-lib osd could be changed to use argb layer automatically
when available. This is kind of "unscaled" OSD too.

>  I have a patch which effectively preforms
> an unscaled effect by counter-adjusting text before scaling,
> without any render glitches. But I will not submit it at
> this stage because there is still a lot of awfulness everywhere
> (ie. hard-coded pixel sizes instead of pt sizes etc, especially in
> xitk/osd.c).

You could send it as some kind of "RFC" patch, even if it doesn't work
yet ?

Also, you could consider fixing / extending underlying xine-lib OSD
too, when it makes any sense (= improves OSDs from inside xine-lib,
like subtitles).

> Was ok in 2001, but resolutions have changed dramatically
> since then.

I think GUI should use relative sizes everywhere and have some kind of
automatic scale factor + user override. Currently it is either too
small or blurry with HiDPI displays. But this requires quite much
changes. I've started isolating X11 stuff, so that maybe one day it is
possible to use OpenGL to render the gui, without X server / XWayland
scaling the output window ...

Currently video output can use Wayland surface, and it seems to improve
video sharpness and details a lot - as expected, because of X11 window
is first rendered at lower resolution (= downscaling the video), and
then upscaled by XWayland. And this doesn't blur only hi-res video, it
blurs all video.

> :JW
> 
> 
> 
> _______________________________________________
> xine-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/xine-devel