[PATCH 00/15] weston scaling support

[Jason Ekstrand]

On Mon, Jun 3, 2013 at 3:21 PM, Bill Spitzak <spitzak at gmail.com> wrote:

> It appears John Alsaker is proposing exactly the same change I have been
> proposing. I think we are having a hard time explaining it however.
>
>
> Pekka Paalanen wrote:
>
>> On Tue, 28 May 2013 19:27:35 +0200
>> John Kåre Alsaker <john.kare.alsaker at gmail.com> wrote:
>>
>>  My proposal is simply to let the compositor tell the client how much
>>> larger
>>> it wants the client to render content. The client can then tell the
>>> compositor how much larger it made content in the window. Armed with this
>>> information the compositor can size the window accordingly.
>>>
>>
>> How would this look in protocol? Just roughly, what requests and events
>> would be involved. Especially, how does the compositor know to suggest
>> a size?
>>
>
> It would look *EXACTLY* the same as how the compositor currently tells
> clients about the output scale.
>
>
>  I think they may have issues. A surface pel may not cover an integer
>> amount of pixels in both buffer and output. Or how do you arrange that?
>>
>
> In John's proposal a "pel" *EQUALS* a buffer pixel. It is always an
> integer number of pixels in buffer space, no matter what scale is chosen.
> The fact that you don't see this means that somehow John is not explaining
> his design well enough, and perhaps that is why there is resistance to it?
> But it seems pretty obvious to me.
>
> The current scale proposal allows a "pel" to be a non-integer in both
> buffer and output space. The easiest way is to put a surface with a scale
> of 3 on an output with a scale of 2.
>
>
>  + Output sizes do not have to be a multiple of the scaling factor.
>>>
>>
> I think this may be useful for tablets? But it turns out that large
> monitor sizes have been designed to allow integer scales of smaller sizes.
> For instance 1920x1080 has common factors of 2,2,2,3,5, meaning any integer
> scale that is a multiple of any set of those factors will work.
>
> However if there is any kind of "panel" on the edge of the monitor there
> are going to be problems with maximized windows because the reduced size is
> going to have much fewer factors, or the panel is going to be restricted to
> large increments in size that may mean only ugly sizes are possible.
>
>
>  + Clients can specify their size in pixels exactly.
>>>
>>
> The biggest problem with the scale proposal is that the sizes and
> positions of windows are restricted to visibly large steps, thus defeating
> the whole point of high-dpi displays.
>
>
>  + 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. And I'm worried that high-resolution
> pointing devices will be ignored by clients that immediately round to the
> nearest buffer pixel.
>
>
>  I don't really get the above.
>>
>
>  There are however some downsides:
>>> - Clients may need to transform input events in order to match the
>>> coordinates used by applications.
>>>
>>
>> So this is a minus here, but the same wrt. buffers was a plus. And it's
>> the application that first deals with input events, and then decides
>> what to draw. I don't think input goes directly to drawing machinery.
>>
>
> I think the assumption that the application is working in "pels" is
> simplistic. We *KNOW* that part of the application is working in buffer
> pixels (ie the drawing code). It should use a coordinate system that is
> known to mean something to the application.
>
>
>  - 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 don't expect GTK or other (ancient) toolkits to do fractional scaling
>>> and
>>> reap all the benefits listed here. I don't want anything in the core
>>> protocol blocking the ability for clients to scale smoothly up though
>>> when
>>> clients will actually be able to do this.
>>>
>>
>> You listed some features, but I still have no idea what you are
>> suggesting.
>>
>
> I think is is incredibly obvious what the advantages of his scheme are.
> The fact that you cannot see it is really mystifying.
>
> ______________________________**_________________
> wayland-devel mailing list
> wayland-devel at lists.**freedesktop.org<wayland-devel at lists.freedesktop.org>
> http://lists.freedesktop.org/**mailman/listinfo/wayland-devel<http://lists.freedesktop.org/mailman/listinfo/wayland-devel>
>

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).

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.

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.

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.

Food for thought,
--Jason Ekstrand
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.freedesktop.org/archives/wayland-devel/attachments/20130603/9fe7e7f0/attachment-0001.html>