Download it now!
Bug 130991 - Toolbar arrows too large on 200% scaling
Summary: Toolbar arrows too large on 200% scaling
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: UI (show other bugs)
Version:
(earliest affected)
6.4.1.2 release
Hardware: All All
: medium normal
Assignee: Not Assigned
URL:
Whiteboard: target:7.1.0 target:7.0.0.1 target:6.4.6
Keywords:
: 132178 (view as bug list)
Depends on:
Blocks: HiDPI 134054
  Show dependency treegraph
 
Reported: 2020-02-27 16:52 UTC by Klaus1189
Modified: 2020-09-14 23:00 UTC (History)
7 users (show)

See Also:
Crash report or crash signature:


Attachments
6.4.1.2 arrows to big (100.61 KB, image/png)
2020-02-27 16:52 UTC, Klaus1189
Details
comparison of 6.2.8.2 and 6.4.1.2 (74.33 KB, image/png)
2020-03-17 17:02 UTC, Klaus1189
Details
comparison of 6.2.8.2 and 6.4.1.2 (89.21 KB, image/png)
2020-03-17 17:04 UTC, Klaus1189
Details
7.0.0.1.png (98.82 KB, image/png)
2020-07-10 11:01 UTC, Klaus1189
Details
cut off 7.0.0.1.png (110.22 KB, image/png)
2020-07-10 11:02 UTC, Klaus1189
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Klaus1189 2020-02-27 16:52:15 UTC
Created attachment 158240 [details]
6.4.1.2 arrows to big

Toolbar arrows too large on 200% scaling

last version which is fine is 6.2.x

See attachment for illustration.
Comment 1 Heiko Tietze 2020-03-17 14:40:01 UTC
200% sounds like much scaling. 8k display? ;-)
Don't think we can do much, see bug 122118. The triangles are drawn as 

    long width = round(rDropDownRect.getHeight()/5.5) * fScaleFactor; // scale triangle depending on theme/toolbar height with 7 for gtk, 5 for gen
    long height = round(rDropDownRect.getHeight()/9.5) * fScaleFactor; // 4 for gtk, 3 for gen
    if (width < 4) width = 4;
    if (height < 3) height = 3;

https://opengrok.libreoffice.org/xref/core/vcl/source/window/toolbox.cxx?r=4a08d20e#2374


But I'd keep the ticket open to see if more complaints come in.
Comment 2 Klaus1189 2020-03-17 17:00:53 UTC
How are the triangles drawn in versions till 6.2.8.2?

This version looks good to me, I am on 200 % scaling for 4 years and LibreOffice was always fine and nice to look at it, but the arrows seems to be to big. See also new camparison screenshot.
Comment 3 Klaus1189 2020-03-17 17:02:25 UTC
Created attachment 158758 [details]
comparison of 6.2.8.2 and 6.4.1.2
Comment 4 Klaus1189 2020-03-17 17:04:12 UTC
Created attachment 158759 [details]
comparison of 6.2.8.2 and 6.4.1.2
Comment 5 Heiko Tietze 2020-03-18 07:44:06 UTC
(In reply to Klaus1189 from comment #3)
> Created attachment 158758 [details]
> comparison of 6.2.8.2 and 6.4.1.2

bug 122118 refers to this patch https://cgit.freedesktop.org/libreoffice/core/commit/?id=b62c43d1200e524369d9c7c2bd1dad3044efd672

Reason was likely the introduction of antialiasing but the past drawing function was also not really convincing

   while( width >= 1)
   {
      rRenderContext.DrawRect( tools::Rectangle( x, y, x+width-1, y ) );
      y++;
      x++;
      width -= 2;
   }

If we go ahead, and I would do only if more complaints come in, we should reduce the effect of scaling like 

long width = round(rDropDownRect.getHeight()/5.5) * fScaleFactor * 0.9;

I introduced the values of 5.5 and 7 for bug 122118 by trial and error as approximation to the normal expander triangle at 100%. Doing the same for higher scaling makes no sense without hires screen.
Comment 6 Michael Meeks 2020-03-19 14:18:32 UTC
Thanks Heiko - of course, having a properly AA thing would be lovely; for the precision there, I guess we should have multiple sizes of pre-drawn bitmap (or something) =) Then again - much of the UX would be better as native, platform rendered & themed widgets I think - in the deep future.
Comment 7 omickal 2020-04-17 09:53:46 UTC
I have same bug...
Comment 8 V Stuart Foote 2020-04-17 13:05:26 UTC
*** Bug 132178 has been marked as a duplicate of this bug. ***
Comment 9 Klaus1189 2020-04-18 06:07:31 UTC
I just downloaded 6.4.3 and the arrows still look way too big. Going back to 6.2.8

