Bug 121026 - Horizontal table borders appear slightly fatter compared to vertical lines and compared to previous versions
Summary: Horizontal table borders appear slightly fatter compared to vertical lines an...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
6.2.0.0.alpha1+
Hardware: All Windows (All)
: lowest trivial
Assignee: Not Assigned
URL:
Whiteboard:
Keywords: bibisected, bisected, regression
Depends on:
Blocks: Table-Borders Regressions-FrameBorderPrimitive
  Show dependency treegraph
 
Reported: 2018-10-29 15:24 UTC by Telesto
Modified: 2019-06-03 11:40 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:


Attachments
How it looks on linux gtk3 (61.76 KB, image/png)
2018-11-10 12:45 UTC, Xisco Faulí
Details
Look different but actually not (127.12 KB, image/png)
2018-11-29 09:08 UTC, kuouu
Details
Bibisect log (3.07 KB, text/plain)
2018-11-29 21:33 UTC, Telesto
Details
how it looks after the patch (47.17 KB, image/png)
2019-06-03 09:19 UTC, Xisco Faulí
Details
how it looks before the patch (46.95 KB, image/png)
2019-06-03 09:19 UTC, Xisco Faulí
Details
Screencast (512.28 KB, video/mp4)
2019-06-03 11:40 UTC, Telesto
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Telesto 2018-10-29 15:24:16 UTC
Description:
Horizontal table borders appear slightly fatter compared to vertical lines

Steps to Reproduce:
1. Insert a table (default style)

Actual Results:
Horizontal table borders appear slightly fatter compared to vertical lines

Expected Results:
Same borders


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 6.2.0.0.alpha1+
Build ID: cb7500ddb8de6c41fca84a0009ffe22240bb1845
CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; 
TinderBox: Win-x86@42, Branch:master, Time: 2018-10-29_03:24:02
Locale: nl-NL (nl_NL); Calc: C
Comment 1 Xisco Faulí 2018-11-10 12:45:10 UTC
Created attachment 146521 [details]
How it looks on linux gtk3

On linux ( gtk3 ) it looks better on master than on 6.1.3.2
Comment 2 Telesto 2018-11-10 13:39:26 UTC
(In reply to Xisco Faulí from comment #1)
> Created attachment 146521 [details]
> How it looks on linux gtk3
> 
> On linux ( gtk3 ) it looks better on master than on 6.1.3.2

Attachment 146522 [details] does shows the issue
Comment 3 kuouu 2018-11-29 08:42:03 UTC
Bug confirmed

Version: 6.3.0.0.alpha0+
Build ID: 8a02a1d329c43df6de383a7b0cf8ac14247b18c9
CPU threads: 8; OS: Linux 4.15; UI render: default; VCL: gtk3; 
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2018-11-17_20:48:16
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: threaded
Comment 4 kuouu 2018-11-29 09:08:02 UTC
Created attachment 147129 [details]
Look different but actually not

I insert a table and take screenshot. After I zoom in to 600%, the bug really exists.
But when I go back to Libre office writer and directly zoom in to 600%, the borders are having same width.
Comment 5 Dieter Praas 2018-11-29 21:02:44 UTC
Set to NEW because of comment 3
Comment 6 Telesto 2018-11-29 21:33:22 UTC
Created attachment 147156 [details]
Bibisect log

Bisected to

author	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-10-25 10:06:05 +0200
committer	Armin Le Grand <Armin.Le.Grand@cib.de>	2018-10-25 12:43:55 +0200
commit	313392119522c21a6ecd14403d6f92c948149df7 (patch)
tree	fbd1a112a41f83d34c6bb6ea79eeccf73dba3e7b
parent	8dec85a3b3f4cbd46b03f707458347a25cc22c15 (diff)
Reorganize FrameBorderPrimitive creation (II)
Step5: Move the view-dependent decomposition from
BorderLinePrimitive2D to SdrFrameBorderPrimitive2D.

https://cgit.freedesktop.org/libreoffice/core/commit/?id=313392119522c21a6ecd14403d6f92c948149df7
Comment 7 Telesto 2018-11-29 21:38:19 UTC
Adding CC: to Armin Le Grand
Comment 8 Telesto 2018-12-04 14:12:24 UTC
Sorry for the spam
Comment 9 Xisco Faulí 2018-12-05 13:49:25 UTC
Personally I see the line drawing better in master than in 6.1, specially when zooming. To me it's rathen an improvement than a bug...
Adding the UX team to know their opinion...
Comment 10 Heiko Tietze 2018-12-10 10:15:28 UTC
(In reply to Xisco Faulí from comment #9)
> Adding the UX team to know their opinion...

It depends on the render engine (both OS and LibO). Tools > View > Graphics Output > Anti-Aliasing has a significant impact on the lines.IIRC, Armin changed the subpixel calculation, let's see what he says.
Comment 11 Telesto 2019-06-02 13:50:35 UTC
@Xisco
Any change that the fix for bug 121241 could be used here too?
BTW the issue is limited to  Anti-Aliasing (comment 10)
Comment 12 Xisco Faulí 2019-06-03 09:19:01 UTC
Created attachment 151867 [details]
how it looks after the patch
Comment 13 Xisco Faulí 2019-06-03 09:19:34 UTC
Created attachment 151868 [details]
how it looks before the patch
Comment 14 Xisco Faulí 2019-06-03 09:20:40 UTC
it seems fine to me. Please reopen it if you disagree.
Comment 15 Telesto 2019-06-03 10:03:28 UTC
Sorry, reopening
1. This report is about Windows, not MacOS. (Didn't check MacOS)
2. Behavior is still the same. Borders are - with Anti-Aliasing - enabled rather fuzzy/fat. This didn't exist in previous versions with Anti-Aliasing enabled. 

Not sure how I can illustrate properly. Anti-Aliasing is an improvement at certain zoom-levels but not in general, IMHO. Rather hard to give an example, because of the multiple influences at play (zoomlevel, border size, screen used)  

A border of 2,0 pt is crisp without Anti-Aliasing and slightly fuzzy with Anti-Anti-Aliasing on my non-HiDPI screen. At zoom level between 50-200. 

1. Open Writer
2. Insert a table with 2.0 pt line width at zoom 175 or something like that
3. Open Tools -> options 
4. Position the dialog so that you can see the table
5. View -> Uncheck Use anti-aliasing & press apply 
6. Check & anti-aliasing & press apply  (and notice the difference)

The (only) advantage of Anti-Aliasing is it masking drawing issues at corners (horizontal/vertical lines don't always exactly match on screen; again depending on zoomlevels/ border line thickness)
Comment 16 Xisco Faulí 2019-06-03 10:05:48 UTC
Then it's not fixed, my commit changed mac related code
Comment 17 Xisco Faulí 2019-06-03 10:11:16 UTC
@Telesto, could you please attach a screenshot ? the one from comment 2 is on macos. OTOH, this issue was confirmed in comment 3 with gtk3, which is incorrect...
Comment 18 Telesto 2019-06-03 11:40:08 UTC
Created attachment 151869 [details]
Screencast

An attempt to show to difference.. Not to easy to record though