Open requested to merge asturmlechner/qtbase:QTBUG-95319-inconsistent-cursor-w-fractional-scaling into kde/5.15
This one is a bit convoluted, so bear with me. I decided to keep full cherry-pick history including those not slated for 5.15 but it could also be squashed.
- Upstream task, still ongoing: https://bugreports.qt.io/browse/QTBUG-92468
- Main bug to be fixed: https://bugreports.qt.io/browse/QTBUG-95319
Short summary of the commits picked:
- e99a883b (has Pick-To 5.15, causing regression)
- 33238ea2 (amends 1., not fixing regression)
- 3709bc36 (has Pick-To 5.15)
- de163006 (rolls back 1. and 2. - touching 3. - but also adds fix for when QScriptItem is a QScriptAnalysis::Object)
The latter was conflicting with 5335cc4a in dev branch, jfyi.
The end result leaves two patch hunks:
a) QTextLayout: Reconsider cursor drawing on TextObject
- Revert: e99a883b - Revert: 33238ea2 These two commits made the drawing of the cursor incomprehensible, but their purpose was to fix the problem of abnormal cursor drawing when QScriptAnalysis::Object is present. Because objects require some special handling, they can be specially aligned or floated. [...] We just need to specially consider the case where the QScriptItem is a QScriptAnalysis::Object, keeping the base and descent the same as the row. Task-number: QTBUG-92468 Task-number: QTBUG-86823 Task-number: QTBUG-96288 Pick-to: 6.2 6.4 Change-Id: I6d9a0e00fbc3823e0cc8e0e8bd061da5782d1f8a Reviewed-by: Shawn Rutledge <firstname.lastname@example.org>
b) Ensure consistent cursor width under fractional scaling
Under fractional scaling, an N units wide rectangle can in general cover either M or M+1 pixels, depending on placement. For a tall thin recangle like the cursor, this difference becomes very visible as the cursor moves from position to position. Avoid by instead painting the cursor as a cosmetic line in such cases, since that keeps its width independently of the current transformation. Fixes: QTBUG-95319 Pick-to: 6.4 6.3 6.2 5.15 Change-Id: I31a31f89fe7eac3037694946aa452a9f2bd6e5be Reviewed-by: Morten Johan Sørvig <email@example.com>