Modern Toolset (Accelerated) Viewport is quarter size on HiDPI Screens

Bug #1797308 reported by Stou Sandalski on 2018-10-11
This bug affects 6 people
Affects Status Importance Assigned to Milestone
Fix Released
John Beard

Bug Description

Selecting "Modern Toolset (Accelerated)" in Eeschema on a Thinkpad X1 Carbon with Intel(R) HD Graphics 5500 (Broadwell GT2) running Fedora 28 causes the viewport with the schematic to be half in each dimension. When the mouse cursor is in the middle of the window it shows up in the middle of the viewport. Fallback canvas works but is barely readable.

The 3D Viewer also has the same problem.

Application: kicad
Version: (6.0.0-rc1-dev-862-gab1f01613), release build
    wxWidgets 3.0.4
    libcurl/7.59.0 OpenSSL/1.1.0i zlib/1.2.11 libidn2/2.0.5 libpsl/0.20.2 (+libidn2/2.0.4) libssh/0.8.3/openssl/zlib nghttp2/1.32.1
Platform: Linux 4.18.12-200.fc28.x86_64 x86_64, 64 bit, Little endian, wxGTK
Build Info:
    wxWidgets: 3.0.4 (wchar_t,wx containers,compatible with 2.8) GTK+ 3.22
    Boost: 1.66.0
    OpenCASCADE Community Edition: 6.9.1
    Curl: 7.59.0
    Compiler: GCC 8.1.1 with C++ ABI 1013
Build settings:

Stou Sandalski (stou) wrote :
Nick Østergaard (nickoe) wrote :

Does it look correct in pcbnew?

tags: added: eechema gal hidpi
Changed in kicad:
milestone: none → 6.0.0-rc1
milestone: 6.0.0-rc1 → 5.1.0
Tomasz Wlostowski (twlostow) wrote :

Can you try changing antialiasing settings?


Stou Sandalski (stou) wrote :

It's also broken in pcbnew.

The AA settings make no difference.

Tomasz Wlostowski (twlostow) wrote :

Do you have any compositing window manager? If so, could you try changing it?


Stou Sandalski (stou) wrote :

There isn't anything besides Gnome 3.28.2 and X since I am running a default Fedora 28 Workstation install but with Wayland disabled.

To me it looks like the pixel size isn't being taken into account when sizing the viewport.

Tomasz Wlostowski (twlostow) wrote :

Can you try changing the display's (fonts, etc.) DPI in the system settings?


Stou Sandalski (stou) wrote :

