summaryrefslogtreecommitdiffstats
path: root/src/sql/models/qsqlquerymodel.cpp
diff options
context:
space:
mode:
authorShawn Rutledge <shawn.rutledge@qt.io>2025-03-14 16:59:37 +0100
committerShawn Rutledge <shawn.rutledge@qt.io>2025-03-17 18:45:12 +0100
commit209a2145f94e99f99832c3a08cdf579d8f42ca55 (patch)
treec7a3dae29379dc9958d051b6816b0d08309ea4f7 /src/sql/models/qsqlquerymodel.cpp
parent7d25a1a0fd8b1f8eb48390f4c8681b8c1a8a2de1 (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