summaryrefslogtreecommitdiffstats
path: root/player/video.c
diff options
context:
space:
mode:
authorwm4 <wm4@nowhere>2020-05-22 14:24:16 +0200
committerwm4 <wm4@nowhere>2020-05-22 14:24:16 +0200
commitd62131d3aeda6f3b4c255ca06e70573433a8f16a (patch)
tree8a902caabc1887810172611b67360ece06d505b4 /player/video.c
parent77f730f63c340fc88e8c3db0cb73cff1807d7432 (diff)
downloadmpv-d62131d3aeda6f3b4c255ca06e70573433a8f16a.tar.bz2
mpv-d62131d3aeda6f3b4c255ca06e70573433a8f16a.tar.xz
vo_x11: allow OSD rendering outside of video region
I'm not sure why it only rendered OSD inside the video. Since OSD rendering was always done on the X image (after software scaling and color conversion), there was no technical reason for this. Maybe it was because the code started out this way, and it was annoying to change it. Possibly, one reason was that it didn't normally have to clear the black bars in every frame (if video didn't cover the entire window). Anyway, simply render OSD to the full window. This gets rid of some rather weird stuff. It seems to look mostly like vo_wlshm now. The uncovered regions are cleared every frame, which could probably be avoided by being clever with the OSD renderer code, but this is where I'm decidedly losing interest. There was some mysterious code for aligning the image width to 8 pixels. Replace that by attempting to align it to SIMD alignment (might matter for libswscale, or if repack.c gets SIMD). Why are there apparently 4 different ways representing a pixel format (depth, VisualID, Visual, XVisualInfo), but none of them seem to provide the XImage.bits_per_pixel value (the actual size of a pixel, including padding)? Even after 33 years, X11 still seems overengineered, confusing, and inconvenient. So just call X11 a heap of shit, and assume the worst case for alignment.
Diffstat (limited to 'player/video.c')
0 files changed, 0 insertions, 0 deletions