Bug 133877 - [7.0 AppImage] Tabbed/ribbon view's hamburger menu is incorrectly at ≥ 200% scale on KDE Plasma with KDE5 VCL
Summary: [7.0 AppImage] Tabbed/ribbon view's hamburger menu is incorrectly at ≥ 200% s...
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: graphics stack (show other bugs)
Version:
(earliest affected)
7.1.0.0.alpha0+
Hardware: All Linux (All)
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0 target:7.0.0.1 target:6.4.6
Keywords:
Depends on:
Blocks: HiDPI KDE, KF5
  Show dependency treegraph
 
Reported: 2020-06-10 20:09 UTC by Nate Graham
Modified: 2020-07-06 06:44 UTC (History)
3 users (show)

See Also:
Crash report or crash signature:


Attachments
Pixellated icons and more (556.06 KB, image/png)
2020-06-10 20:10 UTC, Nate Graham
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Nate Graham 2020-06-10 20:09:56 UTC
Description:
Description:
I just got a laptop with a 4K screen and am using 250% scale factor, for an effective DPI of 240 (However the bug I am about to describe also happens with 200% scale/192 DPI). I am using the 7.0 daily AppImage which includes better HiDPI support for the KDE5 VCL.

Here are the remaining issues:
- Toolbar and menu item icons are pixellated, not sharp.
- The "New" ribbon button has a downward-pointing arrow that is much too large
- The Hamburger menu in the ribbon is too small

Steps to Reproduce:
1. Have a 4K screen
2. Set a scale factor of 200% or greater in KDE System Settings
3. Open a LibreOffice app
4. Use the Ribbon UI

Actual Results:
Various UI elements are scaled incorrectly (See above).

Expected Results:
All UI elements are scaled perfectly.


Reproducible: Always


User Profile Reset: Yes



Additional Info:
Version: 7.0.0.0.alpha1+
Build ID: 6ba74150866d71469827de9f4f19268dfa7db137
CPU threads: 8; OS: Linux 5.6; UI render: default; VCL: kf5; 
Locale: en-US (en_US.UTF-8); UI: en-US
TinderBox: Linux-rpm_deb-x86_64@86-TDF, Branch:master, Time: 2020-05-07_15:09:13
Calc: threaded
Comment 1 Nate Graham 2020-06-10 20:10:47 UTC
Created attachment 161859 [details]
Pixellated icons and more
Comment 2 Roman Kuznetsov 2020-06-15 14:42:48 UTC
Nate, can you try Libreoffice from snap package or from deb/rpm packages? And what Linux distro do you use?
Comment 3 Nate Graham 2020-06-15 15:13:45 UTC
Version 6.4.4.2 in openSUSE Tumbleweed's package repo is even worse; see Bug 133876.

