<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
</head>
<body text="#000000" bgcolor="#FFFFFF">
Hello,<br>
<br>
On 11/12/2017 18:19, Rémi Denis-Courmont wrote:<br>
<blockquote type="cite"
cite="mid:18013107.bpO08FYjDW@basile.remlab.net">
<pre wrap=""> Hello,
The second patch does not look correct at all to me. I don't see why we should
assume that the window expands solely right and down. glViewport() manages the
mapping of OpenGL coordinates to window coordinates.</pre>
</blockquote>
The (x,y) parameters required in wl_egl_window_resize() are those
used in wl_surface_attach(), and they are a bit misleading<br>
<br>
Doc says : <span style="color: rgb(0, 0, 0); font-family:
"liberation sans", "Myriad ", "Bitstream
Vera Sans", "Lucida Grande", "Luxi Sans",
"Trebuchet MS", helvetica, verdana, arial, sans-serif;
font-size: 14px; font-style: normal; font-variant-ligatures:
normal; font-variant-caps: normal; font-weight: 400;
letter-spacing: normal; orphans: 4; text-align: start;
text-indent: 0px; text-transform: none; white-space: normal;
widows: 4; word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); text-decoration-style:
initial; text-decoration-color: initial; display: inline
!important; float: none;">"The x and y arguments specify the
location of the new pending buffer's upper left corner, relative
to the current buffer's upper left corner, in surface-local
coordinates. In other words, the x and y, combined with the new
surface size define in which directions the surface's size
changes."<br>
<br>
Reality is : it should read : "</span><span style="color: rgb(0,
0, 0); font-family: "liberation sans", "Myriad
", "Bitstream Vera Sans", "Lucida
Grande", "Luxi Sans", "Trebuchet MS",
helvetica, verdana, arial, sans-serif; font-size: 14px;
font-style: normal; font-variant-ligatures: normal;
font-variant-caps: normal; font-weight: 400; letter-spacing:
normal; orphans: 4; text-align: start; text-indent: 0px;
text-transform: none; white-space: normal; widows: 4;
word-spacing: 0px; -webkit-text-stroke-width: 0px;
background-color: rgb(255, 255, 255); text-decoration-style:
initial; text-decoration-color: initial; display: inline
!important; float: none;"><span style="color: rgb(0, 0, 0);
font-family: "liberation sans", "Myriad ",
"Bitstream Vera Sans", "Lucida Grande",
"Luxi Sans", "Trebuchet MS", helvetica,
verdana, arial, sans-serif; font-size: 14px; font-style: normal;
font-variant-ligatures: normal; font-variant-caps: normal;
font-weight: 400; letter-spacing: normal; orphans: 4;
text-align: start; text-indent: 0px; text-transform: none;
white-space: normal; widows: 4; word-spacing: 0px;
-webkit-text-stroke-width: 0px; background-color: rgb(255, 255,
255); text-decoration-style: initial; text-decoration-color:
initial; display: inline !important; float: none;">In other
words, the x and y, combined with the new surface size define in
which directions <u>the surface moves</u>."<br>
<br>
</span></span>Actually, when you provide the (x,y) parameters via
wl_egl_window_resize(), you're requesting the EGL library to move
the original display by (x,y) during their next wl_surface_attach().
This is wrong as the original display belongs to the qt interface
with its internal placement strategy and must not be tampered with.
The EGL library also needs the size of the original display to
render the right buffer size. Unlike X, Wayland doesn't offer a
means to query/to register the server to get updated about the size
of an existing window. This is the reason why wl_egl_window_resize()
is needed for Wayland but not for X.<br>
<br>
Please, just give a try to the patches. You'll see that without the
patches, the video widget moves around a lot (because of these (x,y)
parameters). With the patch, everything stays in place and is fully
OK (resize, crop, aspect ratio, ...). You even benefit from a clean
video while resizing, which was impossible in Opengl with an X
server. A first benefit that was a promise of Wayland !<br>
<br>
As a side note, this misuse of the (x,y) parameter also exists in
wl_surface_attach() in the wl vout display. You cannot use them to
place the video inside a given window. With the qt interface, you
just end up moving the video widget outside the vlc interface where
it belongs. But a fix for the wl vout display is more complicated to
do. I guess the only way to solve it is via an additional
subsurface, that you can position wrt to the original display. But
Wayland is more basic (too basic?) than X with these things.<br>
<br>
<blockquote type="cite"
cite="mid:18013107.bpO08FYjDW@basile.remlab.net">
<pre wrap="">
And the third patch looks like a kludge rather than a fix, TBH.</pre>
</blockquote>
I do agree. This patch was added just in case somebody wanted to
test the result of the other two patches right away.<br>
<br>
Rgds<br>
<br>
<br>
<br>
<div id="DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2"><br /> <table style="border-top: 1px solid #D3D4DE;">
<tr>
<td style="width: 55px; padding-top: 18px;"><a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank"><img src="https://ipmcdn.avast.com/images/icons/icon-envelope-tick-round-orange-animated-no-repeat-v1.gif" alt="" width="46" height="29" style="width: 46px; height: 29px;" /></a></td>
<td style="width: 470px; padding-top: 17px; color: #41424e; font-size: 13px; font-family: Arial, Helvetica, sans-serif; line-height: 18px;">Garanti sans virus. <a href="https://www.avast.com/sig-email?utm_medium=email&utm_source=link&utm_campaign=sig-email&utm_content=emailclient" target="_blank" style="color: #4453ea;">www.avast.com</a> </td>
</tr>
</table>
<a href="#DAB4FAD8-2DD7-40BB-A1B8-4E2AA1F9FDF2" width="1" height="1"> </a></div></body>
</html>