Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • Users
  • Groups
  • Search
  • Get Qt Extensions
  • Unsolved
Collapse
Brand Logo
  1. Home
  2. General talk
  3. Blog
  4. Qt Canvas Painter blog post series
Qt 6.11 is out! See what's new in the release blog

Qt Canvas Painter blog post series

Scheduled Pinned Locked Moved Unsolved Blog
19 Posts 8 Posters 2.6k Views 2 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • B beeka

    @Kaj-Gronholm There are many cases where GPL is problematic but LGPL would work. While I understand the commercial imperative, it is depressing that nothing new is being contributed to the core Qt (I appreciate there are bug fixes). It doesn't feel like a "difficult decision" but instead what is now normal. It is also frustrating that the commercial license is too expensive for me to justify to management (together with the clause preventing switching part-way through development). I still had hope that small features or performance-focused improvements might still find a home under the LGPL, but that does not look likely now.

    K Offline
    K Offline
    Kaj Gronholm
    wrote on last edited by
    #10

    @beeka I'm confident the licensing feedback will be monitored and adjusted if needed. Also, I'm sure there are ways to avoid the part-way through development issue. If in doubt, please get your management in touch with our sales representatives.

    1 Reply Last reply
    0
    • K Offline
      K Offline
      Kaj Gronholm
      wrote on last edited by
      #11

      The third post of the trilogy is out now: https://www.qt.io/blog/accelerated-2d-canvas-benchmarks

      TL;DR: Canvas Painter can be up to 10 times faster than QPainter with the OpenGL backend. Please read the blog post for details and comment here with your own results!

      1 Reply Last reply
      0
      • kkoehneK Offline
        kkoehneK Offline
        kkoehne
        Moderators
        wrote on last edited by kkoehne
        #12

        While I understand the commercial imperative, it is depressing that nothing new is being contributed to the core Qt (I appreciate
        there are bug fixes). It doesn't feel like a "difficult decision" but instead what is now normal.

        I can understand the frustration, but it's simply not true that everything 'new' in Qt is released only under Qt Commercial + GPL3 licenses. Actually the other three new modules in Qt 6.11 - Qt TaskTree, Qt OpenAPI and Qt Labs StyleKit - are made available under Qt Commercial + LGPLv3! And there are also new features in a lot of established Qt modules ...

        This obviously doesn't help you though if you are interested primarily on Qt CanvasPainter.

        Director R&D, The Qt Company

        1 Reply Last reply
        0
        • D Offline
          D Offline
          Dyami Caliri
          wrote last edited by
          #13

          This is really cool, and something I've been waiting for to be able to transition our software from OpenGL to QRhi.

          However, in my first attempts to use it, I can't seem to do what I want to do: use QCanvasPainter to draw OVER other content I've already drawn within a QRhi render pass. It seems to insist on clearing the contents. I want to draw grids, masking marks, and text over 2D composited images I've already drawn.

          Is this possible?

          A 1 Reply Last reply
          0
          • D Dyami Caliri

            This is really cool, and something I've been waiting for to be able to transition our software from OpenGL to QRhi.

            However, in my first attempts to use it, I can't seem to do what I want to do: use QCanvasPainter to draw OVER other content I've already drawn within a QRhi render pass. It seems to insist on clearing the contents. I want to draw grids, masking marks, and text over 2D composited images I've already drawn.

            Is this possible?

            A Offline
            A Offline
            agocs
            wrote last edited by
            #14

            @Dyami-Caliri said in Qt Canvas Painter blog post series:

            This is really cool, and something I've been waiting for to be able to transition our software from OpenGL to QRhi.

            However, in my first attempts to use it, I can't seem to do what I want to do: use QCanvasPainter to draw OVER other content I've already drawn within a QRhi render pass. It seems to insist on clearing the contents. I want to draw grids, masking marks, and text over 2D composited images I've already drawn.

            Is this possible?

            Yes. See https://doc-snapshots.qt.io/qt6-dev/qcanvasrhipaintdriver.html#endPaint (esp. the second snippet with the DoNotRecordRenderPass flag)

            This can be seen in action in the hellorhi2 manual test that renders a triangle with QRhi and then some QCanvasPainter-based rendering within the same pass within a QRhiWidget: https://code.qt.io/cgit/qt/qtcanvaspainter.git/tree/tests/manual/hellorhi2/hellorhi2.cpp?h=6.11#n97
            (there is no public example for this kind of low-level usage currently, perhaps it is something we should consider, since this is definitely a valid and important use case for QCanvasPainter)

            D 1 Reply Last reply
            1
            • A agocs

              @Dyami-Caliri said in Qt Canvas Painter blog post series:

              This is really cool, and something I've been waiting for to be able to transition our software from OpenGL to QRhi.

              However, in my first attempts to use it, I can't seem to do what I want to do: use QCanvasPainter to draw OVER other content I've already drawn within a QRhi render pass. It seems to insist on clearing the contents. I want to draw grids, masking marks, and text over 2D composited images I've already drawn.

              Is this possible?

              Yes. See https://doc-snapshots.qt.io/qt6-dev/qcanvasrhipaintdriver.html#endPaint (esp. the second snippet with the DoNotRecordRenderPass flag)

              This can be seen in action in the hellorhi2 manual test that renders a triangle with QRhi and then some QCanvasPainter-based rendering within the same pass within a QRhiWidget: https://code.qt.io/cgit/qt/qtcanvaspainter.git/tree/tests/manual/hellorhi2/hellorhi2.cpp?h=6.11#n97
              (there is no public example for this kind of low-level usage currently, perhaps it is something we should consider, since this is definitely a valid and important use case for QCanvasPainter)

              D Offline
              D Offline
              Dyami Caliri
              wrote last edited by
              #15

              @agocs That's brilliant. Thank you. I'm sorry I didn't read the documentation more thoroughly.

              1 Reply Last reply
              0
              • D Offline
                D Offline
                Dyami Caliri
                wrote last edited by
                #16

                I'm making great progress with using this in our application. The antialiasing is really excellent.

                One thing I've noticed is that QCanvasImage does not seem to have a devicePixelRatio. So, if I create one from a QImage that is a retina @2x resource, I have to then know when I paint to pass in the calculated width and height. Is my understanding correct, or am I missing something again?

                K 1 Reply Last reply
                0
                • D Dyami Caliri

                  I'm making great progress with using this in our application. The antialiasing is really excellent.

                  One thing I've noticed is that QCanvasImage does not seem to have a devicePixelRatio. So, if I create one from a QImage that is a retina @2x resource, I have to then know when I paint to pass in the calculated width and height. Is my understanding correct, or am I missing something again?

                  K Offline
                  K Offline
                  Kaj Gronholm
                  wrote last edited by
                  #17

                  @Dyami-Caliri Thanks!

                  You are correct, QCanvasImage currently works on actual pixels and doesn't take into account devicePixelRatio or "@nx" images. So it matches with "lower-level" APIs behavior mentioned here https://doc.qt.io/qt-6/highdpi.html#drawing

                  Please tell what would be the expected behavior in your opinion? What would QCanvasImage width&height return, how would different drawImage() methods behave, should there be additional API etc. Thanks!

                  1 Reply Last reply
                  0
                  • D Offline
                    D Offline
                    Dyami Caliri
                    wrote last edited by
                    #18

                    @Kaj-Gronholm Thank you for clarifying.

                    It seems to me that the rest of the QCanvasPainter does take devicePixelRatio into account. If you call the QCanvasRhiPaintDriver::beginPaint method that takes logicalSize and dpr parameters, the painter will automatically scale points and line widths, so that the drawing looks the same across different dpr screens. I have confirmed this with testing.

                    The main difference in behavior I would expect is for QCanvasPainter::drawImage(const QCanvasImage &image, float x, float y) to draw the image based on the logical dimensions (dimensions / image_dpr). So, if I've created a QCanvasImage from a QImage with dpr=2, these should be equivalent:
                    painter->drawImage(retinaImg, x, y);
                    painter->drawImage(retinaImg, x, y, retinaImg.width() / 2, retinaImg.height() / 2);

                    Or, put another way, if I had a @1px image and painted it with
                    painter->drawImage(img, x, y),
                    and then replaced it with a @2px or @3px image, I would expect it to take the same amount of logical space on the screen.

                    K 1 Reply Last reply
                    0
                    • D Dyami Caliri

                      @Kaj-Gronholm Thank you for clarifying.

                      It seems to me that the rest of the QCanvasPainter does take devicePixelRatio into account. If you call the QCanvasRhiPaintDriver::beginPaint method that takes logicalSize and dpr parameters, the painter will automatically scale points and line widths, so that the drawing looks the same across different dpr screens. I have confirmed this with testing.

                      The main difference in behavior I would expect is for QCanvasPainter::drawImage(const QCanvasImage &image, float x, float y) to draw the image based on the logical dimensions (dimensions / image_dpr). So, if I've created a QCanvasImage from a QImage with dpr=2, these should be equivalent:
                      painter->drawImage(retinaImg, x, y);
                      painter->drawImage(retinaImg, x, y, retinaImg.width() / 2, retinaImg.height() / 2);

                      Or, put another way, if I had a @1px image and painted it with
                      painter->drawImage(img, x, y),
                      and then replaced it with a @2px or @3px image, I would expect it to take the same amount of logical space on the screen.

                      K Offline
                      K Offline
                      Kaj Gronholm
                      wrote last edited by
                      #19

                      @Dyami-Caliri Thanks for the explanation. I created now a ticket to check how we should handle this with the Canvas Painter https://qt-project.atlassian.net/browse/QTBUG-145183

                      1 Reply Last reply
                      0

                      • Login

                      • Login or register to search.
                      • First post
                        Last post
                      0
                      • Categories
                      • Recent
                      • Tags
                      • Popular
                      • Users
                      • Groups
                      • Search
                      • Get Qt Extensions
                      • Unsolved