This bug report tracks the remaining issues I found when testing the 7.0 beta.
Comment 4 Michael Weghorn 2020-06-15 15:57:32 UTC
(In reply to Nate Graham from comment #0)
> Here are the remaining issues:
> - Toolbar and menu item icons are pixellated, not sharp.

That aspect might be the same as or related to tdf#122263 and tdf#123623.
Comment 5 Nate Graham 2020-06-15 17:00:40 UTC
Yep, pixellated icons looks to be already tracked by Bug 122263.
Comment 6 Jan-Marek Glogowski 2020-06-15 19:11:29 UTC
BTW: you can simply test this by starting LO with GDK_SCALE=2 QT_SCALE_FACTOR=2. You don't need an 4k screen per-se ;-)

> - Toolbar and menu item icons are pixellated, not sharp.
The default is still to use PNG images and scale these. You have to explicitly select an SVG icon set in Options >> LibreOffice >> View. If you compare the 100% SVG to the 100% PNGs, you'll see why both still exist :-(

- The "New" ribbon button has a downward-pointing arrow that is much too large
I consider this a general problem. On the "Layout" page, the arrow is at least placed better, but I think it's even too large at 100%. The whole "New" button + dropdown arrow looks to narrow. If you click the dropdown, it wrongly paints over the button icon. I'm not sure, why the implementation of both widgets is separated... Looks a bit better with gtk3 or gen.

- The Hamburger menu in the ribbon is too small
This at least was easy to fix: https://gerrit.libreoffice.org/c/core/+/96390
Comment 7 Nate Graham 2020-06-15 19:29:03 UTC
(In reply to Jan-Marek Glogowski from comment #6)
> BTW: you can simply test this by starting LO with GDK_SCALE=2
> QT_SCALE_FACTOR=2. You don't need an 4k screen per-se ;-)
> 
> > - Toolbar and menu item icons are pixellated, not sharp.
> The default is still to use PNG images and scale these. You have to
> explicitly select an SVG icon set in Options >> LibreOffice >> View. If you
> compare the 100% SVG to the 100% PNGs, you'll see why both still exist :-(
Aha, that works!

Idea: if you're using an icon theme with an SVG option, and you're also using high DPI mode, automatically switch to the SVG version. In other words, make the default "Automatic" mode a bit smarter and able to dynamically switch between png and SVG versions according to DPI.


> - The "New" ribbon button has a downward-pointing arrow that is much too
> large
> I consider this a general problem. On the "Layout" page, the arrow is at
> least placed better, but I think it's even too large at 100%. The whole
> "New" button + dropdown arrow looks to narrow. If you click the dropdown, it
> wrongly paints over the button icon. I'm not sure, why the implementation of
> both widgets is separated... Looks a bit better with gtk3 or gen.
Yeah, can confirm.


> - The Hamburger menu in the ribbon is too small
> This at least was easy to fix: https://gerrit.libreoffice.org/c/core/+/96390
Nice, thanks!
Comment 8 Nate Graham 2020-06-15 19:30:08 UTC
Is this bug report too general? Should we consider it fixed with https://gerrit.libreoffice.org/c/core/+/96390 and then I can file new bugs for the idea to automatically switch to SVG icons if available, and the issue with the downward-pointing arrow? What do you think?
Comment 9 Commit Notification 2020-06-15 23:37:46 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/0cdcaff7005e02280c8f6190a179ba12c9b567ca

tdf#133877 use optimal size for hamburger button

It will be available in 7.1.0.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 10 Commit Notification 2020-06-16 01:37:59 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-7-0":

https://git.libreoffice.org/core/commit/1c73b219487b2aa60d888755cf4eca082e6b00c0

tdf#133877 use optimal size for hamburger button

It will be available in 7.0.0.1.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.
Comment 11 Jan-Marek Glogowski 2020-06-16 15:05:14 UTC
(In reply to Nate Graham from comment #7)
> (In reply to Jan-Marek Glogowski from comment #6)
> > BTW: you can simply test this by starting LO with GDK_SCALE=2
> > QT_SCALE_FACTOR=2. You don't need an 4k screen per-se ;-)
> > 
> > > - Toolbar and menu item icons are pixellated, not sharp.
> > The default is still to use PNG images and scale these. You have to
> > explicitly select an SVG icon set in Options >> LibreOffice >> View. If you
> > compare the 100% SVG to the 100% PNGs, you'll see why both still exist :-(
> Aha, that works!
> 
> Idea: if you're using an icon theme with an SVG option, and you're also
> using high DPI mode, automatically switch to the SVG version. In other
> words, make the default "Automatic" mode a bit smarter and able to
> dynamically switch between png and SVG versions according to DPI.

When I originally implemented the SVG iconset packaging, I wanted to implement some automatic detection and selection for scaling and dark themes. I just remember that "everyone" wanted to wait for user feedback of the SVG icons and keep the PNG default, but I doubt many people use these.

So feel free to open a new bug report, but I won't work on this. LO has and uses two SVG reader / writer implementations, which both have different bugs. AFAIK one is a relatively fast rasterizer, while the other can deconstruct the SVG (and other vector graphics?) into LO scene graph primitives and make the image editable in Draw. Personally I think LO should use a common, fast rasterizer, like librsvg, and just keep the extra importer... actually LO was using librsvg at some point and I once wrote a patch to get rid of the LO implementation and use librsvg again, as LO's own was much slower and buggy for some documents...
AFAIK this was all started, because Apache can't use / didn't allow LGPL dependencies.

IMHO LO should get rid of the PNG icons. As one can see comparing the 100% icons, there is obviously not much motivation to fix either the icons or SVG implementations currently.

> > - The "New" ribbon button has a downward-pointing arrow that is much too
> > large
> > I consider this a general problem. On the "Layout" page, the arrow is at
> > least placed better, but I think it's even too large at 100%. The whole
> > "New" button + dropdown arrow looks to narrow. If you click the dropdown, it
> > wrongly paints over the button icon. I'm not sure, why the implementation of
> > both widgets is separated... Looks a bit better with gtk3 or gen.
> Yeah, can confirm.

Just to make it clear. The arrow is painted by LO itself, not the native backend. But since the HiDPI patch, the Qt5 VCL plugin got some strange toolbox button sizing code with fixed numbers, which I missed when reviewing and working on it:

  contentRect = QRect(boundingRect.left(), boundingRect.top(),
                      upscale(25, Round::Ceil), upscale(25, Round::Ceil));

I had a "quick" look. The code is in vcl/source/window/toolbox.cxx ImplDrawDropdownArrow. But the whole toolbox button drawing logic looks like it needs some overhaul, especially, if you look at the better layouted "Layout"-tab menu buttons.

The scaling was last changed in commit e3cc5506d695b602fbd3c6ee816e36e6a76d9d96 for bug 122118. It even added a comment, which doesn't make any sense for me.

> > - The Hamburger menu in the ribbon is too small
> > This at least was easy to fix: https://gerrit.libreoffice.org/c/core/+/96390
> Nice, thanks!

(In reply to Nate Graham from comment #8)
> Is this bug report too general? Should we consider it fixed with
> https://gerrit.libreoffice.org/c/core/+/96390 and then I can file new bugs
> for the idea to automatically switch to SVG icons if available, and the
> issue with the downward-pointing arrow? What do you think?

Yeah. Just adding more stuff here won't help.

Please open two new bugs for this:
1. The toolbox button arrow size, which has a VCL and a KF5 part
  - KF5 HiDPI sizing fix for the ControlType::Toolbar, ControlPart::Button
  - Cleanup / Refactor / Fix of the toolbox button drawing code for buttons with arrows
2. The automatic SVG selection, based on DPI settings
  - eventually needs more SVG fixes
  - eventually needs icon fixes

Then this bug can be closed.
Comment 12 Michael Weghorn 2020-06-16 15:38:40 UTC
Regarding SVG, there is also tdf#115439 (asking to prefer them over PNG), and a meta bug for SVG icon related issues: tdf#124940.

IIRC, the idea was to do a general switch to SVG at some point, but there were still too many issues.
Comment 13 Nate Graham 2020-06-16 22:26:33 UTC
Thanks so much, guys. Here are the two requested bug reports:

- Prefer SVGs icons on high DPI: Bug 115439
- Arrows too large: Bug 134054


This has been e very positive experience overall. <3 <3
Comment 14 Commit Notification 2020-07-06 06:44:01 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "libreoffice-6-4":

https://git.libreoffice.org/core/commit/9bb3b614300cd8b6572c9fa92fcd92a80d22fdc6

tdf#133877 use optimal size for hamburger button

It will be available in 6.4.6.

The patch should be included in the daily builds available at
https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More
information about daily builds can be found at:
https://wiki.documentfoundation.org/Testing_Daily_Builds

Affected users are encouraged to test the fix and report feedback.