Bug 120644 - RTL: GTK3: Artifacts created in caret position
Summary: RTL: GTK3: Artifacts created in caret position
Status: RESOLVED WORKSFORME
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
Version:
(earliest affected)
5.4.0.0.alpha0+
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: RTL-CTL GTK3
  Show dependency treegraph
 
Reported: 2018-10-16 15:33 UTC by Xisco Faulí
Modified: 2019-11-06 10:33 UTC (History)
2 users (show)

See Also:
Crash report or crash signature:


Attachments
the problem (27.92 KB, image/png)
2018-10-16 15:36 UTC, Xisco Faulí
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Xisco Faulí 2018-10-16 15:33:34 UTC
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

Reproduced in

Version: 6.2.0.0.alpha0+
Build ID: 49c87270f7176312806d1759967c247a312f0acf
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); Calc: threaded
Comment 1 Xisco Faulí 2018-10-16 15:36:01 UTC
Regression introduced by:

https://cgit.freedesktop.org/libreoffice/core/commit/?id=555e1ff4cc84682ea73f9976f8e3c6f1d0f22590

author	Caolán McNamara <caolanm@redhat.com>	2017-02-07 16:17:02 +0000
committer	Caolán McNamara <caolanm@redhat.com>	2017-02-07 16:41:51 +0000
commit 555e1ff4cc84682ea73f9976f8e3c6f1d0f22590 (patch)
tree c6e071aaf02b08ec2db90407a3ede837959d4ce8
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
Comment 2 Xisco Faulí 2018-10-16 15:36:35 UTC
Created attachment 145763 [details]
the problem
Comment 3 Caolán McNamara 2018-10-16 20:24:50 UTC
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 ?
Comment 4 Caolán McNamara 2018-11-05 09:29:58 UTC
FWIW, some debugging tips.

with a debugging build export VCL_GTK3_PAINTDEBUG=1 before launching it will allow some keys to do special stuff.

pressing...

0
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
Comment 5 QA Administrators 2019-11-06 03:30:43 UTC Comment hidden (obsolete)
Comment 6 Xisco Faulí 2019-11-06 10:33:43 UTC
I can't reproduce it in

Version: 6.3.4.0.0+
Build ID: e93e0fb7ac8f14230434653e5d5f318707712667
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

nor in

Version: 6.4.0.0.alpha1+
Build ID: ee909ca2c02f949605f68720c3f1eef658502749
CPU threads: 4; OS: Linux 4.15; UI render: default; VCL: gtk3; 
Locale: ca-ES (ca_ES.UTF-8); UI-Language: en-US
Calc: threaded

Closing as RESOLVED WORKSFORME