Rendering performance problems on iMac with Retina 5K
-
Hello,
I originally posted this topic (I recommend to read it first but it is not necessary): https://forum.qt.io/topic/59466/image-rendering-performance-problem-on-imac-retina-5kt but no one has replied. Now I have a better description of the problem and I also attached working example.Whats going on?
I have a problem with image rendering performance on iMac with Retina 5K. On this link you can download the working example program. The program creates an serie of images then it starts rendering in the showEvent() and it also continually displays the current framerate in the status bar. Here are the most important methods:MainWindow::MainWindow(QWidget *parent) : QMainWindow(parent),ui(new Ui::MainWindow) { ui->setupUi(this); m_iFramesDrawn = -1; m_iImgCounter = 0; //prepare the images to be rendered for (int i = 0; i < IMG_COUNT; i++) m_images[i] = prepareImage(i); m_pView = new QGraphicsView(this); setCentralWidget(m_pView); m_pScene = new QGraphicsScene(); m_pView->setScene(m_pScene); QImage *pFirstImage = &m_images[0]; m_pPixItem = new QGraphicsPixmapItem(); m_pPixItem->setTransformationMode(Qt::FastTransformation); m_pPixItem->setPixmap(QPixmap::fromImage(*pFirstImage)); m_pScene->addItem(m_pPixItem); m_pScene->setSceneRect(0, 0, pFirstImage->width(), pFirstImage->height()); m_pView->fitInView(m_pPixItem, Qt::KeepAspectRatio); } void MainWindow::showEvent(QShowEvent *) { zoomFitToScreen(); drawImage(); // start repainting } void MainWindow::drawImage() { // calc FPS if (m_iFramesDrawn == -1) { m_iFramesDrawn = 0; m_timer.start(); } else if (m_timer.elapsed() > 1000) // every second { double dFps = m_iFramesDrawn * 1000 / (double)m_timer.restart(); ui->statusBar->showMessage(QString("fps = %1").arg(dFps, 0, 'f', 1)); m_iFramesDrawn = 0; } // draw next image m_iImgCounter = (m_iImgCounter+1)%IMG_COUNT; m_pPixItem->setPixmap(QPixmap::fromImage(m_images[m_iImgCounter])); m_iFramesDrawn++; // schedule for next image QTimer::singleShot(1, this, SLOT(drawImage())); } QImage MainWindow::prepareImage(int idx) { QPixmap pix(1024, 768); pix.fill(Qt::gray); QPainter p(&pix); p.setFont(QFont("Arial", 50)); p.setPen(Qt::white); p.drawText(QRect(0, 0, pix.width(), pix.height()), Qt::AlignCenter, QString::number(idx)); p.end(); return pix.toImage(); }
When I run this program on iMac with Retina 5K then I got these framerates (the application was maximized!):
Screen resolution / rendering FPS
3200x2560 / 14.5
2560x1440 / 20
1600x900 / 60Exactly the same program on the same hardware but on Windows 10 (started from Bootcamp) gave these framerates:
3840x2160 / 125
2560x1440 / 300
1600x900 / 655The side effect was that the program running on Mac had very slow responsivity (>5 sec if I clicked the close button for example) while on the Windows the responsivity was always excelent.
Could someone tell me where is the problem? It seems to me there is something wrong in the Qt's...
Thank you for any usefull hint.
-
Hi, very good description.
I do agree its odd with such a big difference.
For test, have you tried the 40000 sample to see if that also becomes really slow at 5k display?
-
Ok super , so now we know its not just because its 5k.
I tried your code on my laptop with win 7.
At 1920x1080 (maximized), I ran around 60 fps.
So maybe win 10 has better driver / does something different.You could time different pieces of the code to pinpoint where it takes much longer on mac.
One operation that can be expensive is the QImage to Pixmap convert
(QPixmap::fromImage) but still such HUGE different is indeed odd. -
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.
-
@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.
-
@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.
-
@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. -
@DmitryGrig
The link above is working now. Or just click here. -
@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.