<html><head></head><body>It sounds rather schizophrenic for a LibVLC app to ask for a size that its own backend cannot handle... And anyway, VLC core does not have means to rollback a vout size change as of yet.<br><br><div class="gmail_quote">Le 18 janvier 2019 11:50:39 GMT+02:00, Steve Lhomme <robux4@ycbcr.xyz> a écrit :<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 18/01/2019 10:38, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">You cannot have direct rendering with invalid pictures. The vout <br>wrapper will force non-DR in the later case.<br></blockquote><br>Agreed.<br><br>><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">And all I'm saying is that resizing a display cannot fail, at least <br>not on X11 and Win32. <br></blockquote><br>But the patches (and following ones) are about "window less" rendering, <br>in an external texture or whatever you want.<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">If you cannot handle a given size, you have to ensure that the window <br>provider will never report it, by whatever means.<br></blockquote><br>In OpenGL it may work to ignore what a client app does, but in D3D9 and <br>D3D11 it will not work. So I could return an error in the general <br>callback and ignore it for OpenGL (even though it seems wrong to me).<br><br>><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"> Le 18 janvier 2019 10:39:31 GMT+02:00, Steve Lhomme <robux4@ycbcr.xyz> <br> a écrit :<br><br>     On 17/01/2019 17:06, Rémi Denis-Courmont wrote:<br><br>         Le torstaina 17. tammikuuta 2019, 17.46.15 EET Steve Lhomme a<br>         écrit :<br><br>             On 16/01/2019 12:41, Rémi Denis-Courmont wrote:<br><br>                 This is obviously wrong since it ends with an<br>                 assertion failure at opengl/display.c:228. And thus<br>                 the commits before it make no sense. <br><br>             It asserts there because it's not meant to handle<br>             VOUT_DISPLAY_RESET_PICTURES. And it receives that because<br>             during a<br>             VOUT_DISPLAY_CHANGE_DISPLAY_SIZE/VOUT_DISPLAY_CHANGE_DISPLAY_FILLED/VOUT_DIS<br>             PLAY_CHANGE_ZOOM it returned an error from a call to<br>             vlc_gl_Resize(). If the code is not ready to handle such<br>             an error (why it occurs for you is another thing to look<br>             at) then it will also assert on the call right after:<br>             if(vlc_gl_MakeCurrent(sys->gl)!=VLC_SUCCESS)<br>             returnVLC_EGENERIC; So I don't see how the commit is<br>             wrong. Either the DISPLAY_CHANGE_* events can never return<br>             an error from there, or the code needs to be ready to<br>             handle it. <br><br>         Returning an error from those controls just means you need to<br>         reset the display input format, <br><br><br>     This wasn't clear to me.<br><br>         and the pool if the display was not ported yet. <br><br><br>     The display pool ? What if direct rendering is on ? That means the<br>     decoder pool as well. Right now the comment you added says "internal<br>     buffers" that's rather vague.<br><br>         Returning an error does *not* mean that you reject the change.<br>         You *cannot* reject the change. It simply does not work and<br>         cannot that way. Since the control is dispatched<br>         asynchronously, it is too late to reject the change. I am<br>         planning to address that for other reasons than error<br>         handling, but even then, most (all except maybe Wayland)<br>         windowing systems lack provisions for rejecting a window size<br>         change. So if you have a failure at that stage, then you have<br>         two options: - render wrong going forward, or - stop rendering<br>         and discard pictures until further notice. Either way, you<br>         don't need to return an error to the core. <br><br>     That would be true if OpenGL wasn't handled in the core. But this<br>     function clearly returns whether the surface dimensions were succesfully<br>     changed:<br>     <a href="http://git.videolan.org/?p=vlc.git;a=blob;f=src/video_output/opengl.c;h=c288fd83b429dfeaabdef4432dfacc96650e5c80;hb=HEAD#l173">http://git.videolan.org/?p=vlc.git;a=blob;f=src/video_output/opengl.c;h=c288fd83b429dfeaabdef4432dfacc96650e5c80;hb=HEAD#l173</a><br><br>     Telling it that it worked when it didn't will not do any good.<hr>     vlc-devel mailing list<br>     To unsubscribe or modify your subscription options:<br>     <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br><br><br> -- <br> Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez <br> excuser ma brièveté.<hr> vlc-devel mailing list<br> To unsubscribe or modify your subscription options:<br> <a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a><br></blockquote><hr>vlc-devel mailing list<br>To unsubscribe or modify your subscription options:<br><a href="https://mailman.videolan.org/listinfo/vlc-devel">https://mailman.videolan.org/listinfo/vlc-devel</a></pre></blockquote></div><br>-- <br>Envoyé de mon appareil Android avec Courriel K-9 Mail. Veuillez excuser ma brièveté.</body></html>