On Thu, 14 Nov 2013 12:27:22 -0800 Bill Spitzak <spit...@gmail.com> wrote:
> Pekka Paalanen wrote: > > > Yes, you cannot use non-integer surface sizes. You cannot express a > > surface size, that would result in a 1024x1024 area in output pixels, > > because 1024 is not divisible by output_scale=3. > > Thanks. That is indeed exactly the problem I am concerned about. > > > This limitation exists also before crop & scale. Crop & scale cannot > > remove this limitation, because the whole Wayland protocol has been > > built on surface coordinates and especially surface sizes are integers. > > I thought the proposed crop+scale used fixed point to specify the > destination rectangle, which is a solution. I don't like it but I > thought it was done on purpose for this. If you read the proposal, it does not, exactly because it was written in the way that the destination rectangle size becomes directly the surface size, and hence it must be integers. The source rectangle is in wl_fixed_t. > The buffer size sent with attach is also in buffer pixels. So a client > can make a surface any size. But because the offset is in "surface > coordinates" they cannot resize the origin corner except in multiples of > buffer_scale. However they *can* resize the opposite corner in pixels. > This seems pretty inconsistent and it would be nice to fix it too. Buffer size is the property of a wl_buffer. The size is not explicitly sent on attach. You are right about the offset. Clients cannot "resize the opposite corner" in the way you assume, because the protocol requires that the buffer size is a multiple of buffer_scale, so that it always results in a surface size in integers. Buffer size must always be a multiple of buffer_scale. That was defined when buffer_scale was added to the protocol. So, there are two different cases for surface size: 1. Crop & scale not used: surface size is determined from buffer size via buffer_transform and buffer_scale. 2. Crop & scale is used: surface size is directly dst_width,dst_height. In both cases, surface size is guaranteed to be in integers. Surface size is always in integers. Nothing I have proposed, or in the current protocol, allows otherwise. - pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel
