On Mon, Jun 3, 2013 at 10:21 PM, Bill Spitzak <spit...@gmail.com> wrote:
> + Clients get input in exact pixels (no rounding errors). >> + Clients doesn't have to transform input events in order to match the >> sizes used by buffers. > > You said "pels" don't match buffer pixels. Therefore a transformation is > needed to get to buffer pixels. Clients can choose if this transformation is used. > And I'm worried that high-resolution pointing devices will be ignored by > clients that immediately round to the nearest buffer pixel. Presumably they wouldn't use the high-resolution for anything then. I'm not sure how this relates to the topic either. > > - Clients changing scaling factors will have older input reported in the >>> old size. This will be quite rare although clients can deal with it if >>> desired. >>> - Requires an implementation <:) >>> >> > This seems to be the biggest actual objection, other than apparent > misunderstanding of the proposal. > > 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. > > 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. > I believe the frame callback event can be used to tell when you get the events from the new frame. On Mon, Jun 3, 2013 at 11:56 PM, Jason Ekstrand <ja...@jlekstrand.net>wrote: > 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. > > 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). > 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. > 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. > 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. > > 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. > The client can always resize the output of the library. It's just another side of thing 2 really. > 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. > 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. > > Food for thought, > --Jason Ekstrand >
_______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
