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 <[email protected]>
发送时间: 2022年6月2日 10:53
收件人: 弓 长 <[email protected]>
抄送: Qt邮件列表 <[email protected]>
主题: Re: [Development] Do we have some plans about the damage tracking of
QtQuick's scene graphics?
On 2022 Jun 2, at 11:47, 弓 长 <[email protected]<mailto:[email protected]>> 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://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugreports.qt.io%2Fbrowse%2FQTBUG-74928&data=05%7C01%7C%7Ca1fd381f297e4406e78b08da448630e9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637897640382852921%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=hGFcgkGz8qD9Qdh2Azrvy7%2FMqLYaiapRqvHkmbssCq0%3D&reserved=0>
https://bugreports.qt.io/browse/QTBUG-101976<https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugreports.qt.io%2Fbrowse%2FQTBUG-101976&data=05%7C01%7C%7Ca1fd381f297e4406e78b08da448630e9%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C637897640383009130%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&sdata=opQ5WkQDlky2AL1aVxhj4iLsn4%2BIGn%2FPP4%2BZanEdBjo%3D&reserved=0>
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?
_______________________________________________
Development mailing list
[email protected]
https://lists.qt-project.org/listinfo/development
