HIDPI and UI Objects for Desktop?

I don’t have a retina Mac or HiDPI Windows machine but I would like to future proof the code I write, so I have started thinking about how to handle HiDPI… It seems to me that there needs to be a lot more than just image sets and scale factors in Paint events to do it right…

Looking at the language reference, Windows and RectControl sizes are still set in pixels… Shouldn’t they be in points too to be DPIMode independent?

That way they stay at about the same size on screen regardless of the DPI mode of the current screen? A UI that is OK at normal DPI might have elements that become hard to use or read (particularly for older eyes) if the are half the size! And If they are double sized at normal DPI the might be off screen…

Do the OSes not support UI Object scaling yet? If not, It seems to me that is where things need to be in this brave new world, or things are going to be very messy!

  • Karen

Windows and RectControl sizes ARE in points. That must be a bug in the docs.

On mac you can test out retina on a non-retina screen using Quartz Debug. To get it you need to log in to developer.apple.com and download the Graphics Tools which has Quartz Debug. You only need to run it once to enable HiDPI display mode and then an extra resolution will appear in System Preferences > Displays > Scaled. The HiDPI resolutions basically treat your screen as a retina screen that’s half the point size so everything scales up (and you can see where retina would be blurry).

Instructions to download Quartz Debug and enable HiDPI resolutions
https://developer.apple.com/library/mac/documentation/GraphicsAnimation/Conceptual/HighResolutionOSX/Testing/Testing.html

Personally I can not recommend testing on an actual retina machine enough, back in 2012 I converted one of our apps over to Retina testing it on a 24" iMac with fake Retina enabled and it was beautiful and smooth.

However some users complained about the app being horrifically slow to use on an actual Retina machine. So i dolled out my hard earned cash and bought a 15" Retina MacBook Pro… And sure enough the application was almost unusable on that machine. I had to work hard to optimize it, so that it would be smooth enough.

Which is why I recommend last years MacBook to anyone looking to make Retina applications, it’s slow… Which means if you can make your application run bearably or smooth on it, it’ll run nicely on everything else :slight_smile:

The Mac yes, Windows HIDPI application used to have some jiggery pokery to make them, however I’ve not tested it with 2016r1. Here’s the old article.
http://blog.xojo.com/2013/11/18/writing_high-dpi_aware_windows_apps/

Hopefully someone with a bit more Windows experience can explain if this is still the case.

What was the source of the slow down? I mean was something simply handled differently to regain speed or are real retina screens somehow inherently slower?. I can’t imagine why/how a real retina screen would have any time difference.

Oh, maybe what you mean is the slow down is because on a real retina screen the user can have a much bigger pixel sized window. So a drawing routine that’s snappy full size on a faux retina takes 4x as long full sized on a real retina.

A 640 x 480 window on a 1x screen is 0.3 megapixels of data, and 1.3 mb of memory.

On a 2x screen it becomes. 1.3 megapixels and 5mb of memory.

4 x the data, any slowdown is multiplied by 4 times.

Some things I used to improve the display time:

  • Cached as much as possible to CGLayers (which are now defunct, being broken with Layer-Backed Views) but CGlayers allow you to cache directly onto the GPU. CALayers are not a direct replacement, but can be used.
  • Invalidate( smallestPossibleRect, false ) to update the smallest area possible and not to erase the background.
  • Disabling font antialiasing on Retina gave a tiny but welcome speed boost.
  • Swapped over to using as much CG as possible.
  • When using CGGradients or NSGradients, make sure you cache them and do not recreate on every draw.
  • Cache NSAttributedStrings rather than re-create them on each draw cycle.

It was actually a good lesson, for some of the problems were down to my bad practices, such as creating some objects in the paint event and not caching them.

That is the whole point of HiDPI support. Once you have designed the app, it stays the same on 72 dpi and on Retina.

Same thing on PC where scaling can be set by percentage, like 125% or 150%, not necessarily 200%.

BTW the UI is designed in points @ 72 dpi. However, I would not be surprised if some designers decided to refine Retina rendition by going to the pixel level. Crisper and less jaggy circles on large 5k screens are probably visible just the same as crisper fonts.

Thanks all.

The Quartz Debug scaling sounds like a good idea without an actual retina screen.

  • Karen