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

Zhang JiDe zccrs at live.com
Fri Jun 3 10:50:48 CEST 2022

For a example:

WaylandOutput {
    WaylandClientSurface {

    Button {

In the WaylandOutput, its have two item. The first item is a WaylandClientSurface, its will report the damaged area of the surface to wayland compositor from the wayland client when the surface is updated, but we unable use the damaged area to the WaylandClientSurface. The second item is a Button of QtQuick.Controls item, when hover to it, its will request to update scene graphics, this is a whole update, we can't get the damage area of  a Button. This results in that we have to submit the full buffer for the WaylandOutput to the DRM device no matter which region is damaged, and, as Giuseppe D'Angelo said, if this WaylandOutput is a VNC screen, then we will have to transmit a lot of useless data by network.

Another example is that when a QtQuick program runs as a Wayland client, each QQuickWindow will not report its own damaged area to Wayland Compositor, even if we only update a 10x10 area in a 1000x1000 window, Wayland Compositor must recomposit the whole window buffer.

发件人: Shawn Rutledge <Shawn.Rutledge at qt.io>
发送时间: 2022年6月2日 10:53
收件人: 弓 长 <zccrs at live.com>
抄送: Qt邮件列表 <development at qt-project.org>
主题: Re: [Development] Do we have some plans about the damage tracking of QtQuick's scene graphics?

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.


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<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.qt.io%2Fqt-6%2Fqquickitem.html%23clipRect&data=05%7C01%7C%7Ca1fd381f297e4406e78b08da448630e9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637897640383009130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=lruc6B1PL5B5yuz%2BGfdln3zGJu98OdXwwMw03bXAPiQ%3D&reserved=0> : if an item observes the viewport, https://doc.qt.io/qt-6/qquickitem.html#updatePaintNode<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fdoc.qt.io%2Fqt-6%2Fqquickitem.html%23updatePaintNode&data=05%7C01%7C%7Ca1fd381f297e4406e78b08da448630e9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637897640383009130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=aJ5JHk5FpgBBNoRmiLP7fuxWv5oWX%2FqZyNyD7NUenuY%3D&reserved=0> 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<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcodereview.qt-project.org%2Fc%2Fqt%2Fqtdeclarative%2F%2B%2F282970&data=05%7C01%7C%7Ca1fd381f297e4406e78b08da448630e9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637897640383009130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=PlbL8a3hE6ZXDLDS7R9GDxiNX5M6KMmPbVFXXAK1Sds%3D&reserved=0> and https://codereview.qt-project.org/c/qt/qtdeclarative/+/366954<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fcodereview.qt-project.org%2Fc%2Fqt%2Fqtdeclarative%2F%2B%2F366954&data=05%7C01%7C%7Ca1fd381f297e4406e78b08da448630e9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637897640383009130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=XCH%2BYE%2FRB9XoBw5gxmLrHGvu5ojdm6sUShJac7XBboo%3D&reserved=0> 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/20220603/140ef103/attachment-0001.htm>

More information about the Development mailing list