[Interest] Errors while building Qt 6 on Windows
Hi all, I’m trying to build Qt 6 on Windows 11, but I’m getting some errors when I run ./configure that I can’t understand the cause of. I used the following instructions: git clone git://code.qt.io/qt/qt5.git qt git checkout dev perl ./init-repository --module-subset=qtbase,qtshadertools,qtdeclarative However, when I run ./configure I get these errors: CMake Error at qtbase/cmake/QtExecutableHelpers.cmake:466 (message): Unable to build syncqt: Change Dir: C:/Qt/6.5.0/qt6_source/qt/qtbase/src/tools/syncqt/configure_time_bins Run Build Command(s):C:/Qt/Tools/Ninja/ninja.exe && [1/1] Linking CXX executable C:\Qt\6.5.0\qt6_source\qt\qtbase\bin\syncqt.exe FAILED: C:/Qt/6.5.0/qt6_source/qt/qtbase/bin/syncqt.exe cmd.exe /C "cd . && C:\Strawberry\c\bin\c++.exe -O2 -g -DNDEBUG CMakeFiles/syncqt.dir/main.cpp.obj -o C:\Qt\6.5.0\qt6_source\qt\qtbase\bin\syncqt.exe -Wl,--out-implib,libsyncqt.dll.a -Wl,--major-image-version,0,--minor-image-version,0 -lkernel32 -luser32 -lgdi32 -lwinspool -lshell32 -lole32 -loleaut32 -luuid -lcomdlg32 -ladvapi32 && cd ." C:/Strawberry/c/bin/../lib/gcc/x86_64-w64-mingw32/8.3.0/../../../../x86_64-w64-mingw32/bin/ld.exe: CMakeFiles/syncqt.dir/main.cpp.obj: in function `std::filesystem::__cxx11::operator==(std::filesystem::__cxx11::path const&, std::filesystem::__cxx11::path const&)': C:/Strawberry/c/lib/gcc/x86_64-w64-mingw32/8.3.0/include/c++/bits/fs_path.h:514: undefined reference to `std::filesystem::__cxx11::path::compare(std::filesystem::__cxx11::path const&) const' The full log can seen here https://pastebin.com/8jZ4pA3E Does anyone have any clue on what might be the problem? Best, Daljit ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Windeployqt for Windows on ARM64 missing
Hello, I’m trying to deploy my application on Windows ARM64 by cross-compiling it on my x64 machine. I was able to compile the program successfully, but couldn’t find windeployqt.exe inside C:\Qt\6.2.4\msvc2019_arm64. Is there a way to use windeployqt when deploying on Windows ARM64? Best, Daljit Singh ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Custom OpenGL drawing with Skia breaks Qt Quick Scenegraph rendering
Hi, I'm using the 2d vector graphics library Skia (with its OpenGL backend) in my Qt 5 project, but I have ran into a bug that I haven't been able to solve . To use Skia in my project, I've tried multiple different ways (using QQuickFramebufferObject, QSGRenderNode and also directly connecting to QQuickWindow::beforeRendering and other signals to draw my custom OpenGL code). However, with all the different ways I've tried, the result is that Qt Quick Scene Graph rendering becomes broken introducing artefacts such as blurry and pixelated text and icons. It seems that Skia messes up with the OpenGL state and this in turn breaks the rendering of Qt Quick items (I'm already using QQuickWindow::resetOpenGLState). I'm not exactly sure why this happens, but I've also tried isolating Skia in a separate OpenGL context (as demonstrated here https://doc.qt.io/qt-5/qtquick-scenegraph-textureinthread-example.html) and as expected the problem goes away. I've create a small GitHub repository here https://github.com/daljit97/SkiaQtBug which shows the bug (since Skia is a pain to build I've included a prebuilt binary for x64 Windows, so you should be able to just open the project in Qt Creator and run it right away). This small example follows this tutorial at the following link https://doc.qt.io/qt-5/qtquick-scenegraph-openglunderqml-example.html and shows how mixing Skia rendering calls and native Qt Quick results in blurry and pixelated Text elements. Also if you run the example with Qt 6, then the problem get slightly better (no more pixelated text) but other rendering artefacts are introduced. Has anyone got any idea on what's going on? Best, Daljit ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Low frame rate in rendering custom opengl code in Qt Quick
Hi, I'm using a third party library (Skia) to render custom opengl code in sync with the QtQuick Scene Graph (Qt 5.15 on Windows 11). I'm using the QQuickFramebufferObject and QSGRenderNode classes to create custom QQuickItems to render my scene. The approach works fine, but I've come across a very strange issue that I'm unable to solve. The problem consists in a sudden unrecoverable drop in FPS during the rendering of my scene. I've noticed that the issue presents itself whenever the rendering frame time jumps above a certain threshold (most of the times my app is able to render at 60fps, but there are times when there is a lot of content to render). When this happens, the frame rate no longer jumps back to 60 fps as expected, but instead is remains weirdly low (less than 10 fps) for the remaning time of the session. This is despite the fact on subsequent draw calls I render nothing in my opengl scene. Doing some logging with the helper logging categories provided by Qt, I can see that the scene graph that the render time is fine most of the time, but the logs consistently report an unusally high sync time in the threaded render loop. An example log message shows (other frame logs show similar times): > Debug: time in renderer: total=4ms, preprocess=0, updates=0, binding=0, > rendering=4 (scenegraph\coreapi\qsgrenderer.cpp:281, void __cdecl > QSGRenderer::renderScene(const class QSGBindable &)) > Debug: Frame rendered with 'threaded' renderloop in 134ms, sync=129, > render=4, swap=1 - (on render thread) > (scenegraph\qsgthreadedrenderloop.cpp:902, void __cdecl > QSGRenderThread::syncAndRender(class QImage *)) Has anyone got any clue about what might be going here? Best Regards, Daljit ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Using QSGRenderNode with Skia
Hi, I'm working with a drawing application where I'm using Skia (opengl backend) for rendering the content (QPainter was too slow for my needs). To do this I first used the QQuickFramebufferObject class and was successfully able to render Skia's drawing commands. However, for various reasons the QSGRenderNode class is more suited for my needs as it enables to render with no intermediate FBO. So, I tried to use it but unfortunately when I tried, the Skia drawing commands are rendered incorrectly. The coordinate system seems to be vertically mirrored and when the window application is resized, the QQuickItem moves around and translates its position unexpectedly. A full example demonstrating the issue can be downloaded here https://easyupload.io/qbi03i. Is there a way to setup QSGRenderNode so that the Skia's drawing commands are rendered as expected? Best, Daljit ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] QSGRenderNode and OpenGL rendering using QPainter
I have added a stackoverflow post which is more detailed and makes it easier to see the code. https://stackoverflow.com/questions/63937113/incorrect-rendering-using-qsgrendernode-and-qpainters-opengl-backend From: Interest on behalf of Daljit Singh Sent: Sunday, September 20, 2020 10:36:16 AM To: interest@qt-project.org Subject: [Interest] QSGRenderNode and OpenGL rendering using QPainter Hi, I wanted to make use of QSGRenderNode to paint some QML items using third party libraries (mainly Skia). So I decided to gave it a go, but I am having a trouble on understanding how to properly use this class. I have wrote a simple class derived on QQuickItem that essentially paints a QSGRenderNode using its updatePaintNode method. To paint the node, I am currently using QPainter together with QOpenGLPaintDevice, but my code produces unexpected results. Here is an example https://pastebin.com/BzMzhu41, where I am trying to create an item that paints a line from (0,0) to (400,400). I would expect this code to create a QML Item (https://pastebin.com/6ZRrMvFi) that paints a line from the top-left towards the bottom right of the item, but instead the line seems drawn with an incorrect offset. I suspect this has something to do OpenGL (on which I am not an expert on), but not really sure. Could someone point me in the right direction on how to go about this? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] QSGRenderNode and OpenGL rendering using QPainter
Hi, I wanted to make use of QSGRenderNode to paint some QML items using third party libraries (mainly Skia). So I decided to gave it a go, but I am having a trouble on understanding how to properly use this class. I have wrote a simple class derived on QQuickItem that essentially paints a QSGRenderNode using its updatePaintNode method. To paint the node, I am currently using QPainter together with QOpenGLPaintDevice, but my code produces unexpected results. Here is an example https://pastebin.com/BzMzhu41, where I am trying to create an item that paints a line from (0,0) to (400,400). I would expect this code to create a QML Item (https://pastebin.com/6ZRrMvFi) that paints a line from the top-left towards the bottom right of the item, but instead the line seems drawn with an incorrect offset. I suspect this has something to do OpenGL (on which I am not an expert on), but not really sure. Could someone point me in the right direction on how to go about this? ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Mouse/Pen input latency in Qt Quick and render loop
There is another possibility. Keep vsync but add a frame delay. That is, if you know your application can finish each frame in less than, say, 5ms, then you delay the start of each frame loop by 1000/Hz - 5 milliseconds. For 60Hz that means sleeping for 11.6ms after rendering the last frame. The render loop then reads input and renders the next frame in the remaining 5ms, giving you a latency of 5ms instead of 16.7. Thanks Nikos for your reply. I am quite new to the world of computer graphics so your thoughts were really helpful. Following your ideas, I was noticeably able to improve the latency in my application! The average render time for each frame (when not scrolling) is about 1-2 ms (I rudimentally tested this using QElapsedTimer in debug mode), since I cache what has previously been drawn in an FBO. What I did then is schedule a timer with an interval of 15ms (my screen refresh rate is 60hz) that get triggered after calling QQuickItem::update() and when the new input events from the pen come in I put them in a queue until the timer has stopped running (so effective calling the next update() slot at t > 15ms). This little hack helped quite a bit and it's very convenient since I am able to turn it off at any point I need, so when the latency is not critical (e.g. when scrolling my canvas) I switch it off. I made some rudimental test videos using my phone (60 fps 0.5 speed) which shows the improvements: Normal latency<https://imgur.com/a/LZJC1xt> vs Improved latency<https://imgur.com/c4YcdpP>. Of course, disabling vsync still gives better results. Just as an extra data point: have you tried driving the Qt Quick render loop manually, using QQuickRenderControl? Yes Giuseppe, you're right I forgot to mention that option. I am not too familiar with this class so I need to study it before attempting this. However, I would like to avoid this since it would essentially involve creating your own threaded renderer and it would require significant time to build and maintain a solution that has feature parity with the default solution provided by Qt (although from the example in the documentation it doesn't seem to be too bad). From: Interest on behalf of Nikos Chantziaras Sent: 21 August 2020 03:10 To: interest@qt-project.org Subject: Re: [Interest] Mouse/Pen input latency in Qt Quick and render loop On 19/08/2020 18:57, Daljit Singh wrote: > - the vsync issue is commonly known in competitive gaming where input > lag is quite important, one way to solve this would to limit the > framerate of the application to be slightly lower than the display > refresh rate (this > https://medium.com/@petrakeas/vsync-with-low-input-lag-50ms-lower-2437118bfa5 > provides more details). However, Qt provides no way to limit the > framerate of an app. A frame rate cap will result in a cyclic latency graph. On *average* the latency will be reduced, but individual frame will oscilate between 0 and 16.7ms of latency over time. So this actually works for bringing down average latency when playing games, but the variable latency effect might not be wanted in a professional application. > - the possibility of dynamically turning off V-Sync at runtime would > allow an app to operate in "low-latency" mode when required. Currently > this is not possible in Qt, as the QSurfaceFormat::setSwapInterval needs > to be called before the QML scene is created. > > - make the threaded renderloop not rely on Vsync throttling so low > latency and multithreaded rendering is possible, this was what I wanted > to know in my previous reply. There seem to be changes to the render > loop in Qt 6, but I am not sure if this has been implemented. There is another possibility. Keep vsync but add a frame delay. That is, if you know your application can finish each frame in less than, say, 5ms, then you delay the start of each frame loop by 1000/Hz - 5 milliseconds. For 60Hz that means sleeping for 11.6ms after rendering the last frame. The render loop then reads input and renders the next frame in the remaining 5ms, giving you a latency of 5ms instead of 16.7. If you miss the target time though, then that frame will need to wait for the next vblank, resulting in a 33.3ms frame time. Or you disable vsync for just that frame, which will give you a tear. However, there's other factors at play here as well. The GPU driver usually does not immediately send out each frame immediately to the screen when it's presented. Furthermore, since frame preparation (CPU) and frame rendering (GPU) are asynchronous in today's graphics APIs, you get several prepared frames queued up for rendering. This is the biggest contributor to latency today, not the 16.7ms frame latency of 60Hz double buffer vsync. That's why disabling vsync in games for example doesn't give you a 16.7ms reduction, it gives yo
Re: [Interest] Mouse/Pen input latency in Qt Quick and render loop
Hi Andreas, the latency issue is platform independent (I have tested my application on Windows, Linux X11 and Android. When V-Sync is enabled, there is a noticeable delay on displaying the rendered frames. For example, on a 60hz monitor the delay can be up to 16ms. When VSync is turned off this doesn't happen because the rendered frames are displayed as soon as possible without being limited by VSync throttling. As mentioned here https://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph.html#scene-graph-and-rendering: "NOTE: The threaded and windows render loops rely on the graphics API implementation for throttling, for example, by requesting a swap interval of 1 in case of OpenGL. ...Without blocking in the swap buffers operation (or elsewhere), the render loop will run animations too fast and spin the CPU at 100%. ..." Indeed if VSync is disabled (setting the swap interval to 0), the QML animations go crazy fast. In order to avoid this it's possible to use the "basic" renderloop, the only problem is that the basic render loop makes the application single-threaded (as there is no dedicated render thread) so if rendering a frame takes a little bit (like >5ms) then QML animations appear jerky as while the rendering is ongoing the animation events are blocked. Now I think there might be some ways this could be solved: - the vsync issue is commonly known in competitive gaming where input lag is quite important, one way to solve this would to limit the framerate of the application to be slightly lower than the display refresh rate (this https://medium.com/@petrakeas/vsync-with-low-input-lag-50ms-lower-2437118bfa5 provides more details). However, Qt provides no way to limit the framerate of an app. - the possibility of dynamically turning off V-Sync at runtime would allow an app to operate in "low-latency" mode when required. Currently this is not possible in Qt, as the QSurfaceFormat::setSwapInterval needs to be called before the QML scene is created. - make the threaded renderloop not rely on Vsync throttling so low latency and multithreaded rendering is possible, this was what I wanted to know in my previous reply. There seem to be changes to the render loop in Qt 6, but I am not sure if this has been implemented. Best, Daljit ________ From: Interest on behalf of Daljit Singh Sent: 15 August 2020 01:08 To: interest@qt-project.org Subject: [Interest] Mouse/Pen input latency in Qt Quick and render loop Hi, I am developing a cross platform application for displaying pen input. The project requires real-time rendering of digital ink (stylus input) and hence the latency of the rendered strokes is very important. To render the strokes I am using a custom QQuickItem together with QSGRenderNode. Unfortunately, drawing the ink results in significant latency as the input is rendered with some delay (e.g. comparing it to something like OneNote I would say there seems to be around 10-15ms more delay). I came across a previous mail thread here https://lists.qt-project.org/pipermail/interest/2014-March/011692.html where it is mentioned that this is largely due to VSync and it's possible to disable this by calling QSurfaceFormat::setSwapInterval(0). This works well and reduces the latency significantly, unfortunately it also introduces another problem: the render loop for the Qt Quick scenegraph must be set to "basic" otherwise QML animations go a bit crazy. My application requires that some of the ink to be rendered when the user is scrolling a large canvas (for which I am currently using Flickable), but using the basic render loop results in the animation being quite jerky (so scrolling is not smooth at all) as while the strokes are rendered the animation system is stopped (at least this is my understanding). Is there a way to overcome what I described? I only require the app to be in "low-latency" mode while the user is drawing on the screen and for all other scenario I would like to stick with the threaded render loop. Best, Daljit ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
Re: [Interest] Mouse/Pen input latency in Qt Quick and render loop
To follow up on this, I was looking at the source code for the renderloop in the Qt repositories and I found this comment here https://github.com/qt/qtdeclarative/blob/dev/src/quick/scenegraph/qsgrenderloop.cpp#L79: [https://avatars2.githubusercontent.com/u/159455?s=400&v=4]<https://github.com/qt/qtdeclarative/blob/dev/src/quick/scenegraph/qsgrenderloop.cpp#L79> qt/qtdeclarative<https://github.com/qt/qtdeclarative/blob/dev/src/quick/scenegraph/qsgrenderloop.cpp#L79> Qt Declarative (Quick 2). Contribute to qt/qtdeclarative development by creating an account on GitHub. github.com - Uses one QRhi (and so OpenGL Context, Vulkan device, etc.) to render multiple windows. - This assumes multiple screens can use the OpenGL context. - Animations are advanced using the standard timer, so QML animations run as expected even when vsync throttling is broken. Does that mean that with Qt6 the "threaded" render loop used by the QML SceneGraph has animations correctly even when v-sync is disabled? ________ From: Daljit Singh Sent: 15 August 2020 01:08 To: interest@qt-project.org Subject: Mouse/Pen input latency in Qt Quick and render loop Hi, I am developing a cross platform application for displaying pen input. The project requires real-time rendering of digital ink (stylus input) and hence the latency of the rendered strokes is very important. To render the strokes I am using a custom QQuickItem together with QSGRenderNode. Unfortunately, drawing the ink results in significant latency as the input is rendered with some delay (e.g. comparing it to something like OneNote I would say there seems to be around 10-15ms more delay). I came across a previous mail thread here https://lists.qt-project.org/pipermail/interest/2014-March/011692.html where it is mentioned that this is largely due to VSync and it's possible to disable this by calling QSurfaceFormat::setSwapInterval(0). This works well and reduces the latency significantly, unfortunately it also introduces another problem: the render loop for the Qt Quick scenegraph must be set to "basic" otherwise QML animations go a bit crazy. My application requires that some of the ink to be rendered when the user is scrolling a large canvas (for which I am currently using Flickable), but using the basic render loop results in the animation being quite jerky (so scrolling is not smooth at all) as while the strokes are rendered the animation system is stopped (at least this is my understanding). Is there a way to overcome what I described? I only require the app to be in "low-latency" mode while the user is drawing on the screen and for all other scenario I would like to stick with the threaded render loop. Best, Daljit ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
[Interest] Mouse/Pen input latency in Qt Quick and render loop
Hi, I am developing a cross platform application for displaying pen input. The project requires real-time rendering of digital ink (stylus input) and hence the latency of the rendered strokes is very important. To render the strokes I am using a custom QQuickItem together with QSGRenderNode. Unfortunately, drawing the ink results in significant latency as the input is rendered with some delay (e.g. comparing it to something like OneNote I would say there seems to be around 10-15ms more delay). I came across a previous mail thread here https://lists.qt-project.org/pipermail/interest/2014-March/011692.html where it is mentioned that this is largely due to VSync and it's possible to disable this by calling QSurfaceFormat::setSwapInterval(0). This works well and reduces the latency significantly, unfortunately it also introduces another problem: the render loop for the Qt Quick scenegraph must be set to "basic" otherwise QML animations go a bit crazy. My application requires that some of the ink to be rendered when the user is scrolling a large canvas (for which I am currently using Flickable), but using the basic render loop results in the animation being quite jerky (so scrolling is not smooth at all) as while the strokes are rendered the animation system is stopped (at least this is my understanding). Is there a way to overcome what I described? I only require the app to be in "low-latency" mode while the user is drawing on the screen and for all other scenario I would like to stick with the threaded render loop. Best, Daljit ___ Interest mailing list Interest@qt-project.org https://lists.qt-project.org/listinfo/interest
