diff options
| author | Shawn Rutledge <shawn.rutledge@qt.io> | 2025-03-14 16:59:37 +0100 |
|---|---|---|
| committer | Shawn Rutledge <shawn.rutledge@qt.io> | 2025-03-17 18:45:12 +0100 |
| commit | 209a2145f94e99f99832c3a08cdf579d8f42ca55 (patch) | |
| tree | c7a3dae29379dc9958d051b6816b0d08309ea4f7 /src/sql/models/qsqlquerymodel.cpp | |
| parent | 7d25a1a0fd8b1f8eb48390f4c8681b8c1a8a2de1 (diff) | |
Initialize QLastCursorPosition with a large number rather than infinity
Infinity has caused some problems when the floating-point position gets
converted to QPoint. We are trying to be stricter about overflows now
(cf 1145e1709d1072f7dd45683e9c25a14615603854). And we still have the
QTBUG-40856 fix in place in Qt Quick: on touch release, we pretend that
the mouse moves back to its last-known position. It should not re-visit
infinity in that case.
Why 2^23? Worst case, qreal might be a 32-bit float. If we store 2^24,
x() - 1 in floating-point ought to be accurately computed:
https://en.wikipedia.org/wiki/Single-precision_floating-point_format#IEEE_754_standard:_binary32
But often manhattanLength() is used with mouse positions, so with a
number half as big, that should also be accurately computed, even if
both operands have coordinates of 2^23.
Another way to look at this is we just need to say that the mouse cursor
is initially offscreen, until it moves to a known location. The actual
coordinate doesn't matter, as long as it's very obviously offscreen, no
matter how big the desktop's cluster of screens is.
Amends c5792dcfd631abb4f9e2b92cd6e88d7e5c373406
Fixes: QTBUG-134718
Change-Id: I246865e1ba389503aadbc833a0308b60f9b91d93
Reviewed-by: Jan Arve Sæther <jan-arve.saether@qt.io>
Diffstat (limited to 'src/sql/models/qsqlquerymodel.cpp')
0 files changed, 0 insertions, 0 deletions
