Qt Forum

    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Groups
    • Search
    • Unsolved

    Update: Forum Guidelines & Code of Conduct


    Qt World Summit: Early-Bird Tickets

    Solved Different behaviour of backingStore between macos and linux.

    General and Desktop
    qtbase qwidget backingstore macos
    3
    5
    1393
    Loading More Posts
    • 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.
    • P
      pdv_ last edited by

      I have a question on the behaviour of the Qt-backingStore on macos.
      When issuing viewport()->update() without specifying a rectangle an update of the rect of the widget is issued. It looks like in that case Qt expects a full redraw of the widget. If the widget only partially redraws its content, then the rest is painted black (Qt-5.9.2) or becomes transparent (Qt-5.10). If true it means that for a partial redraw one must always specify the correct rect in the update(rect) call. However this seems not to be a problem on linux.
      Which of the 2 behaviours is the intended one?

      This behaviour was not present in Qt-5.4.1 and can be traced back to the introduction of QCocoaBackingStore::beginPaint() where the background is indeed filled with the QColor::transparent.
      The commit-message for this change reads: "Clear backingstore for windows with alpha channel. Fixes painting artifacts in translucent windows.”

      VRonin 1 Reply Last reply Reply Quote 0
      • VRonin
        VRonin @pdv_ last edited by VRonin

        @pdv_ said in Different behaviour of backingStore between macos and linux.:

        Which of the 2 behaviours is the intended one?

        This is my opinion, not the absolute truth

        I'd say "for a partial redraw one must always specify the correct rect in the update(rect) call" is the intended behaviour, and the fact that it works in linux is just a result of undefined behaviour

        "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
        ~Napoleon Bonaparte

        On a crusade to banish setIndexWidget() from the holy land of Qt

        1 Reply Last reply Reply Quote 1
        • VRonin
          VRonin last edited by

          Being a little more scientific, from http://doc.qt.io/qt-5/qwidget.html#update

          Qt normally erases the widget's area before the paintEvent() call.

          "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
          ~Napoleon Bonaparte

          On a crusade to banish setIndexWidget() from the holy land of Qt

          J 1 Reply Last reply Reply Quote 1
          • J
            JMarc @VRonin last edited by

            @VRonin actually in the case we are interested in Qt::WA_OpaquePaintEvent is set. The docs says that Qt can take this opportunity to leave the backing store alone, but it does not on OSX (we did not have the opportunity to test windows yet).

            It looks like the changed mentioned by pdv was done for the benefit of translucent windows, but it should not trigger for plain old opaque windows, IMO.

            PS: the context is LyX, for which we have built our own hand-made editor.

            1 Reply Last reply Reply Quote 0
            • VRonin
              VRonin last edited by

              1st of all, thanks for your effort, I use LyX myself.

              The doc says:

              this indicates that the widget will paint over its entire area with opaque colors. The widget's area will initially be uninitialized

              set the widget's Qt::WA_OpaquePaintEvent, avoiding any unnecessary overhead associated with repainting the widget's background

              Meaning it is saying it won't bother painting a background but it's not committing to leaving the old painted background in place so I still think you are relying on undefined behaviour.

              On the other hand, I think this also impacts the performance of widgets with Qt::WA_OpaquePaintEvent on macOS so it is probably worth highlighting it with a bug report and/or an email on the mailing list

              "La mort n'est rien, mais vivre vaincu et sans gloire, c'est mourir tous les jours"
              ~Napoleon Bonaparte

              On a crusade to banish setIndexWidget() from the holy land of Qt

              1 Reply Last reply Reply Quote 1
              • First post
                Last post