<html><head></head><body>I am not interested in beating dead horses. Lock/unlock callbacks are broken. Failing resize is broken. Those problems have been discussed to death several times already.<br><br><div class="gmail_quote">Le 18 janvier 2019 10:16:20 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 17/01/2019 16:59, 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;">Le torstaina 17. tammikuuta 2019, 16.34.08 EET Steve Lhomme a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">On 16/01/2019 16:59, Rémi Denis-Courmont wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">Le keskiviikkona 16. tammikuuta 2019, 14.33.52 EET Steve Lhomme a écrit :<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #fcaf3e; padding-left: 1ex;"> OK so the documentation of "has_pictures_invalid" needs to be changed.<br> vout_display_SendEventPicturesInvalid() indirectly calls<br> VOUT_DISPLAY_RESET_PICTURES which is also what happens when a<br> resize/crop/etc error occurs but synchronously.<br><br> So has_pictures_invalid means the display handles<br> VOUT_DISPLAY_RESET_PICTURES.<br></blockquote>It rather means that the display may need VOUT_DISPLAY_RESET_PICTURES.<br>Though in practice, it only really affects pool allocation, and should be<br>irrelevant if the display uses push-buffers.<br></blockquote>"if the display uses push buffers" yes. But there are some cases where<br>it's not possible. In many display modules the display pool has its own<br>lock/unlock callbacks.<br></blockquote>I stopped reading here.<br></blockquote><br>That's not a correct way of handling comments on your code. I was <br>explaining the changes you made on VOUT_DISPLAY_CHANGE_xxx to reset the <br>display introduced the error you complained about. My code just exhibits <br>the issue more often.<br><br>Also in general ignoring an error is a bad coding practice. I am <br>proposing to handle the case where resizing a buffer fails (which can <br>happen, since it happened to you).<br><br><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">Lock/unlock has been flaky, not to say plainly broken,<br>for as long as I remember - which is at least as long as picture_pool_t<br>existed. I don't recall if/how the callbacks worked before.<br></blockquote>The lock/unlock of the memory is still going to be needed. It may be <br>possible to fake direct rendering in these (if you read the whole thing <br>you would have seen it's only an issue in "indirect" rendering) and do <br>the lock/copy/unlock during the Prepare. Many of these modules <br>(direct3d9, direct3d11, android opengl/display, mmal) currently do it on <br>more than one picture though. There could be tearing issues if there's <br>no double buffering involved. It will have to be handled internally by <br>each module.<br><br>So in the long run it may be better, I don't think it's mandatory change <br>needed for the push model. At least it works without for me.<br><br>BTW, I mentioned that mmal handles lock and VOUT_DISPLAY_RESET_PICTURES <br>but that's not the case.<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>