Steps to reproduce:
1. Open attachment 145709 [details] from bug 120586
2. Place the cursor in the Hebrew text
3. Move to the right or left using the arrow keys
-> A caret artifact is displayed on every position. Only reproduced with GTK3 and RTL text
Build ID: 49c87270f7176312806d1759967c247a312f0acf
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3;
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded
Regression introduced by:
author Caolán McNamara <email@example.com> 2017-02-07 16:17:02 +0000
committer Caolán McNamara <firstname.lastname@example.org> 2017-02-07 16:41:51 +0000
commit 555e1ff4cc84682ea73f9976f8e3c6f1d0f22590 (patch)
parent f9d0f55b2eefc1107d238774a00f7062a1e0d5c8 (diff)
bubble the original gtk surface type through rendering
this may make scrolling a tad faster
Bisected with: bibisect-linux-64-5.4
Adding Cc: to Caolán McNamara
Created attachment 145763 [details]
not reproducible for me under Fedora 28 with or without export GDK_BACKEND=x11
https://gerrit.libreoffice.org/#/c/61850/ is a speculative guess to see if it would make a difference ?
FWIW, some debugging tips.
with a debugging build export VCL_GTK3_PAINTDEBUG=1 before launching it will allow some keys to do special stuff.
triggers a full refresh of the ui from the backing surface, if pressing 0 redraws without the problem then the problem is with telling gtk what area changed, if pressing 0 doesn't do anything then...
pressing 1 start recording (with 2 stopping) each change as a dumped .png to /tmp which can help to isolate that the initial drawing is broken