OpenGL, MacOS and highDPI


MacOS 10.15.3
Kicad 5.1.5-0-10_14
MBP Retina with external screen

when moving any pcb or schema from one screen to another, the scaling is off: crosshair and mouse do not overlap, contents scroll badly, etc.

NOT the workaround that is noted in, but:
option 1: go to non-accelerated mode (but then it becomes unusably slow on the internal screen)
option 2: close the window with the drawing, and open it again. The drawing will be alright now, but you’ll have the same issue when moving back to the other screen.

As I can see from other forum entries, this is related to OpenGL.

my remarks and questions:

  1. Please update the above mentioned “known-system-related-issues” page, as what is mentioned on that page is NOT the solution for this case.
  2. OpenGL is no longer supported on MacOS. See When are you planning on moving to OpenCL?
  3. In the meantime, can you do like others do: detect the screen change, and adapt the scaling? Please do not repeat what I’ve seen in other forum entries, and blame this on OpenGL or on “bad” drivers. I use plenty other OpenGL software, and most do not have this problem. This is something Kicad can solve, exactly in the same way others have done (although, admittedly, they have not always done it correctly)

This is a user forum, run by KiCad users, not developers. Some of us know a bit more about the project and even some developers lurk here sometimes, but if you want to reach the developers, you have to file bug reports (strictly one per issue) or write to the developers mailing list. Especially your main problem - Symptoms and Workaround - is good to report. Without a report it won’t be fixed.

Apple moving away from OpenGL is known already. As far as I know it’s a non-issue because in reality OpenGL will work anyways in one form or another, at least through a compatibility layer (with no significant performance or other penalty). If some day it looks like it may become an issue I’m sure the developers will consider what to do. One possibility would be to write a backend for Vulkan - MoltenVK is Open Source already. A Vulkan backend might be beneficial in other ways, too, although using Vulkan or Metal hardly would gain anything in performance.

My personal opinion is that I wouldn’t care if MacOS would be abandoned. My experiences as an Open Source user and developer have told that Apple is hostile to developers and Open Source in particular, while Apple took an Open Source product and based their OS on it. It’s a parasite, a modern day counterpart to former Microsoft who made their own standards and twisted existing standards to gain advantage in expense of everyone else, including the end users. (That’s all I have to say about Apple, there’s no use to continue that discussion. Let’s get back to technicalities and KiCad.)

1 Like

OK, I see that the DPI change detection is already mentioned in
Low priority, so maybe it will never see the light of day, but anyway.

Haven’t found the place to report the “known-system-related-issues” page though. Will look.

Almost all bugs are “low priority”, it doesn’t tell much. It just means that the users can somehow live with it and there’s no chance of data loss (crashes etc.)

Reported in the website git repo,


BTW, you can add a “thumb up”, it adds “popularity” of the bug and may affect the order the bugs are considered or fixed.

Good news for you - it was just assigned to a developer. However, it’s scheduled for 6.0 only which may be released within 1…1.5 years unless you are willing to take a risk and use unstable nightly builds.

Actually I might backport this to 5.1.6 if it gets enough testing and seems safe.


This topic was automatically closed 90 days after the last reply. New replies are no longer allowed.