Description: There are extreme keyboard input delays (when typing characters and/or navigating with the arrow keys) in paragraphs which contain both rtl and numeric characters in DOCX files. Since the arrow keys and the characters are handled in independent queues, for some reason, this bug makes it very difficult to edit such files in libreoffice. The characters typed are often inserted before the arrows even if the user typed the arrow first. Steps to Reproduce: 1.Open the attached file in writer. 2.Try to move the cursor along each of the four paragraphs using the arrow keys. Actual Results: In the second paragraph (the only one containing both rtl and numeric characters) the cursor moves extremely slowly and makes uncontrollable jumps. In the other three paragraphs the cursor moves as expected. Expected Results: No input delay should occur in the second paragraph. Reproducible: Always User Profile Reset: No Additional Info: This is tested on ubuntu 22.04 with gnome 42, but I suspect that this problem is platform-independent.
Created attachment 179363 [details] Input delay testcase
Sorry, incomplete attachment. I add the complete one here.
Created attachment 179364 [details] Input selay testcase - corrcet version
Upon further examination, this problem exists in original .odt files as well. Testcase is updated.
Created attachment 179384 [details] Keyboard input delay in the 2nd line only
Created attachment 179385 [details] Keyboard input delay in the 2nd line only
I'm not seeing any delay with Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: fbf739198aa7f02975d531521c6525073783c7f1 CPU threads: 8; OS: Mac OS X 12.2.1; UI render: Skia/Metal; VCL: osx Locale: nl-NL (nl_NL.UTF-8); UI: en-US Calc: threaded
The delay is unmistakable when pressing the left arrow key continuously when the cursor is at the right end of the second rtl paragraph in the testcase. I experience the problem on ubuntu with xorg and the nvidia proprietary driver (hardware acceleration disabled in LO options). Maybe this is related to one of these frameworks. I'll try the 7.4 version here and see if it solves the problem.
I checked out master from git. The problem definitely exists also in: Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: 3e94991d7fd3a085549c3a5d4c991688042d2cb9 CPU threads: 16; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: he-IL (he_IL.UTF-8); UI: en-US Misc: CAlc: CL
This bug does not occur on windows, and according to Telesto it does not occur on mac too. So, this seem to be a linux-only problem.
The issue is noted in /var/log/Xorg.0.log: [ 865.856] (EE) event6 - Microsoft Microsoft® 2.4GHz Transceiver v8.0: client bug: event processing lagging behind by 32ms, your system is too slow [ 3226.007] (EE) client bug: timer event3 debounce: scheduled expiry is in the past (-90ms), your system is too slow [ 3274.957] (EE) event6 - Microsoft Microsoft® 2.4GHz Transceiver v8.0: client bug: event processing lagging behind by 21ms, your system is too slow [ 3286.328] (EE) event6 - Microsoft Microsoft® 2.4GHz Transceiver v8.0: client bug: event processing lagging behind by 21ms, your system is too slow [ 3392.073] (EE) event6 - Microsoft Microsoft® 2.4GHz Transceiver v8.0: client bug: event processing lagging behind by 33ms, your system is too slow [ 3618.939] (EE) event6 - Microsoft Microsoft® 2.4GHz Transceiver v8.0: client bug: event processing lagging behind by 24ms, your system is too slow [ 3618.939] (EE) event6 - Microsoft Microsoft® 2.4GHz Transceiver v8.0: WARNING: log rate limit exceeded (5 msgs per 60min). Discarding future messages. [ 6531.198] (EE) client bug: timer event3 debounce: scheduled expiry is in the past (-58ms), your system is too slow [ 6531.198] (EE) client bug: timer event3 debounce short: scheduled expiry is in the past (-71ms), your system is too slow [ 6924.439] (EE) event6 - Microsoft Microsoft® 2.4GHz Transceiver v8.0: client bug: event processing lagging behind by 36ms, your system is too slow [ 7090.677] (EE) event6 - Microsoft Microsoft® 2.4GHz Transceiver v8.0: client bug: event processing lagging behind by 33ms, your system is too slow [ 7292.991] (EE) event6 - Microsoft Microsoft® 2.4GHz Transceiver v8.0: client bug: event processing lagging behind by 23ms, your system is too slow [ 7654.182] (EE) event6 - Microsoft Microsoft® 2.4GHz Transceiver v8.0: client bug: event processing lagging behind by 22ms, your system is too slow [ 7767.279] (EE) event6 - Microsoft Microsoft® 2.4GHz Transceiver v8.0: client bug: event processing lagging behind by 24ms, your system is too slow [ 7767.279] (EE) event6 - Microsoft Microsoft® 2.4GHz Transceiver v8.0: WARNING: log rate limit exceeded (5 msgs per 60min). Discarding future messages.
Hello Yotam and thank you for reporting. I can reproduce this bug by holding down the arrow keys (single presses work normal) on the second paragraph using: Version: 7.3.2.2 / LibreOffice Community Build ID: 30(Build:2) CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Ubuntu package version: 1:7.3.2~rc2-0ubuntu0.20.04.1~lo1 Calc: threaded and using: Version: 7.4.0.0.alpha0+ / LibreOffice Community Build ID: cb56edb177f4db5b9cc4d140543c4b11d41ef1b0 CPU threads: 16; OS: Linux 5.13; UI render: default; VCL: gtk3 Locale: en-US (en_US.UTF-8); UI: en-US Calc: CL Not reproducible using: LO 4.2.8.2, Ubuntu 14.04 LTS
This regression was introduced in the 5.4 series. I bibisected it: Author: Jenkins Build User <tdf@pollux.tdf> Date: Thu Feb 16 10:27:58 2017 +0100 source 7863798f2ab420fdb91ba3dcda6cea2ab2aded9d source 7863798f2ab420fdb91ba3dcda6cea2ab2aded9d instdir/program/libvcllo.so | Bin 10394213 -> 10394438 bytes instdir/program/libvclplug_gtk3lo.so | Bin 1031387 -> 1031227 bytes instdir/program/versionrc | 2 +- 3 files changed, 1 insertion(+), 1 deletion(-)
The first commit to initiate the problem can be seen here: https://cgit.freedesktop.org/libreoffice/core/commit/?id=7863798f2ab420fdb91ba3dcda6cea2ab2aded9d
On further investigation, the delay occurs whenever rtl and ltr characters exist in the same paragraph, not only in the specific case of numeric characters.
I can't reproduce, but I only have integrated Intel graphics. Does it make any difference if shift is held down to create a selection instead of just changing the input position? And is there any input methods enabled? (though using a Hebrew IM didn't make a difference when I tried it locally) And does changing the font make any difference? The only thing that comes immediately to mind with specifically digits having anything special about them is "GetLocalizedChar" in vcl which shouldn't matter for this language. If someone can reproduce it and is able to build libreoffice they could see if deleting the block of code in vcl/source/outdev/text.cxx at approx line 1190, the "if( meTextLanguage )" block makes any difference. There was trouble in the past with CAIRO_OPERATOR_DIFFERENCE and nvidia cards, again if someone can reproduce and can build libreoffice then they could see if disabling the line "cairo_set_operator(cr, CAIRO_OPERATOR_DIFFERENCE)" in vcl/headless/svpgdi.cxx makes a difference. wrt "hardware acceleration disabled in LO options" that should only affect full screen impress presentation mode FWIW
Holding shift does not make any difference. No input method is defined in settings->area and language->manage installed languages. I think they are not relevant to rtl languages. Changing the keyboard input language has no effect. Changing font (using fonts from various sources) makes no difference. Please note that on further investigation I found that this happens whenever rtl and ltr (e.g., latin) characters are mixed together. This is not exclusive to the case of rtl and numeric characters in the same paragraph.
the remaining leading contender for investigation is then that CAIRO_OPERATOR_DIFFERENCE call, there was difficulties with it in the past on nvidia. I will push a commit which will allow experimenting with the next daily that contains it to see if that has a bearing on this problem or not.
Thank you. Will you let me know how to install libreoffice from daily?
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/90057e372cd07b41c8dbba4e7b7f107568a5f451 Related: tdf#148433 test if CAIRO_OPERATOR_DIFFERENCE is the problem It will be available in 7.4.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.
The link above gives the locations of dailies, i.e. .https://dev-builds.libreoffice.org/daily/master/current.html They are dailies, so it won't be available until at least tomorrow. To test, in a terminal export SAL_DISABLE_CAIRO_DIFFERENCE=1 and run libreoffice from the command line from that terminal, the cursor should then be invisible, but selection will still work,
I confirm that running the current master version with export SAL_DISABLE_CAIRO_DIFFERENCE=1 makes the issue go away (although, as you said, the cursor is invisible).
aha!, well we have some useful data now
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/00e43c14558fa4d0369820fa3d2cd7b987e61377 Related: tdf#148433 experiment with CAIRO_OPERATOR_EXCLUSION It will be available in 7.4.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.
With this experiment then now with export SAL_DISABLE_CAIRO_DIFFERENCE=1 there should be a visible cursor (if its not visible then the change isn't in the build yet). With that visible cursor is there any performance difference than without SAL_DISABLE_CAIRO_DIFFERENCE set ?
I installed the current version from master (LibreOfficeDev 7.4.0.0.alpha0 69f412459257398a7d779541dad95aa7227a5e74). After running: export SAL_DISABLE_CAIRO_DIFFERENCE=1 && /opt/libreofficedev7.4/program/soffice I can see the cursor, but the issue, unfortunately, is not resolved.
Seeing as the problem is associated with mixed RTL and LTR characters and that it appears to be the cursor causing is I suspect the little directional arrow at the top of the cursor is the trigger for the problem.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/c7a32dab567cce8ee435c65299ec60b638700a35 Related: tdf#148433 use a slightly different cursor directional indicator It will be available in 7.4.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 think it's worth improving the look of the direction indicator on the cursor in any case. It's a total longshot if changing the cursor arrow to be slightly larger and an equilateral triangle has any knock on improvement on this performance problem. I suspect it's unlikely, but worth checking when this minor tweak becomes available for testing.
With the newest build (LibreOfficeDev 7.4.0.0.alpha0 f15e6293cf78d67963a6e512f60a11ae58da72c5), the issue is not resolved and behaviour is the same. However, something is weird: The cursor directionality triangle now appears only on the mixed paragraph (ltr and rtl). On the paragraphs that are rtl-only or ltr-only there is no triangle, only vertical line.
(In reply to Yotam Benshalom from comment #30) > However, something is weird: The cursor directionality triangle now appears > only on the mixed paragraph (ltr and rtl). On the paragraphs that are > rtl-only or ltr-only there is no triangle, only vertical line. I believe that is the way it always was, at least it was like that before my change to make the arrow more prominent.
Oh! If the direction triangle appears only in mixed paragraphs, it probably means it is the culprit. Shouldn't we see what happens if we drop it completely? Also, is there a way for me to help in further debugging the nature of the delay? If it represents a bug in cairo or in nvidia proprietary driver, the results might be useful.
(In reply to Yotam Benshalom from comment #32) > Oh! If the direction triangle appears only in mixed paragraphs, it probably > means it is the culprit. That's my guess. > Shouldn't we see what happens if we drop it completely? I will push another environmental variable hack to clarify if not drawing the triangle part of the BiDi cursor would make a difference. > Also, is there a way for me to help in further debugging the nature of the > delay? If it represents a bug in cairo or in nvidia proprietary driver, the > results might be useful. The only hits I ever get on searching for this problem is similar cases to this in the past in LibreOffice. It always seems to be nvidia related as far as I can tell. I've never encountered it myself.
Caolán McNamara committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/6dc41e33e087032a52ee11832ff1299632b4f5dd Related: tdf#148433 experiment with SAL_DISABLE_CURSOR_INDICATOR It will be available in 7.4.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.
The problem indeed disappears, along with the cursor indicator, when running: export SAL_DISABLE_CURSOR_INDICATOR=1 && /opt/libreofficedev7.4/program/soffice In case the issue is not resolved, can this behaviour stay in place? One of my jobs is adding diacritics to entire books, and this bug makes it almost impossible. FWIW, I don't really understand the reason behind the current implementation of the cursor direction indicator. I don't need an indicator telling me whether an existing character is rtl or not, because I can see that for myself. What I do need (or at least would appreciate) is an indicator that would tell me whether the character I am about to type is ltr or rtl, based on my current keyboard input language - exactly the way it is implemented in the comment textbox I am using right now via firefox. If I am not mistaken, this is the way ms word does it as well.
(In reply to Yotam Benshalom from comment #35) > The problem indeed disappears, along with the cursor indicator, when running: > export SAL_DISABLE_CURSOR_INDICATOR=1 && > /opt/libreofficedev7.4/program/soffice > > In case the issue is not resolved, can this behaviour stay in place? the variable for workaround can certainly stay in place until some proper solution is arrived at. > FWIW, I don't really understand the reason behind the current implementation > of the cursor direction indicator. RTL is not my specialty, my understanding is that if the arrow is pointing left then if a RTL char is entered it will appear at the point indicated to the left, if the arrow is pointing right then if a LTR char is entered it will appear at the point to the right. Something like gedit instead uses a split-cursor and shows two cursors with arrows to show both locations a char might appear if there is ambiguity where a char would appear depending on its classification once entered.