Bug 121026 - Horizontal table borders appear slightly fatter compared to vertical lines and compared to previous versions (anti-aliasing)
Summary: Horizontal table borders appear slightly fatter compared to vertical lines an...
Status: RESOLVED WONTFIX
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: 2022-02-21 09:20 UTC (History)
4 users (show)

See Also:
Crash report or crash signature:
Regression By:


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 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
Comment 19 Telesto 2020-03-29 14:35:33 UTC
Version: 7.0.0.0.alpha0+ (x64)
Build ID: 7ae9c9572ccac55c0926b8a9779bb63c4236291c
CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Raster; VCL: win; 
Locale: nl-NL (nl_NL); UI-Language: en-US
Calc: CL
Comment 20 Armin Le Grand 2021-12-15 10:56:23 UTC
AA is used for CellBorders using resolution-dependent primitive decompositions starting from a fixed liniewidth, but that is the same for all systems. Thus this should be mostly the same, of course depending on graphic backend for how it does AA in the last system-dependent step. I can check if I find something on windows, but it may just be the backend. I would not propose to change the fixed linewidth from when to start using AA e.g. system-dependent.
Comment 21 Armin Le Grand 2022-02-21 09:20:47 UTC
Those small system- and backend-related AA-relicts are unavoidable. To fix we would need to use an internal software-renderer, that would guarantee to getthe same AAing on all systems. This would be slow and not a good choice.