<!DOCTYPE html><html data-lt-installed="true"><head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body style="padding-bottom: 1px;">
<p>> Who said you shouldn't use the viewporter for the interface?
You just can't instantiate it for the video surface.</p>
<p>Qt itself uses it for the interface surface since version 6.5.
The video surface, when embedded, is expected to use the same
scale the interface surface uses so that it fits perfectly. Thomas
has previously provided a screenshot for this in
<a class="moz-txt-link-freetext" href="https://code.videolan.org/videolan/vlc/-/merge_requests/5721#note_446336">https://code.videolan.org/videolan/vlc/-/merge_requests/5721#note_446336</a>.</p>
<p>> VLC doesn't support fractional video window dimensions
anyway, because that would be totally overkill.</p>
<p>By fractional scale, I don't necessarily mean fractional size.
There can be a big difference between, let's say, 1.0 and 1.5
scale, depending on the size.</p>
<p>One might say, why not report the size as `size * scale` instead
of using viewporter. I did not want to couple size and scale, as
that can be quite problematic, and that goes against the
fractional scale protocol anyway. We should probably add a "scale"
field to window structure, and introduce
`vlc_window_ReportScale()` and not handle scaling in the
interface.</p>
<p>> That's a server/driver restriction, not a provider
restriction.</p>
<p>I say that with proper justification, provider can impose
additional restriction (only) when it is used. Imagine if there
was no such `EGL_KHR_display_reference` at all, then we would not
have EGL display just because some provider needs it?</p>
<p>> And SHM is supposed to be the one module that works on *any*
display server.</p>
<p>> If embedding is not possible then you can't provide an
embedded window. You don't get to provide a partially working
partially crashing backend</p>
<p>Yes, we should fix this. However, we need to decide how.</p>
</body>
<lt-container></lt-container>
</html>