[PATCH 00/15] weston scaling support

[John Kåre Alsaker]

 On Mon, Jun 3, 2013 at 10:21 PM, Bill Spitzak <spitzak at 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 <jason at 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130604/3360c629/attachment-0001.html>