Pekka Paalanen wrote:
This seems pretty limiting to me. What happens when *all* the outputs
are hi-res? You really think wayland clients should not be able to take
full advantage of this?
Then the individual pixels are so small that it won't matter.
It does not matter how tiny the pixels are. The step between possible
surface sizes and subsurface positions remains the size of a scale-1
unit. Or else I am seriously mis-understanding the proposal:
Let's say the output is 10,000dpi and the compositor has set it's scale
to 100. Can a client make a buffer that is 10,050 pixels wide appear 1:1
on the pixels of this output? It looks to me like only multiples of 100
are possible.
If nothing else it makes it so that subsurfaces are
always positioned on integer positions on non-scaled displays, which
makes things easier when monitor of differen scales are mixed.
This is false if the subsurface is attached to a scaled parent surface.
Huh?
Parent surface uses the scaler api to change a buffer width of 100 to
150. The fullscreen and this hi-dpi interface can also produce similar
scales. The subsurface has a width of 51. Either the left or right edge
is going to land in the middle of an output pixel.
The input rectangle to the scaler proposal is in the space between the
buffer transform and the scaling. Therefore there are *three* coordinate
spaces.
Where did you get this? Where is this defined or proposed?
The input rectangle is in the same direction as the output rectangle
even if the buffer is rotated 90 degrees by the buffer_transform.
On a quick thought, that seems only a different way of doing it,
without any benefits, and possibly having cons.
Benefits: the buffer can be any integer number of pixels in size,
non-integer buffer sizes cannot be specified by the api, you can align
subsurfaces with pixels in the buffer (which means a precomposite of
subsurfaces into the main one before scaling is possible).
Actually, it means that the surface coordinate system can change
dramatically when a client sends a new buffer with a different scale,
which then raises a bucketful of races: is an incoming event using new
or old surface coordinates? That includes at least all input events
with a surface position,
This is a good point and the only counter argument that makes sense.
All solutions I can think of are equivalent to reporting events in the
output space, the same as your proposal. However I still feel that the
surface size, input area, and other communication from client to server
should be specified in input space.
and the shell geometry event.
Geometry is in the space of the parent surface, not this surface. This
is true in both proposals. Both would get exactly the same geometry events.
For the record, wl_surface.attach changes the surface coordinate system
by translating with x,y, but that is not a problem. The x,y do not
describe how the surface moves, they describe how pixel rows and
columns are added or removed on the edges.
If x,y is in buffer pixels then it matches my proposal. It can change
the results of the scaler to non-integers then, so I was under the
impression it would be ignored in this case. Assuming logical use of the
hi-dpi I don't see a problem with it being in buffer pixels then.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
