[Interest] QPointF in QMouseEvent

[Rutledge Shawn]

On 21 Sep 2015, at 03:50, Brad Pepers <bpepers at me.com> wrote:

> I was wondering if anyone knows why QMouseEvent::pos() returns a QPoint but QMouseEvent::localPos() returns a QPointF.  When do you ever have fractional pixels?  When would pos() and localPos() be different?

We need to stop using integer coordinates in QtQuick.  IMO those cases where QPoint or int are still used for such purposes are anachronisms.

Practically every embedded system big enough to run Qt has an FPU nowadays.  So it is more wasteful to convert numbers back and forth between int and float formats than to use floats everywhere.

In standard Javascript, numbers are always floating-point.  So we might as well be consistent with that in QML as much as possible.

In OpenGL, rendering coordinates are always floating-point.  So you may ask for integer coordinate positioning and sizing, but there will be a transformation matrix applied during rendering anyway.

Using floating point numbers does permit subpixel precision whenever that’s useful.  We cannot say for sure that no mouse or touchscreen will ever provide subpixel resolution.  With Wacom tablets, subpixel resolution is already quite important to artists, because they are trying to replicate the experience of drawing or painting with physical media.

Using real-world units helps takes the design philosophy beyond “pixel-perfect design” and into the modern era of truly scalable graphics, on displays with such high resolution that you can’t see the pixels anyway.

The physical world (on human scale) is measured in meters (and multiples and fractions), not the cellulose cells of which paper is composed.  And displays are catching up to the resolution of paper, right on course to continue to make paper-based communication more and more obsolete.  So, we need to move towards using real-world units for computer graphics too, because in the limit, pixels will be vanishingly (and unpredictably) small.