On 05/20/2013 11:46 PM, Pekka Paalanen wrote:
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.
As far as I understand, that is correct.
But it does not matter. You cannot employ any widgets or widget parts
that would need a finer resolution than 100 px steps, because a) the
user cannot clearly see them, and b) the user cannot clearly poke them
with e.g. a pointer, since they are so small. So there is no need to
have window size in finer resoution either. Even a resize handle in a
window border would have to be at least 300 pixels thick to be usable.
This proposal does not actually restrict widget positions or line sizes,
since they are drawn by the client at buffer resolution. Although
annoying, the outside buffer size is not that limiting. The client can
just place a few transparent pixels along the edge to make it look like
it is any size.
However it does restrict the positions of widgets that use subsurfaces.
I see this as a serious problem and I'm not sure why you don't think it
is. It is an arbitrary artificial limit in the api that has nothing to
do with any hardware limits.
The reason you want to position widgets at finer positions is so they
can be positioned evenly, and so they can be moved smoothly, and so they
can be perfectly aligned with hi-resolution graphics.
How can you say that? Where did you get the specification of how scaler
interacts with buffer_scale? We didn't write any yet.
It is pretty obvious that if the parent has a scale and the child has
one, these scales are multiplied to get the transform from the child to
the parent's parent.
It is true that the resulting scale if the hi-dpi and scaler are applied
to the *SAME* surface is not yet written.
And what is this talk about parent surfaces?
The subsurfaces have a parent. For main surfaces the parent is the
compositor coordinate space.
The input rectangle is in the same direction as the output rectangle
even if the buffer is rotated 90 degrees by the buffer_transform.
Yes exactly. Thus it is a different space than the buffer pixels, as
there may be a 90 degree rotation / reflections, and translation to put
the origin in different corners of the buffer.
How could you ever arrive to non-integer buffer sizes in the earlier
proposal?
If the scale is 3/2 then specifying the surface size as 33 means the
buffer is 49.5 pixels wide. I guess this is a protocol error? Still
seems really strange to design the api so this is possible at all.
Aligning sub-surfaces is still possible if anyone cares about that, one
just have to take the scale into account. That's a drawing problem. If
you had a scale 1 output and buffers, you cannot align to fractional
pixels, anyway.
If there is a scale of 2 you cannot align to the odd pixels. And a
scale of 3/2 means you *can* align to fractional pixels.
Why would pre-compositing not be possible is some case?
Because it would require rendering a fractional-pixel aligned version of
the subsurface and compositing that with the parent. This may make
unwanted graphics leak through the anti-aliased edge. The most obvious
example is if there are two subsurfaces and you try to make their edges
touch.
However both proposals have this problem if pre-compositing is not done,
and most practical shells I can figure out can't do pre-compositing
because that requires another buffer for every parent, so maybe this is
not a big deal.
Urgh, so you specify input region in one coordinate system, and then
get events in a different coordinate system? Utter madness.
Let's keep everything in the surface coordinates (including client
toolkit widget layout, AFAIU), except client rendering which needs to
happen in buffer coordinates, obviously.
Sounds like you have no problem with two coordinate spaces. I don't see
any reason the size of windows and the positions of graphics should not
be done in the same coordinates drawings are done in.
The x,y do not
describe how the surface moves, they describe how pixel rows and
columns are added or removed on the edges.
No, it is in the surface coordinate system, like written in the patch.
Then I would not describe it as "pixel rows and columns added or removed
on the edges". If the scaler is set to 70/50 than a delta of -1,0 is
adding 1.4 pixels to the left edge of the buffer. I agree that having it
in the parent coordinates works otherwise.
_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel
