Rendering performance problems on iMac with Retina 5K
-
New observations:
- The problem appears on MacBooks with Retina displays (<5k) as well (slow framerate, slow GUI response).
- On MacBooks with "normal" (no Retina, 1440x900) display the the framerate is also significantly slower under Mac comparing to Windows => It is not a Retina problem but the problem either of Mac OS X itself or the Qt implementation on Mac.
Some particular times:
Method | Win10[ms] | Mac[ms]
QGraphicsView::paintEvent() | 4-6 | 4-6
QPixmap::fromImage() | <1 | <1
QTimer::singleShot(1…) timeout | 7-9 | 40-50 *)*)
As for the QTimer::singleShot()... It is very strange. If the window is maximized (under Mac), the timeout is 40-50ms, but if the windows is small then the timeout is significantly lesser (2ms for example). On Windows the timer varies from <1ms to 7ms depending on the window size. The timer type was Qt::PreciseTimer.I wonder how the QTimer::singleShot() works. And how the application process other GUI events while the timer is running? My observation is (as I already have written) that the GUI responsivity is significantly slower under Mac comparing to Windows even if the framerate is much more better under Windows. I have to look into the source codes...
-
New observations:
- The problem appears on MacBooks with Retina displays (<5k) as well (slow framerate, slow GUI response).
- On MacBooks with "normal" (no Retina, 1440x900) display the the framerate is also significantly slower under Mac comparing to Windows => It is not a Retina problem but the problem either of Mac OS X itself or the Qt implementation on Mac.
Some particular times:
Method | Win10[ms] | Mac[ms]
QGraphicsView::paintEvent() | 4-6 | 4-6
QPixmap::fromImage() | <1 | <1
QTimer::singleShot(1…) timeout | 7-9 | 40-50 *)*)
As for the QTimer::singleShot()... It is very strange. If the window is maximized (under Mac), the timeout is 40-50ms, but if the windows is small then the timeout is significantly lesser (2ms for example). On Windows the timer varies from <1ms to 7ms depending on the window size. The timer type was Qt::PreciseTimer.I wonder how the QTimer::singleShot() works. And how the application process other GUI events while the timer is running? My observation is (as I already have written) that the GUI responsivity is significantly slower under Mac comparing to Windows even if the framerate is much more better under Windows. I have to look into the source codes...
@PetrM Looks like no one wants to solve this problem during recent years. I waited since 2013 and all Steinberg products (they use Qt) are having really bad video performances on macOS under HiDPI mode (not so bad with Dorico due to their optimization, and they are still working on this to make it better. Still, Qt needs to do something).
Meanwhile, PreSonus wrote their own cross-platform framework and their apps runs at 60fps on macOS under HiDPI mode.
I am not blaming Steinberg because their limited developer resources are supposed to be dedicated to the audio functionality of their apps. Nevertheless, Steinberg is definitely not the only victim of Qt's lack of fully-powered macOS HiDPI video acceleration support.
In your case, it needs to be addressed that Qt is not your only choice. I don't know how Xamarin (Visual Studio for Mac, available now) performs, but you may want to try.
-
@ShikiSuen It's a bit quick to say that no ones wants to solve the problem. High DPI support has improved since @PetrM wrote this post. And work is currently going on on the subject.
Also there have been several releases of Qt done in between. You can't blame Qt based on software editor products not working as you want/expect without a least checking wether they are running an up to date version of Qt with they product.
-
@ShikiSuen It's a bit quick to say that no ones wants to solve the problem. High DPI support has improved since @PetrM wrote this post. And work is currently going on on the subject.
Also there have been several releases of Qt done in between. You can't blame Qt based on software editor products not working as you want/expect without a least checking wether they are running an up to date version of Qt with they product.
@SGaist said in Rendering performance problems on iMac with Retina 5K:
@ShikiSuen It's a bit quick to say that no ones wants to solve the problem. High DPI support has improved since @PetrM wrote this post. And work is currently going on on the subject.
Also there have been several releases of Qt done in between. You can't blame Qt based on software editor products not working as you want/expect without a least checking wether they are running an up to date version of Qt with they product.
Thanks for your reply with your most-recent information. I already send the link of this thread to some people in Steinberg and MakeMusic (Finale), and they may come here to read your information. I do apologize for my too-quick words caused by my 4-years waiting for HiDPI video performance improvements of Steinberg Cubase and MakeMusic Finale, this drove me sick.
I would better post a screenshot using Cubase 8.5 under macOS Sierra (running on a compatible PC), Low DPI 1600x900 using Geforce GTX 950 (better than the AMD M395X shipped with iMac 5k). The screenshot (Quartz Debug running at the bottom right of the screen) indicates: 1) Cubase using Qt could not fully occupy the graphics to keep 60fps; 2) The performance meter at the bottom left of the screen indicates that this is not CPU bottleneck. // You could think of the deducted performance on a 5k display w/ macOS HiDPI mode.
-
Something's not clear from your description: what do you mean by "compatible PC" ?
-
- And how the application process other GUI events while the timer is running?
well that normally happens via the exec() for the Application object as normally seen in main.cpp.
-
Further tests I did proved that what @SGaist said is right. Steinberg Dorico 1.0.0 (my purchased copy) may occupied later versions of Qt and it could be 60fps under Retina HiDPI mode (Intel Iris Graphics only, MacBook Pro early-2015 13-inch) while scrolling sheetmusic pages only. If resizing window or zooming score pages, there is an FPS bottleneck choking the FPS at maximum 29~30fps. AFAIK, according to what Daniel Spreadbury announced through certain online communities, Dorico team is now dedicating to the UI responsiveness optimization for future Dorico updates. Now I am wondering whether the current version of Qt supports Metal.
-
Further tests I did proved that what @SGaist said is right. Steinberg Dorico 1.0.0 (my purchased copy) may occupied later versions of Qt and it could be 60fps under Retina HiDPI mode (Intel Iris Graphics only, MacBook Pro early-2015 13-inch) while scrolling sheetmusic pages only. If resizing window or zooming score pages, there is an FPS bottleneck choking the FPS at maximum 29~30fps. AFAIK, according to what Daniel Spreadbury announced through certain online communities, Dorico team is now dedicating to the UI responsiveness optimization for future Dorico updates. Now I am wondering whether the current version of Qt supports Metal.
@ShikiSuen said in Rendering performance problems on iMac with Retina 5K:
Metal
https://forum.qt.io/topic/42356/qt-and-apple-s-metal
As far as I know it do not.
Just as it do not support (directly) DirectX and other OS bound techs.Also 4K+ screens are not that common yet.
https://www.w3counter.com/globalstats.php
so Im not sure getting Metal support has high focus. (purely guessing)
But note that hi-res support have gotten some love and improved a lot. -
@ShikiSuen said in Rendering performance problems on iMac with Retina 5K:
Metal
https://forum.qt.io/topic/42356/qt-and-apple-s-metal
As far as I know it do not.
Just as it do not support (directly) DirectX and other OS bound techs.Also 4K+ screens are not that common yet.
https://www.w3counter.com/globalstats.php
so Im not sure getting Metal support has high focus. (purely guessing)
But note that hi-res support have gotten some love and improved a lot.@mrjj said in Rendering performance problems on iMac with Retina 5K:
@ShikiSuen said in Rendering performance problems on iMac with Retina 5K:
Metal
https://forum.qt.io/topic/42356/qt-and-apple-s-metal
As far as I know it do not.
Just as it do not support (directly) DirectX and other OS bound techs.Also 4K+ screens are not that common yet.
https://www.w3counter.com/globalstats.php
so Im not sure getting Metal support has high focus. (purely guessing)
But note that hi-res support have gotten some love and improved a lot.Thanks. Looks like my suggestion of using Xamarin in lieu of Qt still makes sense at this moment:
https://developer.xamarin.com/guides/mac/platform-features/introduction-to-macos-sierra/
Note that Apple is phasing out their non-retina models. Graphic acceleration efficiency necessities on Retina MacBook Pro models and Retina iMac models are the same. Qt is already 4 years late for this and has no reason to refer the global stats (because they count windows computers) for reasons of postponing Metal support for macOS. -
Update: @mrjj did not tell me anything regarding the difference between Qt QML and Qt Widgets.
Thanks to some answers from experts on Zhihu. Now the reason of the performance issue has been found out: Qt Widgets is a deprecated approach which never consults GPU for UI graphic manipulation.
The solution is simple: Use Qt Quick + QML instead.
-
Update: @mrjj did not tell me anything regarding the difference between Qt QML and Qt Widgets.
Thanks to some answers from experts on Zhihu. Now the reason of the performance issue has been found out: Qt Widgets is a deprecated approach which never consults GPU for UI graphic manipulation.
The solution is simple: Use Qt Quick + QML instead.
@ShikiSuen
Super.
QML is not intended for heavy calculations so for that kind of program you will need
Qt Quick + QML instead + C++ backend. -
Hi PetrM.
Please update the link to your "working example" - it reports "File Not Found" now.
I'd like to reproduce your results on my MacBook. -
Hi PetrM.
Please update the link to your "working example" - it reports "File Not Found" now.
I'd like to reproduce your results on my MacBook. -
Update: @mrjj did not tell me anything regarding the difference between Qt QML and Qt Widgets.
Thanks to some answers from experts on Zhihu. Now the reason of the performance issue has been found out: Qt Widgets is a deprecated approach which never consults GPU for UI graphic manipulation.
The solution is simple: Use Qt Quick + QML instead.
@ShikiSuen said in Rendering performance problems on iMac with Retina 5K:
Update: @mrjj did not tell me anything regarding the difference between Qt QML and Qt Widgets.
Thanks to some answers from experts on Zhihu. Now the reason of the performance issue has been found out: Qt Widgets is a deprecated approach which never consults GPU for UI graphic manipulation.
The solution is simple: Use Qt Quick + QML instead.
You can't be serious. That's equivalent to tearing down your house and rebuilding it from the foundation. That's not a "simple" solution.
I too have experienced QWidgets - in my case with QLabel poor rendering performance, and strangely enough, Hackintosh in Virtual box runs faster than better specced native hardware.
-
@mrjj @ShikiSuen there is a real performance problem not with QWidgets, but with QWidgets's macOS implementation. I'm dual booting macOS/Linux on a retina macbook, and all the QWidgets applications I use, QtCreator, Clementine, Wireshark, (and the ones I develop) are much more fluid and smooth under Linux than MacOS even though it's the same hardware and screen resolution.
-
@mrjj @ShikiSuen there is a real performance problem not with QWidgets, but with QWidgets's macOS implementation. I'm dual booting macOS/Linux on a retina macbook, and all the QWidgets applications I use, QtCreator, Clementine, Wireshark, (and the ones I develop) are much more fluid and smooth under Linux than MacOS even though it's the same hardware and screen resolution.
@jcelerier
What resolution was it ? -
@jcelerier
What resolution was it ? -
If anyone's interested I did a pass through Xcode's performance tools and put the trace here :
as you can see, roughly 25% of the time is spent in CGContextDrawImage. This was with QtCreator, but I have similar findings when benchmarking my app.
-
Super.
Hopefully a fix comes out of it if possible.
