Skip to content

Instantly share code, notes, and snippets.

@karliss
Last active July 20, 2019 09:36
Show Gist options
  • Save karliss/3e2da4c372ea9c49fab8652bfae0c7b8 to your computer and use it in GitHub Desktop.
Save karliss/3e2da4c372ea9c49fab8652bfae0c7b8 to your computer and use it in GitHub Desktop.
High dpi support notes

High dpi support notes

Compatiblity modes

TODO have a good understanding of backwards compatiblity modess supported by QT and various OS

OS specific highdpi support optin

Both Windows and MacOS require program to explicitly optin for full high dpi support. See QT documentation for that. Not sure how much of that QT do automatically and what needs to be done manually by us.

Failure modes

  • everything is very small
  • only font is scaled but widget dimensions are small
  • widget size is scaled but font is very small
  • sizes get messed up when moving window between monitors
  • OS or GUI toolkit upscales everything after drawing resulting in correct size but blurry or pixelated look
  • double scaling, OS scaling factor gets stacked with display's scaling factor detected by GUI toolkit resulting in excesive scaling
  • bad scaling when window is across multiple displays
    • intermediate states that don't match either display
    • widget relative scale is correct but absolute scale is too small or too big
    • absolute and relative scale is correct but picture is blurry due to picture scaling

Support level and aspects

  • doesn't work work at all even with with operating system's compatiblity modes, see failure modes
  • works with operating system's or QT compatibility mode which can be enabled by user, some parts are blurry due to automatic scaling not being perfect
  • works with single highdpi display (either reads single scaling factor from API or reads it only once during construction)
  • works in mixed monitor configration (with some glitches during transition between them)
  • works perfectly when window is across multiple displays with different scaling factors (see failure modes for various intermediate states)

I don't think last level is achievable with current OS and GUI toolkit support. Last time I checked even Windows builtin programs like calculator glitch out during transition and macOS avoids problem by bumping window in to single screen.

  • most builtin widgets are correctly scaled except some custom drawn widgets
  • all widgets including custom ones are corrrectly drawn
  • scaling factor for displays manually selected by user
  • scaling factor is chosen based on physical dpi
  • scaling factor respectd OS selected scaling factor configuration

Testing scenarios

  • normal dispaly
  • single high dpi display
  • retina macbook
  • 4k monitor
  • high dpi display + other display

Testing environments

Should be tested with latest versions of QT and OS.

  • Windows
  • MacOS
  • Linux
    • QT backends
      • X11
      • wayland + xwayland
      • wayland + QT wayland backend
    • Desktop environemts
      • Gnome
      • KDE

Possible approach for improving high dpi support in Cutter

  • creating test matrix and understanding current situation
  • het the backwards compatiblity modes working on all platforms so that Cutter is at least somewhat usable
  • fix scaling for custom widgets
  • full support without backward compatibility modes

Qt documentation mentions that intended way is calculating all the size relative to somthing else. I wonder how its supposed to be working with .UI files.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment