<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">On 30 March 2013 13:34, Matthias Clasen <span dir="ltr"><<a href="mailto:matthias.clasen@gmail.com" target="_blank">matthias.clasen@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On Sat, Mar 30, 2013 at 7:56 AM, Daniel Stone <span dir="ltr"><<a href="mailto:daniel@fooishbar.org" target="_blank">daniel@fooishbar.org</a>></span> wrote: </div>
<div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr"><div class="gmail_extra">
<div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Various input events have a time field. The spec doesn't really say<br>
anything about this. What is it good for, and what units are these -<br>
monotonic time ?<br></blockquote><div><br></div></div><div>Monotonic (ideally) time in an undefined domain, i.e. they're only meaningful on relation to each other.</div></div></div></div>
</blockquote><div><br></div></div><div>What can you do with them ? For the use case that Giulio mentioned (double-click detection), I'd need to know at least if the difference between two times is seconds or milliseconds or microseconds...<br>
</div></div></div></div></blockquote><div><br></div><div style>Oh sorry, milliseconds. Just with an undefined base, i.e. they don't necessarily correlate to gettimeofday() or CLOCK_MONOTONIC.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div></div><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">
<div class="gmail_extra"><div class="gmail_quote"><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Still on popups, I don't see a way for the client to dismiss the<br>
popup, or is that handled by just destroying the surface ?<br></blockquote><div><br></div></div><div>Indeed, just destroy the surface or attach a NULL buffer.</div></div></div></div></blockquote><div><br></div></div><div>
Good to know. I don't think the spec mentions at all that 'attach NULL buffer' == unmap.</div></div></div></div></blockquote><div><br></div><div style>Mapping rules are specific to the surface type, but yes, indeed I can't think of any surface roles where that isn't the case.</div>
<div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="im"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
- Buffer transformations - fun. How do these relate to each of the following ?<br>
- resize edges<br>
- transient offset<br>
- buffer attach x/y<br>
- input/opaque/damage regions<br>
- surface x/y in motion events<br></blockquote><div><br></div></div><div>All the latter occur on surfaces rather than buffers, so are unaffected. Buffer transforms are meant to support situations like where your screen is rotated 90°, and your client can also render rotated in order to avoid that extra blit. So it doesn't affect the event pipeline at all, only the display pipeline.</div>
</div></div></div></blockquote><div><br></div></div><div>That sounds right for resize edgets and motion events, certainly. For some of the others, at least the wording of the spec is not always very clear on this point. E.g. for buffer attach x/y, the wl_surface.attach docs say:<br>
<br> The x and y arguments specify the location of the new pending<br> buffer's upper left corner, relative to the current buffer's<br> upper left corner. <br><br></div><div>See how it talks about the current buffer's upper left corner. Should that say 'the surface's upper left corner, then ?</div>
</div></div></div></blockquote><div><br></div><div style>Yeah, except the wording to be a little more subtle to clarify that that the position change happens a) in surface co-ordinates, and b) when the buffer is attached. But this is the one I'm least sure about, in all honesty. :) <br>
</div></div><br></div><div class="gmail_extra" style>Cheers,</div><div class="gmail_extra" style>Daniel</div></div>