Make cursor text precision actually correspond to pointing precision. #16776
Conversation
9c4d240 to
0dc2bfe
Compare
|
👍 in principle, but this is in the hot-loop of user feedback, are we sure that this won't be slow? |
|
Can't we use a simple appoximate solution like |
0dc2bfe to
ebf2282
Compare
|
I slightly optimized the code, and added tim's rough (though likely reasonable :-)) estimate for cases other than x/y. Looks like this PR makes format_data_short ~50x slower than before, but we're still at a reasonable ~100µs per call (so 10^4 calls per second). This should be compared to mouse polling rates (as that's what determines of often this function gets called), which a quick googling suggests is around 100Hz (up to 1kHz for gaming mouses), and screen refresh rates (typically 60Hz). |
ebf2282 to
2b4d611
Compare
|
added whatsnew |
Currently, the cursor text (x=..., y=...) is typically displayed with much, much more precision than the mouse cursor has (typically, one pixel); IOW the last digits displayed are typically meaningless. Make ScalarFormatter.format_data_short convert the inter-pixel distance to data space and compute the corresponding number of significant digits to use (and don't drop the final zeroes if any, as they are now, well, significant). (A similar change could be applied to other formatters, e.g. LogFormatter.)
2b4d611 to
bfb9cc7
Compare
Currently, the cursor text (x=..., y=...) is typically displayed with
much, much more precision than the mouse cursor has (typically, one
pixel); IOW the last digits displayed are typically meaningless.
Make ScalarFormatter.format_data_short convert the inter-pixel distance
to data space and compute the corresponding number of significant digits
to use (and don't drop the final zeroes if any, as they are now, well,
significant).
(A similar change could be applied to other formatters, e.g.
LogFormatter.)
PR Summary
PR Checklist