Bug 133066

Tested on 6.4.3.2, but 7.0.0 Alpha 1 exhibits the same behavior. Using Nvidia P2000 with proprietary drivers.
 
Version: 6.4.3.2
Build ID: 1:6.4.3-0ubuntu0.20.04.1
CPU threads: 12; OS: Linux 5.4; UI render: default; VCL: gtk3; 
Locale: en-US (en_US.UTF-8); UI-Language: en-US
Calc: CL

Created attachment 160858 [details]
Screenshot

This bug is no longer reproducible in version 7.1.0.0.alpha0


Changing status to RESOLVED WORKSFORME

I confirm with the simulated scaling:
GDK_SCALE=2 SAL_USE_VCLPLUGIN=gtk3 libreoffice

Arch Linux 64-bit
Version: 7.1.0.0.alpha0+
Build ID: cb72269f93a20dd175dae3dcf30740c9931e7684
CPU threads: 8; OS: Linux 5.7; UI render: default; VCL: gtk3
Locale: fi-FI (fi_FI.UTF-8); UI: en-US
Calc: threaded
Built on 24 June 2020

Can confirm that this still exists with Wayland and 200% scaling.

Version: 7.1.0.0.alpha0+
Build ID: 73933ed0a207f1cf210cc4a7d329755bd885f871
CPU threads: 16; OS: Linux 5.8; UI render: default; VCL: gtk3
Locale: en-US (en_US.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-10-19_17:49:49
Calc: threaded

(In reply to Buovjaga from comment #4)
> I confirm with the simulated scaling:
> GDK_SCALE=2 SAL_USE_VCLPLUGIN=gtk3 libreoffice
> 
> Arch Linux 64-bit
> Version: 7.1.0.0.alpha0+
> Build ID: cb72269f93a20dd175dae3dcf30740c9931e7684
> CPU threads: 8; OS: Linux 5.7; UI render: default; VCL: gtk3
> Locale: fi-FI (fi_FI.UTF-8); UI: en-US
> Calc: threaded
> Built on 24 June 2020

With GDK_SCALE=2 SAL_USE_VCLPLUGIN=gtk3 libreofficedev7.2, still exist in

Version: 7.2.0.0.alpha0+ / LibreOffice Community
Build ID: b7175495249958c430e16c0bad358eee0032b65a
CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3
Locale: id-ID (id_ID.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2021-01-28_20:31:16
Calc: threaded

The report is not stating essential information: this happens with scaling factors > 1. And it has been happening for years. And it's even worst for SVG icons. And it doesn't happen with the Qt backend.

At the end of https://bugs.documentfoundation.org/show_bug.cgi?id=51733 (which has been open since 2012) are a number of reports for Linux systems.

Yep, it seems I didn't search enough, let's close as dupe

*** This bug has been marked as a duplicate of bug 51733 ***

It's ok that your marked this as a dup because it's probably the same underlying issue, but maybe the original one should be reformulated as not to seem as MacOS specific as it seems now. Besides, the fact that SVG icons render just fine with Qt backend may be pointing in a different direction than providing higher resolution icons. There should be a reason why the GTK backed is doing such a poor job with SVG. Just saying.

(In reply to Buovjaga from comment #9)
> Yep, it seems I didn't search enough, let's close as dupe
> 
> *** This bug has been marked as a duplicate of bug 51733 ***

Probably no. bug 51733 is about providing more PNG scales, while this bug is about the rendering process. Obviously the rasterisation step is done in the wrong scaling.

Ok, let's undupe, then.

(In reply to carlosjosepita from comment #10)
> Besides, the fact that SVG icons render just fine with Qt backend may be pointing in a different direction than providing higher resolution icons.

I can confirm that. The gen vcl plugin renders well, too. That really narrows down the problem

Let's take a look at https://wiki.inkscape.org/wiki/index.php/HiDPI

(In reply to frontrunner_medicophysical from comment #13)
> (In reply to carlosjosepita from comment #10)
> > Besides, the fact that SVG icons render just fine with Qt backend may be pointing in a different direction than providing higher resolution icons.
> 
> I can confirm that. The gen vcl plugin renders well, too. That really
> narrows down the problem

Well, after another test, I believe both the kf5 and the gen vcl plugin don't give the right scaling, because they don't draw the scaled graphics at all, except the menu icon.