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.alsa...@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@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
