Avoiding HiDPI

Targets macOS
1

Despite some pretty hefty code refactoring, I have been getting the odd report that my software runs extremely slowly -
but on the biggest and supposedly fastest Macs.

Looking through such support calls, a common factor are the 27inch 5K 3.xGhz machines - which should blow my modest development Macbook Pro 2015 Retina into the dust.

I have come to the conclusion that the sheer volume of pixels I have to throw about (and associated backup graphics in memory that I use for some actions) , is eating memory.
I have discovered that if I get them to tick the ‘open in Low resolution’ attribute in ‘Get Info’, things run properly.

So: while I consider how to reduce memory, is there a way to

-make the app decide to do this for itself at run time, (I dont think it will be possible to modify the plist while the app is running)
or
-set the flag using a shell command?

2

In theory; yes. And it can be with App Wrapper. I’m not in the office right now so I can’t look up the correct key.

3

Yeah, I actually use Appwrapper to set it in the first place.
It will be NSHighResCapable or similar.
And most of the time I want that set.

I think my ideal for the big screens would be getting the menus sharp, and keep the gfx lowres.

4

I would encourage you to do some insvestigation into your graphics code. The simple suggestions will take time to implement, but will improve performance.

Drawing via Graphics:

  1. Try to move as much calculation and logic code out as possible, so in the paint event you do as little work as possible.
  2. Avoid resizing images when drawing. If your image is going to be displayed at a certain size, but you’re drawing a much larger image down, consider doing this once to an offscreen bitmap.
  3. Avoid caching, contradictory to the above point, but don’t buffer the entire graphics class, then draw it to screen. Do as much drawing directly to the graphics class as possible, except in the circumstance above!
  4. When drawing images, disable anti-alias.
  5. If you’re drawing text, try to reduce the number of font variants.

OpenGL or Metal:

  1. Make sure you’re not using wide gamut unless you need it.
  2. Try to match the context as close to the screen, bit-depth and color space.
  3. If you don’t need color matching, disable it.
  4. For Metal, Apple claim a possible 2x improvement by re-writing your shaders in pure metal, precompiling and peocessing 4 pixels in one go.
  5. For Metal, if your pipeline is slow, consider using Synchronous updating (reduces stuttering).
  6. If you use OpenGL, consider switching to Metal, but be warned there is many gotchyas with Metal, which are undocumented, and Metal is inconsistent, what works on one machine may not work on another, I’ve even had failures between the integrated GPU amd dedicated one.

Thats all I can think of roght now.

5

I have reported a ‘bug/unwanted new feature’ in the past which involved a large ( percentage ) increase in the time taken by .drawpicture if the target size is not the same as the source size.
This suddenly came into Xojo about 3 or 4 years back, if memory serves.
Most people wouldn’t notice the slowdown, but parts of my app do up to a million drawpictures in a loop… the tiniest difference in one call was causing seconds of difference in total.
So I did a bunch of work around that a while back… generating image sets of ‘the right size’ once when the app starts or only when absolutely needed. It was never fixed in Xojo.

I’ll be looking for other things I can shift.

Points 1 and 3 (as you know) kinda contradict each other. Right now, I do use the buffering method.
Maybe that will have to go.

(OpenGL / Metal - not using these, just standard graphics.
I’ve debated them - since I suppose they are designed for fast gfx work - but I dont understand how to use them, and my impression is that cross platform use is out anyway)

6

Yes, if the value is True, YES or 1; it’s to enable it. So I would image that false, No or 0 would disable it. However this will probably affect your menus and system controls.

In all fairness, I don’t think that this is a Xojo issue, I would say that it’s most likely an OS issue. Now technically the OS should cache that resized image and only draw the cached version on subsequent draws, however to be sure, resizing it yourself so that it’s “Pixel Perfect” reduces this concern.

I still miss GLLayers, these were off-screen bitmaps directly on the GPU, which meant they were super fast!

[quote=483187:@Jeff Tullin]Points 1 and 3 (as you know) kinda contradict each other. Right now, I do use the buffering method.
Maybe that will have to go.[/quote]
Yes, it does contradict and I apologize about that, sometimes I am horrendous at explaining things (even worse when my words don’t come out in the correct order, or even the letters of words don’t). Please allow me to try again.

  1. Logic code, perhaps layout code is a better explanation. Basically if you can cache draw locations, text, text widths, sizes, any of that sort of calculation, you’ll save time in the paint event. It’s hard, it’s really hard I know. But it does make a difference.
  2. Under the macOS, you’re burning resources and time by drawing to a large picture and then drawing that large picture (unless you’re drawing a photograph or something), otherwise try to keep it as direct as possible.

Yes they are hard, and not x-plat at all. At least with OpenGL, you stood some chance, with Metal you don’t. What makes it harder is there’s a lot of things I’ve had to figure out (poor documentation or because those that have done it already are like me and don’t have the time to write it up nicely).

With both OpenGL or Metal, it’s the opportunity to basically utilize GPU processing, gives you the potential to have improved performance, actually getting the most optimal performance, can take years, I’m still figuring out Metal, 3 years after I first started, and in some circumstance, my code STILL runs much faster in OpenGL than Metal (like WAY faster), but I don’t really have much choice going forwards.