Concerning high DPI handling on Windows, we probably all agree that sticking to physical pixels in their API was probably one of the worst mistakes Microsoft ever made. With higher resolution screens becoming the standard, physical pixels became pretty much meaningless for layout purposes. All we care about is the size of something, not how many pixels it is comprised of on whatever monitor or device maybe currently used. Nevertheless, we need to deal with this mess now.
This post may seem overly cautious, even panicked, so please bear with me. Digging into DPI hell on Windows left me so shocked, I even considerend abandoning the Windows platform altogether, if it only was economically feasible.
As far as I understand so far, Juce refers to coordinates as logical pixels. That is, all numbers used in the code or saved as XML state will denote logical pixels in order to render properly on any device if restored at a later time. Is that correct?
While I understand that transparently mapping to physical pixels under the hood for both apps and plugins/libraries is certainly a challenge (give all this is still a work in progress even at Microsoft), it would be great if there was a clear commitment that Juce will always adhere to logical pixels in its API no matter what.
Most likely there will remain a need for certain hacks or manual interventions, but the general direction should be logical pixels, so developers can rely on coding consistent layouts across platforms (TBH, I can’t even figure how it would work otherwise).
Can we?
