On Fri, 29 Nov 2013 10:20:18 +0200 Pekka Paalanen <ppaala...@gmail.com> wrote:
> On Fri, 29 Nov 2013 01:51:03 +0000 > Daniel Stone <dan...@fooishbar.org> wrote: > > > Hi, > > > > On 26 November 2013 17:19, Jonny Lamb <jonny.l...@collabora.co.uk> > > wrote: > > > + <arg name="src_x" type="fixed" summary="source rectangle > > > x"/> > > > + <arg name="src_y" type="fixed" summary="source rectangle > > > y"/> > > > + <arg name="src_width" type="fixed" summary="source > > > rectangle width"/> > > > + <arg name="src_height" type="fixed" summary="source > > > rectangle height"/> > > > > In the same vein as my reply to Bill, I'd really like to see these > > changed to int. I have little sympathy for clients which perform > > layout such that their buffer_scale doesn't allow them to represent > > their scene in integer space. I also have a very difficult time > > imagining that toolkits would actually perform layout like this. > > > > The more practical / less ideological objection is that this is an > > invitation for clients to get things very, very wrong. Using fixed > > suggests that partial-pixel co-ordinates are okay (e.g. src_x of 8.5 > > with a buffer_scale of 3); just how this is supposed to be > > represented accurately in hardware, I'm not quite sure. I don't > > see any benefit to this additional complication for both protocol > > and implementations; only downsides. > > Err... but arbitrarily fractional values are technically ok. As I > explained before: > > On Wed, 27 Nov 2013 10:34:10 +0200 > Pekka Paalanen <ppaala...@gmail.com> wrote: > > > The values are allowed to be arbitrary, so that you can zoom in to > > partial buffer pixels if you want to. They are not meant to counter > > buffer_scale, which you will likely choose to set to 1 anyway when > > using crop & scale and regardless of output scale. > > GL-renderer has no trouble realizing fractional src rect values; if I > read compositor-drm right the drmModeSetPlane() API uses 16 bits for > the fraction, and even rpi Dispmanx uses 16.16 fixed point. The way > pixman renderer is written it should handle fractions just fine, too. > > If I understood anything from v4l2, it seems to leave the matter up to > each driver or device. > > The test program included in the series deliberately has 1px wide > green lines in the buffer, which are cut in half by using fractional > values to test it. With a 1x1 linear texture sampling filter (pixman > and gl renderers) this results in the surface edge being solid green > and shifting to blue when moving towards an inner pixel, just like it > should. Checking visually with xmag, the results look identical. > > You're right that I don't know of any real world use case where > fractional src rect is needed, but since all the hardware APIs I know > about have it, I guess it is useful for something. Therefore I > included it. > > My imaginary use case is a pointer-controlled magnifier, where if the > magnification is high enough, pointer motion can move the src rect in > less than one buffer pixel steps. Ookay, so far it is just me vs. Daniel on the wl_fixed_t issue. Any other opinions for/against changing wl_fixed_t to just int? Thanks, pq _______________________________________________ wayland-devel mailing list wayland-devel@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/wayland-devel