Created attachment 185750 [details] Screenscast of the text "fidgeting" as I type it in To reproduce: 1. Start LO Writer 2. Create a new document 3. Set the paragraph direction to RTL 4. Set the alignment to Right 5. Set your keyboard input language to Hebrew 6. Start typing text (it's enough if you simply paste the letter ש again and again Expected results: As new ש characters are added to the left of the sequence of existing characters, the sequence itself does not change nor move. Actual results: many/most letters in the sequence - including very far away from its left edge - move slightly, back and forth with consecutive keystrokes - they "fidget", as if some tie is broken regarding how to render them, once to one side then to the other and back again. There doesn't seem to be an obvious cycle - I think I notice a "slide" back after 3-4 tiny movements in a single direction, but I can't tell for sure. Experienced with: Version: 7.5.0.3 (X86_64) / LibreOffice Community Build ID: c21113d003cd3efa8c53188764377a8272d9d6de CPU threads: 4; OS: Linux 6.1; UI render: default; VCL: qt5 (qfont+xcb) Locale: en-IL (en_IL); UI: en-US Calc: CL threaded and also with VCL: gtk3 Note: When the text run ends - e.g. due to getting to a new line, or typing in some LTR text - the fidgeting stops for the characters in the earlier run, and only occurs for the characters in the new text run.
This seems to also happens in Arabic. For the text, try tying ف and then غ repeatedly (or pasting the former and then the latter if you can't type in Arabic).
I can reproduce this but to a much smaller degree (probably depends on the DPI), but I have no idea what is going on. Looks like something Caolán McNamara might know about.
Well, if Khaled can reproduce - even if fidgeting is not as pronounced - then marking as NEW. Also, +Caolan.
This bug affects all languages, and can be reproduced in English by right-aligning a paragraph, typing some text, and then deleting characters from the beginning (left) of the line. Technical details: The root cause for this bug is precision loss while laying out right-aligned text. In LibreOffice, all text is internally laid out from left-to-right. This includes RTL text (which is laid out backwards), and right-aligned text (which is offset by its width during rendering). Due to this approach, the calculation for a glyph's position always depends on the positions of the glyphs to its left. Unfortunately, floating point math is not perfectly accurate. In order to keep stationary glyphs from vibrating during editing, their positions must be calculated in the same manner both before and after an edit. For left-aligned LTR text, this is the case. However, it is not true for right-aligned RTL text, where typing always inserts to the left of the characters that should be stationary. Example: Suppose you have some trivial, left-aligned LTR characters with advances A, B, C. Their laid out X coordinates are 0, A, A+B Then, you add another character to the end of the line, with advance D. Their X coordinates are now 0, A, A+B, A+B+C In both cases, the coordinates for the first three characters are calculated in the same way. They therefore won't appear to vibrate. Now, suppose you have right-aligned RTL characters with advances A, B, C. Their laid out X coordinates are (C+B)-(A+B+C), (C)-(A+B+C), 0-(A+B+C) Then, you add another character to the end of the line, with advance D. (D+C+B)-(A+B+C+D), (D+C)-(A+B+C+D), (D)-(A+B+C+D), (0)-(A+B+C+D) In the real numbers, we know that the first three characters have the same coordinate. However, floating point math is not commutative; by adding and then subtracting D from those first three characters in this manner, an observable amount of error is introduced. The fix for this issue is to lay out right-aligned text from right-to-left, rather than from left-to-right.
(In reply to Jonathan Clark from comment #4) So, it was likely some kind of repositioning was occurring with every typed character, but that explanation paint a clear picture of the mechanism. I certainly support layout occurring from right-to-left directly. However - I have to wonder how the floating-point inaccuracy is so high. I mean, single-precision floating-point values, which I assume are what's used, are precise to under 1e-6 in relative terms (the 7th decimal digit is when error starts to accrue); and even if we multiply this by, say, 30, for 30 different characters on the line - that's still pretty small. Should not show up as even a 0.5-pixel; movement (which is 1/3840 > 1e-4 on a typical display). Is there some other factor which scales the error upwards?
(In reply to Eyal Rozenberg from comment #5) > Is there some other factor which scales the error upwards? Yes, as a matter of fact: shortly after posting I also found out the hard way that "A+B+C+D" was being truncated. This ended up being the worst of it. The example I gave above is highly simplified. The real code does multiple passes of repeated (unfused) multiply adds for layout, adjustment, and positioning. I haven't tried to quantify the error, but I lifted a multiply out of the main layout loop and it cleared up almost all of the remaining subpixel judder. I'm hoping these two changes combined are good enough, and we can avoid the more extensive change I suggested above.
Jonathan Clark committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/560e5406f3c6e8e6ed0f1c251b6910465266ed8d tdf#153966 vcl: Fix precision loss laying out right-aligned text It will be available in 25.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I'm provisionally marking this bug fixed. I can still see some rare subpixel judder, but the situation is greatly improved. We can reopen this bug if others disagree.
(In reply to Jonathan Clark from comment #8) So, I downloaded the latest nightly. Huge improvement! ... but I still see fidgeting, at the word level. For example, in zoom level 80% or 90% type two words, e.g.: אחת שתיים in RTL and right-aligned. Then, repeatedly type a space and delete it. The second word, שתיים, will fidget. This happens with most/all words - as the last word (leftmost word) on the line. Font is David CLM. The exact build id is: Version: 25.2.0.0.alpha0+ (X86_64) / LibreOffice Community Build ID: 560e5406f3c6e8e6ed0f1c251b6910465266ed8d CPU threads: 4; OS: Linux 6.6; UI render: default; VCL: gtk3 Locale: he-IL (en_IL); UI: en-US What do you think? I tend towards not closing the bug yet.
(In reply to Eyal Rozenberg from comment #9) > What do you think? I tend towards not closing the bug yet. I agree.