<div dir="ltr"> On Mon, Jun 3, 2013 at 10:21 PM, Bill Spitzak <span dir="ltr"><<a href="mailto:spitzak@gmail.com" target="_blank">spitzak@gmail.com</a>></span> wrote:<br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> + Clients get input in exact pixels (no rounding errors).<br> + Clients doesn't have to transform input events in order to match the<br> sizes used by buffers.</blockquote></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> You said "pels" don't match buffer pixels. Therefore a transformation is needed to get to buffer pixels.</blockquote><div>Clients can choose if this transformation is used. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> And I'm worried that high-resolution pointing devices will be ignored by clients that immediately round to the nearest buffer pixel.</blockquote><div>Presumably they wouldn't use the high-resolution for anything then. I'm not sure how this relates to the topic either.</div> <div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><br> <br> <blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> - Clients changing scaling factors will have older input reported in the<br> old size. This will be quite rare although clients can deal with it if<br> desired.<br> - Requires an implementation <:)<br> </blockquote></blockquote> <br></div> This seems to be the biggest actual objection, other than apparent misunderstanding of the proposal.<br> <br> However the same problem applies for when a buffer attach is done with an x and y offset. The client does not know exactly what mouse events are pointing at unless it knows whether they are before or after the commit.<br> <br>So I now think a better solution is to have the compositor echo the commit in the event stream, so the client can easily tell whether events are before or after it. It is possible that existing events can be used to determine this.<br> </blockquote><div>I believe the frame callback event can be used to tell when you get the events from the new frame.</div><div><br><div class="gmail_quote">On Mon, Jun 3, 2013 at 11:56 PM, Jason Ekstrand <span dir="ltr"><<a href="mailto:jason@jlekstrand.net" target="_blank">jason@jlekstrand.net</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="gmail_extra">I think I'm begining to see what you and John have been suggesting. While I think Alexander's proposal will work well enough for the standard case, I think this also has merit. If I were to sum up, I'd say I was "cautiously supportive" of the above. It does seem to solve some of the edge-cases. That said, there are a few things I'd like to note.<br> <br></div><div class="gmail_extra">1. This requires a concept of a "window" which is one we currently don't have. If we put it in wl_surface, we have to define how it works for subsurfaces. We could say that the scale factor on subsurfaces gets ignored. However, this means that we have defined an extension-specific exception. What happens if we add another future extension that alters the window's size or orientation? This will get messy. We could put this in wl_shell_surface but then we are mixing the global (wl_output) with the desktop-specific (wl_shell_surface).<br> </div></div></blockquote><div>The concept of window I refer to is just regular a wl_surface really. With the subsurface extension added in it breaks this concept so an exception in this extension is required. This is just a side effect of adding subsurfaces as an afterthought and not having a separate window object in the protocol. I'm sure there's quite a few other things we can't do with subsurfaces already.</div> <div><br></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"> <br></div><div class="gmail_extra">2. This restricts subsurfaces to the same scaling factor as the original surface. Probably not a huge problem, but I'm not convinced it's a smaller restriction than requiring subsurfaces on pel-boundaries.<br> </div></div></blockquote><div>I don't think that's going to be a problem. If the client for some reason want to mix scaling factors, it can resize the subsurface itself.</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><div class="gmail_extra"><br></div><div class="gmail_extra">3. This makes the subsurface case of handing off to a library more complicated. In Alexander's implementation, the library would simply render at native resolution or not. With this, the client has to tell the library what surface scale to use and the library has to *EXACTLY* match. Maybe this isn't a huge issue, but there's no opportunity for a client to embed an older library.<br> </div></div></blockquote><div>The client can always resize the output of the library. It's just another side of thing 2 really.</div><div><br></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><div class="gmail_extra"><br></div><div class="gmail_extra">4. If a client presents a scale_factor to the compositor that is not an integer multiple of one of the ouput_scale factors provided by the compositor, it should not expect the compositor to do anything intelligent. There are similar problems with integer proposal, but this one makes it more interesting.<br> </div></div></blockquote><div>It should expect the compositor to resize the window accordingly to it's policies. The client remains blissfully unaware of whatever that has been done. I don't see how this is a issue with either proposal.</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><div class="gmail_extra"><br></div><div class="gmail_extra">Food for thought,<br></div><div class="gmail_extra">--Jason Ekstrand<br></div></div></blockquote></div></div></div>