Have you developers plans to go back to 6.2.8 arrows which look perfect?
Comment 10 omickal 2020-04-23 11:05:57 UTC
Please implement patches quickly, it would be a shame to stop using LibreOffice after many years. In the current form of the program it is practically impossible to use.
Comment 11 Michael Meeks 2020-04-23 11:14:12 UTC
Hi all, this is an easy hack - anyone who feels passionately about this can build LibreOffice and tweak the code Heiko pointed at and that is linked in that patch to get something they like better, and then send their first patch. Thanks.
Comment 12 Klaus1189 2020-05-24 12:56:34 UTC
Hi,
I downloaded 6.4.4 and the issue still persists. I beg to go back to 6.2.x look.
Comment 13 Heiko Tietze 2020-06-29 07:56:33 UTC
*** Bug 134054 has been marked as a duplicate of this bug. ***
Comment 14 Jan-Marek Glogowski 2020-06-30 15:23:55 UTC
So I had a look into this, and it's no easy hack. While the arrow now scales, the assigned drop-down-arrow rectangle doesn't. You can see this in the attached images, where the arrow is painted out-of-bounds and overlaps with other widgets. In fact the reported size to the native painting code is always 11px, the TB_DROPDOWNARROWWIDTH. If you highlight the button with the mouse, you'll see the too small dividing line between the button and the drop-down-arrow.

This is also visible in my attached images of bug 134054, but that had in addition a broken implementation of the native button sizing code in the Qt5 VCL backend.

Now interestingly there is some IOS code there, which probably needs some additional fixup now:

-    long            nDropDownArrowWidth = TB_DROPDOWNARROWWIDTH;
+    long            nDropDownArrowWidth = TB_DROPDOWNARROWWIDTH * fScaleFactor;
#ifdef IOS
    nDropDownArrowWidth *= 3;
#endif

And I don't know if any platform code works around this problem in the VCL plugin. IMHO that IOS code should be removed too, but since I don't know anything about IOS, and interested party has to review the (multiple) patches.
Comment 15 Commit Notification 2020-07-01 09:56:26 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

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

tdf#130991 Scale the drop-down arrow size-request

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 16 Commit Notification 2020-07-01 15:19:12 UTC
Jan-Marek Glogowski committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/17b75eb1d7032f8ff85d9af1ec635fa1800cca1e

tdf#130991 Fit the drop-down arrow into its rect

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 17 Commit Notification 2020-07-01 20:52:51 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/f0daeb39aa61cc3435630cf0b9727f6da818de1a

tdf#130991 Scale the drop-down arrow size-request

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 18 Commit Notification 2020-07-02 03:03:53 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/b0315eb69c62f2108983e6a4b2177cf28a2663bf

tdf#130991 Fit the drop-down arrow into its rect

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 19 Commit Notification 2020-07-07 12:14:38 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/c0971961cf11097c787c67b5892d6209f89662e7

tdf#130991 Fit the drop-down arrow into its rect

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.
Comment 20 Commit Notification 2020-07-08 00:32:14 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/9921be1f47943781c443927f7c7d94a460f2780b

tdf#130991 Scale the drop-down arrow size-request

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.
Comment 21 Klaus1189 2020-07-10 11:01:22 UTC
I installed 7.0.0.1 and the issue is fixed. Thank you very much for this.
I checked installer on 200% scaling ass well and it is fine as well. Nice ;)

But I got two other cosmetics to be delt with, so official 7.x.x stable/final is looking good.

I have still 3840x2160p display and windows is sclaed to 200%, then I encounter this in pre 7.0.0.1:

- The filename is cut off when hoovering the mouse onto a recent document the user edited. -> "cut off 7.0.0.1.png

- In german translation "Zuletzt verwendete Dateien" for recent files or similar on english version, the last "n" of "Dateien" is cut in half by the drop down arrow box -> "7.0.0.1"

should I create new bugs for these, or is it enough here?

Thank you guys :)
Comment 22 Klaus1189 2020-07-10 11:01:52 UTC
Created attachment 162876 [details]
7.0.0.1.png
Comment 23 Klaus1189 2020-07-10 11:02:17 UTC
Created attachment 162877 [details]
cut off 7.0.0.1.png