[Development] Do we have some plans about the damage tracking of QtQuick's scene graphics?

Shawn Rutledge Shawn.Rutledge at qt.io
Thu Jun 2 12:53:54 CEST 2022



On 2022 Jun 2, at 11:47, 弓 长 <zccrs at live.com<mailto:zccrs at live.com>> wrote:

I am doing a Wayland compositor use the QtQuick with wlroots, when the client's window has update its buffer, I had to update the whole screen, usually the dirty area would be small, but this is only possible in QtQuick.

https://bugreports.qt.io/browse/QTBUG-74928
https://bugreports.qt.io/browse/QTBUG-101976

Others have the same problem, so I wanted to ask how we're going to treat this, can upstream accept my patch if I try to fix it?

In Qt Quick the strategy has been to build a complete scene graph for all the contents of all visible items that you declared, and during rending, the SG nodes that are not visible get culled; so we didn’t have anything like QPaintEvent::region() to tell you what part of an Item is “dirty”.  But the new thing is two new item flags: ItemObservesViewport, and ItemIsViewport.  See https://doc.qt.io/qt-6/qquickitem.html#clipRect : if an item observes the viewport, https://doc.qt.io/qt-6/qquickitem.html#updatePaintNode can be implemented to use clipRect() to find out what is dirty, update SG nodes within that area, and omit SG nodes that fall outside.  This is the foundation for an optimization of the Text item (and TextEdit etc): you can load a large document, and if the Text is in a window or Flickable that is much too small to show it all, we can avoid rendering most of the text that is currently outside the viewport; in that case, updatePaintNode is called more often during scrolling, and updates the SG nodes according to the updated clip rect, according to the part that is now visible in the viewport. (Implementation in https://codereview.qt-project.org/c/qt/qtdeclarative/+/282970 and https://codereview.qt-project.org/c/qt/qtdeclarative/+/366954 and a few more)

So maybe that will help you in this case too, somehow.  But clients give you whole-window textures anyway, when they update their content, so what can you avoid updating?  On a big panning virtual desktop, much larger than the screen, you could omit windows that are completely outside; that would be just like the large-text case.  Or if it’s the compositor’s responsibility to tell clients what area is damaged, so that they can avoid repainting the whole window… is that the point here?

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20220602/a6666158/attachment-0001.htm>


More information about the Development mailing list