Poor performance with HiDPI display

[magalexParticipant]

Hello! Sorry if the topic is in the wrong category…

Faced the problem of very slow graph rendering on a high-resolution monitor (any changes entail almost a minute redrawing of the graph with an unresponsive program and 100% CPU load).

I save myself for now by enabling the “Open in low resolution” option in the DataGraph.app properties (the graphics are updated instantly in this mode), but because of this, the fonts look blurry, and my eyes quickly get tired…

Tell me, is there any other way to reduce the load on the processor?

DataGraph 4.7.1, macOS 11.6, Mac Pro Late 2013, 3840 × 2160 LCD, 117048 rows and 16 columns of data.

[jordanParticipant]

Do you have grid lines enabled on the graph? Turn them off if you do and see if that improves performance. I have seen grid lines kill the performance on some of my work.

[magalexParticipant]

No, grid lines are disabled…

[davidModerator]

There is a known issue with rendering complicated paths in Core Graphics.

I first reported it in 2012, here is an Xcode project that shows what happens

https://www.visualdatatools.com/SpeedTest.zip

This is likely what you are running into. The issue is that when a line is drawn on the screen with a line width more than one pixel Apple uses a different drawing routine than for lines that are one pixel or less. When the shape is simple this code works perfectly fine but when it has a lot of overlaps rendering slows down drastically.

This is the reason why the default line thickness is 0.5 which is one pixel on retina screens. When the thickness is 1 the line is two pixels on retina and 1 pixel on non-retina. Move the line thickness to 1.5 or 2 (or even 1.0001) and things slow down drastically on the non-retina.

This also means that if you export the graph with 0.5 pixels and everything draws fast on the screen and then open the pdf in preview and scale the graphic up speed goes down drastically.

The same happens when you have a dotted line. My guess is that with a thin line they use the GPU to render and for lines where the line joins have to be done carefully they use code that has bad scaling properties when the line is noisy (overlaps).

One thing that speeds things up a little bit is to adjust the line join option in the Plot command. Miter is slower than the other options. I already do a lot of processing to avoid this but it is not easy to predict how slow the rendering routine will be.

[magalexParticipant]

Thank you, David, for a detailed explanation!

Indeed, decreasing the line thickness from 1 to 0.5 radically changed the situation, the graph began to update instantly. And yes, the data stream is quite dense and noisy:

[magalexParticipant]

Thank you, David, for a detailed explanation!

Indeed, decreasing the line thickness from 1 to 0.5 radically changed the situation, the graph began to update instantly. And yes, the data stream is quite dense and noisy:

[magalexParticipant]

Thank you, David, for a detailed explanation!

Indeed, decreasing the line thickness from 1 to 0.5 radically changed the situation, the graph began to update instantly. And yes, the data stream is quite dense and noisy:

[Author]

Posts