Changing the scaling to 1 by launching kicad with (from GDK_SCALE=1 renders the viewport the correct size but all the fonts, icons, etc. are too small.

Launching with GDK_SCALE=2 produces the quarter sized viewport in accelerated mode but some text is too big and some normal sized.

Seth Hillbrand (sethh) wrote :


If you set GDK_SCALE=1, can you select the correct icon scale using KiCad Preferences?

Changed in kicad:
status: New → Incomplete
Seth Hillbrand (sethh) on 2019-01-10
Changed in kicad:
milestone: 5.1.0 → none
Stou Sandalski (stou) wrote :

Setting GDK_SCALE=1 and icon size to 150% in kicad preferences makes the accelerated toolset very usable.

Two remaining issues:
1. Fonts in status bar, "Configure Paths" dialog, "Footprint Libraries" dialog, and kicad project browser are tiny (see screenshot).

2. Layers drop down is cut off in both the toolbar and in the footprint text editor.

Seth Hillbrand (sethh) wrote :

@Stou- Are you using Wayland?

Stou Sandalski (stou) wrote :

No, as I mentioned in #6, Wayland is disabled.

Seth Hillbrand (sethh) wrote :

Does this still happen with the current nightly build?

Can you provide more information about your system. Which X1 carbon version is it?

I also have a hipdi monitor running Linux but do not observe this issue, so we're trying to determine the differences.

Stou Sandalski (stou) wrote :

Yes running the nightly. The computer is a 3rd Generation X1 with Intel(R) HD Graphics 5500 (Broadwell GT2) and ``14.0" WQHD (2560x1440), anti-glare, 270 nits, 700:1 contrast ratio, IPS, multitouch screen supports 10-finger gesture display`` running Fedora 29 with everything on default except that Wayland has been disabled and the wallpaper changed.

Launchpad Janitor (janitor) wrote :

[Expired for KiCad because there has been no activity for 60 days.]

Changed in kicad:
status: Incomplete → Expired
Nick Østergaard (nickoe) wrote :

@Stou, is this still an issue?

Stou Sandalski (stou) wrote :

Yes, it's still an issue with the accelerated canvas in pcbnew (and the 3d viewer). Fallback canvas works fine so pcbnew is totally usable.

For what it's worth I've noticed the same issue with the viewport in the `Slic3r` application.

Seth Hillbrand (sethh) wrote :

Did you get a chance to try Tom's suggestion from #7? What DPI do you have set at the moment?

Stou Sandalski (stou) wrote :

I should have mentioned in #8 that the only way I could figure out how to change the system DPI at the time was through the GDK_SCALE variable. I don't see any system settings specifically for fonts or icons. Lauching with `GDK_SCALE=1 kicad` fixes the viewport but has the same cosmetic issues described in #10.

There is a 'Displays > Built-in display > Scale' parameter in the control panel which allows two values 100% and 200%. It is normally set to 200%. Setting to 100% makes the system shell, shell dialogs, cursor, and application title-bar text smaller but even after a reboot it has no effect on kicad at all. This setting also doesn't seem to have any effect on gnome applications like terminal or nautilus besides the title bar text so I am not very clear about its purpose.

Changed in kicad:
status: Expired → New
Seth Hillbrand (sethh) wrote :

The Scale parameter slider is the same as using the GDK_SCALE variable.

After you set GDK_SCALE, you make need to tweak your font scaling using gsettings (bigger scaling, bigger fonts).

gsettings set org.gnome.desktop.interface text-scaling-factor 1.5

Seth Hillbrand (sethh) wrote :

@Nick- I don't know that there's anything we can do here. This appears to be a configuration issue. The standard workaround requires tweaking for the user's configuration.

Stou Sandalski (stou) wrote :

@Seth: As I wrote in #19, the 100% and 200% buttons (attached screenshot) produce no observable effect on kicad's viewport issue but launching kicad with GDK_SCALE=1 fixes the issues regardless of what the buttons are doing. Therefore I can not imagine a way in which the buttons and the variable are doing the same thing. Also all applications I use, except for kicad, behave normally and have no issues with scaling, viewport scaling, font sizes, dpi, etc. so it doesn't make sense to set a global GDK_SCALE and font sizes and essentially break everything except kicad.

This is most definitely not a configuration issue but a bug in wx widgets when running opengl on hidpi screens (cf and likely not fixable on the kicad side without significant effort.

Leandro Heck (leoheck) wrote :

Stou, I have the same problem.
Do you have any workaround for increasing the fonts?
It is smaller than I can see.

Seth Hillbrand (sethh) wrote :

I installed Gnome to try to recreate this and I found that I could only recreate it when I had the display scale set to 200%. If you set it to 100%, KiCad works as expected. Note that this is _monitor_ dependent, so it will only affect the monitor selected and if you have multiple monitors (or a laptop with external display), you'll need to configure them separately.

Now, at 100%, the fonts are small (as you've noted). You can change this by going into "Universal Access" and choosing "Large Text" on.

Stou Sandalski (stou) wrote :

@Seth... as I wrote in #19, and #22 the 100% or 200% buttons have no effect on the viewport issue at all. Please see the attached screenshot which was taken after rebooting the machine with 100% scale.

Seth Hillbrand (sethh) wrote :

@Stou- Then it is likely that something is overriding your scale settings (maybe you are setting GDK_SCALE in a configuration file?). You can work around this by using the environmental variable or you might be able to ask around Fedora forums to see if they know what is happening. But we've moved outside of what we'll be able to address in KiCad.

Stou Sandalski (stou) wrote :

@Seth: As I wrote in #22 this is not a configuration issue with my perfectly default installation but a bug beyond the reach of the kicad team. You are welcome to close this ticket =)

John Beard (john-j-beard) wrote :

Ok, so this is kind of a WX thing, and kind of a KiCad thing.

Looks like we should be using GetContentScaleFactor() when computing the OpenGL scale factor.

However, even if we do this, it only works with WX >= 3.1 and GTK+ >= 3.10. Since WX 3.0.x is the current stable release, this means it basically doesn't work on any Linux distro. I have no idea about Windows, but I see no reference to a Windows implementation for this in the WX code.

As a stop-gap, I propose a patch like the attached, which provides a user-configurable way to set the scaling factor for OpenGL. This falls back to the WX method silently, so if the user is using a WX/GTK combo that works (i.e. after WX 3.2 is released), this option will not be needed, and by not setting it, the right thing will be done.

We could alternatively or additionally pick up the GDK_SCALE env var automatically, but I'm not sure if that's an easier method that an advanced config (also only works on GTK+, and probably isn't a default setting, as GDK is supposed to do that automagically?)

If we're anticipating a long period of supporting Hi-DPI on platforms without WX 3.2 (all the LTS distros, I guess) maybe this should be a full UI option?

Seth Hillbrand (sethh) wrote :

Hi John-

I'd be in favor of the full-UI option. At least to give folks a way to easily override the system settings when they don't work.

That said, the patch appears to not get the crosshairs correct. I normally run at 100% but if I set the ContentScaleFactor=2, my crosshair position is twice as far away from the bottom left corner in OpenGL (not under the mouse). This doesn't happen in Cairo.

John Beard (john-j-beard) wrote :

@Seth, yeah it's not a complete patch, it also makes the grid very heavy. The patch is more to say it is possible to compensate for the DPI stuff, but just not automatically.

It does work OK if you also set GDK_SCALE=2 (as then GDK is scaling the mouse events in the opposite direction, I suppose...) to simulate a (small) hi-DPI screen.

So the question is how much care do we need to take when the user has set a scale that doesn't agree with the toolkit's scaling? When you get the factor from the toolkit, you can't have a discrepancy, but when the users can set it manually, lots of things can get out of sync, because the canvas is at a totally different scale to the input event co-ordinates.

Cairo is not changed by this config, but it could hook into the same values if we know what to do with them (cairo_scale or a surface scale factor?)

Mitch (lsbcoug) wrote :

Hello. I'm new to kicad / PCB design in general. But, I just want to add that I believe I am experiencing this as well. I was using the previous stable version (5.0) and it looked OK. Upgraded to 5.1 and now I am experiencing this quartering effect also. I am using Ubuntu 18.10 with 4k monitors. Using 200% scaling for legibility.

Changed in kicad:
status: New → Triaged
importance: Undecided → High
Adrian Scripcă (benishor) wrote :

Hello all. @John's patch definitely made it for me. I can finally find KiCad usable on an XPS 15 with a 4K display using Ubuntu 18.10. I wish this would be merged into master ASAP.

Thanks John for your hard work!


John Beard (john-j-beard) wrote :

@benishor: Thanks for checking it out, and confirming it works on a real hi-DPI screen.

Here is a patch to make it a real UI (you can remove the old one). Could you just check again and make sure it works as expected? Set the scale to 2.0 (or whatever your scale is) in the main preferences.

I have also fixed the OpenGL grid thickness.

@Seth: this approach calls into the config/env var stuff a lot. Should it be cached/memoised or something?

This doesn't touch Cairo, but it could in theory use the exact same interface as OpenGL.

Seth Hillbrand (sethh) wrote :

@John- Tests fine for me. I agree, we shouldn't be calling into the config settings for each OpenGL call. The value should be stored with the GAL canvas I think.

Wayne Stambaugh (stambaughw) wrote :

@John, everything looks good to me although I have no way to test it on a high dpi monitor :(. Before you push this change, please modify it to save the setting in the GAL canvas rather than fetching the config setting for each OpenGL call. Also, cherry-pick this into the 5.1 branch.

Changed in kicad:
milestone: none → 5.1.1
Adrian Scripcă (benishor) wrote :

@John, I confirm the second patch including the UI works properly on a 4K display. The canvas scale however was not properly detected to 2.0 but was instead 1.0 so I had to manually set it. The grid thickness was also fixed and looks so much better now.

Thanks! I think this fix should be added to 5.1 and posted on some blog/twitter so that people can be made aware it exists!

Thanks again for your hard work!

John Beard (john-j-beard) wrote :

@Wayne, @Seth, absolutely, I'll sort it out. I didn't get to a finished patch on Friday, but I wanted Adrian's testing of it including the grid sooner rather than later.

@Adrian, thanks for testing and for checking the grid! It is (sadly) expected that WX will not be able to divine the real scaling on Linux (and give you a default value of 1.0) until WX 3.1. This probably means WX 3.2 release on most distros, as 3.1 is not a stable release.

However, this patch should allow KiCad to seamlessly pick it up from WX when the function does work.

I am also unsure if all the hacks in wxwidgets on OSX are still needed. AFAICT, WX does support GetContentScaleFactor() in 3.0, but not sure about older versions or if that's even what's needed for Retina displays.

KiCad Janitor (kicad-janitor) wrote :

Fixed in revision 567bdd9b9d4f51de1d2784664238a769e29abed5

Changed in kicad:
status: Triaged → Fix Committed
assignee: nobody → John Beard (john-j-beard)
John Beard (john-j-beard) wrote :

Also in 5.1.1 branch: 6f78bb6966f78bb6960a85ebb4907d63bdd7ab347ef25d9cf

Seth Hillbrand (sethh) wrote :

Nice patch. The forward compatibility is really slick.

If you want, you can use 'git cherry-pick -x SHA' to get the the "(cherry-picked from ###)" message automatically added.

Adrian Scripcă (benishor) wrote :

Awesome! This should end up in nightlies, right?

Wayne Stambaugh (stambaughw) wrote :

It should be available in nightly builds as soon as the builder servers finish. It will also be available when for stable releases 5.1.1 is released.

Nick Østergaard (nickoe) wrote :

FWIW it looks like the fix broke the windows build, so it may take a bit longer for the windows builds.

Wayne Stambaugh (stambaughw) wrote :

Here is the link error:

[ 60%] Built target pcbcommon
../../common/libcommon.a(dpi_scaling.cpp.obj):dpi_scaling.cpp:(.text+0x12a3): undefined reference to `wxPlatformInfo::Get()'
collect2.exe: error: ld returned 1 exit status

John Beard (john-j-beard) wrote :

Hmm, that's a high ironic thing to be a cross-platform breakage...

John Beard (john-j-beard) wrote :

I have pushed fixes for the breakage to both branches:

aef369f4a (master)
4e2e69c9c (5.1)

Adrian Scripcă (benishor) wrote :

Hi John,

I just noticed that the patch does not fix the 3D viewer as well. Could you please extend the patch for the 3D viewer?


Changed in kicad:
status: Fix Committed → Fix Released
To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.