<!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>> Of course not. The display is expected to pick a scale
according to VLC video settings.</p>
<p>The *default* scale, whether fetched from the settings, or from
the interface window in embedding case, is supposed to come from
the (same) environment (depending on high DPI display, for
example). And this default value would naturally match for
different windows in the same screen, the interface window or the
video window. Of course, it can deviate if overridden by the user,
but by default they should match so as embedded window fits
perfectly. We should not present the user a situation where the
video window exceeds the boundaries of the interface window, by
default.<br>
</p>
<p>> That's how it's supposed to work. That's how it works for
all other displays, all other providers, Win32 and X11, and how
the core makes its calculations.<br>
> If you don't respect that convention, this is 100% a bug in
the Qt module. I shouldn't have to explain something like that.<br>
</p>
<p>If we do that, we lose information. The video window can no
longer know the scale, so technically we can not support high dpi.
How does the OSD behave in high dpi scenario, for example, without
knowing the scale?<br>
</p>
<p>> You can't add restrictions on how the display module is
using the surface for rendering.</p>
<p>I wanted to mean not for rendering, but for something that
legitimately concerns both the display module and the window
provider. I just mean that if they are not compatible, it does not
mean that one might go. As I said, "If in some situations video
embedding is not possible, they should not be enabled or offered
when the interface is used.".</p>
</body>
<lt-container></lt-container>
</html>