
<html><head></head><body>Hi,<br><br>There are several problems with that fast-path approach.<br><br>1) If the mouse changes between the time of (fast) check and the time of render, it will be postponed by one frame interval. Not great for reactivity. Generally speaking, handling render timing differently with and without mouse events feels rather dangerous.<br><br>2) Some, if not all, mouse events cannot be merged. It's obvious for press and release. But it also applies for movement, if a filter checks for gestures.<br><br><div class="gmail_quote">Le 18 août 2020 07:12:35 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 2020-08-17 20:31, 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;">Hi,<br><br>I don't understand why atomic_bool here.<br></blockquote><br>So we don't need to take a lock to check if we need to wait in <br>ThreadDisplayPicture(). (and release it while before we wait or if we don't)<br><br>I don't have a strong feeling for either ways. The display_lock is <br>already used for a lot of cases, so one more is not a big deal.<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>