Re: Review Request 128763: WindowThumbnail: Do GL calls in the correct thread

[Hrvoje Senjan]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128763/#review99643
---




src/declarativeimports/core/windowthumbnail.cpp (line 231)


This is added in Qt 5.6, but:
set (REQUIRED_QT_VERSION "5.3.0")
which is also wrong.


- Hrvoje Senjan


On Sept. 3, 2016, 10:33 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128763/
> ---
> 
> (Updated Sept. 3, 2016, 10:33 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> WindowThumbnail did some open GL operations, discarding old textures, in the 
> GUI thread. Whislt it's not going to cause a threading issue (as 
> updatePaintNode always ran when the main thread was blocked) we're not meant 
> to mix threads with openGL contexts.
> 
> It also seems to have a GL leak on nvidia, which was previously masked
> by the double delete fixed in https://git.reviewboard.kde.org/r/126131/diff/2/
> It seems only one worked, and in the applied version we went with the wrong 
> one.
> 
> This patch makes use of QQuickItem::releaseResources to delete the GL
> textures on window change and destructor; it's then removed from
> stopRedirecting so that start/stop redirecting handles xcb on the GUI thread 
> and updatePaintNode/discardPixmap is the GL stuff on the render thread. 
> 
> See http://doc.qt.io/qt-5/qquickitem.html#graphics-resource-handling
> 
> REVIEW:
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.h 
> 7276f95de16e71006618f3282d8eaf419a199d1d 
>   src/declarativeimports/core/windowthumbnail.cpp 
> d106994315099ab6e6f948c31a606d5309ae03e2 
> 
> Diff: https://git.reviewboard.kde.org/r/128763/diff/
> 
> 
> Testing
> ---
> 
> Using nvidia with proprietory drivers (which puts me 
> QSG_RENDER_LOOP=threaded) mouse over the panel a lot. VRAM didn't increase. 
> Previews still appear. 
> "Used Dedicated Memory:" in nvidia-settings remained roughly static, rather 
> than constantly increasing.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

Re: Review Request 128763: WindowThumbnail: Do GL calls in the correct thread

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128763/#review98834
---


Ship it!




Ship It!

- Martin Gräßlin


On Sept. 2, 2016, 6:44 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128763/
> ---
> 
> (Updated Sept. 2, 2016, 6:44 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> WindowThumbnail did some open GL operations, discarding old textures, in the 
> GUI thread. Whislt it's not going to cause a threading issue (as 
> updatePaintNode always ran when the main thread was blocked) we're not meant 
> to mix threads with openGL contexts.
> 
> It also seems to have a GL leak on nvidia, which was previously masked
> by the double delete fixed in https://git.reviewboard.kde.org/r/126131/diff/2/
> It seems only one worked, and in the applied version we went with the wrong 
> one.
> 
> This patch makes use of QQuickItem::releaseResources to delete the GL
> textures on window change and destructor; it's then removed from
> stopRedirecting so that start/stop redirecting handles xcb on the GUI thread 
> and updatePaintNode/discardPixmap is the GL stuff on the render thread. 
> 
> See http://doc.qt.io/qt-5/qquickitem.html#graphics-resource-handling
> 
> REVIEW:
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.h 
> 7276f95de16e71006618f3282d8eaf419a199d1d 
>   src/declarativeimports/core/windowthumbnail.cpp 
> d106994315099ab6e6f948c31a606d5309ae03e2 
> 
> Diff: https://git.reviewboard.kde.org/r/128763/diff/
> 
> 
> Testing
> ---
> 
> Using nvidia with proprietory drivers (which puts me 
> QSG_RENDER_LOOP=threaded) mouse over the panel a lot. VRAM didn't increase. 
> Previews still appear. 
> "Used Dedicated Memory:" in nvidia-settings remained roughly static, rather 
> than constantly increasing.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

Re: Review Request 128763: WindowThumbnail: Do GL calls in the correct thread

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128763/
---

(Updated Sept. 2, 2016, 4:44 p.m.)


Review request for KDE Frameworks and Plasma.


Changes
---

Updated with the comments addressed, also add a missing HAVE_XCB_COMPOSITING

The nvidia user who reported it tested and commented.
(I can't test my NVidia setup at the moment)

[18:24]  i tried yours patch, it works.
[18:24]  i even noticed that now there no those strange pause when 
tooltips are not eve showed.


Repository: plasma-framework


Description
---

WindowThumbnail did some open GL operations, discarding old textures, in the 
GUI thread. Whislt it's not going to cause a threading issue (as 
updatePaintNode always ran when the main thread was blocked) we're not meant to 
mix threads with openGL contexts.

It also seems to have a GL leak on nvidia, which was previously masked
by the double delete fixed in https://git.reviewboard.kde.org/r/126131/diff/2/
It seems only one worked, and in the applied version we went with the wrong one.

This patch makes use of QQuickItem::releaseResources to delete the GL
textures on window change and destructor; it's then removed from
stopRedirecting so that start/stop redirecting handles xcb on the GUI thread 
and updatePaintNode/discardPixmap is the GL stuff on the render thread. 

See http://doc.qt.io/qt-5/qquickitem.html#graphics-resource-handling

REVIEW:


Diffs (updated)
-

  src/declarativeimports/core/windowthumbnail.h 
7276f95de16e71006618f3282d8eaf419a199d1d 
  src/declarativeimports/core/windowthumbnail.cpp 
d106994315099ab6e6f948c31a606d5309ae03e2 

Diff: https://git.reviewboard.kde.org/r/128763/diff/


Testing
---

Using nvidia with proprietory drivers (which puts me QSG_RENDER_LOOP=threaded) 
mouse over the panel a lot. VRAM didn't increase. Previews still appear. 
"Used Dedicated Memory:" in nvidia-settings remained roughly static, rather 
than constantly increasing.


Thanks,

David Edmundson

Re: Review Request 128763: WindowThumbnail: Do GL calls in the correct thread

[David Edmundson]

> On Sept. 2, 2016, 8:11 a.m., Martin Gräßlin wrote:
> > src/declarativeimports/core/windowthumbnail.cpp, lines 482-493
> > 
> >
> > what about these commented lines?

I've replaced it with a call to releaseResources() so that it will clean up if 
we do ever get in this state. I think it's won't, but it'll just no-op in that 
case anyway)


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128763/#review98827
---


On Sept. 1, 2016, 10:50 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128763/
> ---
> 
> (Updated Sept. 1, 2016, 10:50 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> WindowThumbnail did some open GL operations, discarding old textures, in the 
> GUI thread. Whislt it's not going to cause a threading issue (as 
> updatePaintNode always ran when the main thread was blocked) we're not meant 
> to mix threads with openGL contexts.
> 
> It also seems to have a GL leak on nvidia, which was previously masked
> by the double delete fixed in https://git.reviewboard.kde.org/r/126131/diff/2/
> It seems only one worked, and in the applied version we went with the wrong 
> one.
> 
> This patch makes use of QQuickItem::releaseResources to delete the GL
> textures on window change and destructor; it's then removed from
> stopRedirecting so that start/stop redirecting handles xcb on the GUI thread 
> and updatePaintNode/discardPixmap is the GL stuff on the render thread. 
> 
> See http://doc.qt.io/qt-5/qquickitem.html#graphics-resource-handling
> 
> REVIEW:
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.h 
> 7276f95de16e71006618f3282d8eaf419a199d1d 
>   src/declarativeimports/core/windowthumbnail.cpp 
> d106994315099ab6e6f948c31a606d5309ae03e2 
> 
> Diff: https://git.reviewboard.kde.org/r/128763/diff/
> 
> 
> Testing
> ---
> 
> Using nvidia with proprietory drivers (which puts me 
> QSG_RENDER_LOOP=threaded) mouse over the panel a lot. VRAM didn't increase. 
> Previews still appear. 
> "Used Dedicated Memory:" in nvidia-settings remained roughly static, rather 
> than constantly increasing.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

Re: Review Request 128763: WindowThumbnail: Do GL calls in the correct thread

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128763/#review98827
---




src/declarativeimports/core/windowthumbnail.cpp (lines 481 - 492)


what about these commented lines?


- Martin Gräßlin


On Sept. 1, 2016, 12:50 p.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128763/
> ---
> 
> (Updated Sept. 1, 2016, 12:50 p.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> WindowThumbnail did some open GL operations, discarding old textures, in the 
> GUI thread. Whislt it's not going to cause a threading issue (as 
> updatePaintNode always ran when the main thread was blocked) we're not meant 
> to mix threads with openGL contexts.
> 
> It also seems to have a GL leak on nvidia, which was previously masked
> by the double delete fixed in https://git.reviewboard.kde.org/r/126131/diff/2/
> It seems only one worked, and in the applied version we went with the wrong 
> one.
> 
> This patch makes use of QQuickItem::releaseResources to delete the GL
> textures on window change and destructor; it's then removed from
> stopRedirecting so that start/stop redirecting handles xcb on the GUI thread 
> and updatePaintNode/discardPixmap is the GL stuff on the render thread. 
> 
> See http://doc.qt.io/qt-5/qquickitem.html#graphics-resource-handling
> 
> REVIEW:
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.h 
> 7276f95de16e71006618f3282d8eaf419a199d1d 
>   src/declarativeimports/core/windowthumbnail.cpp 
> d106994315099ab6e6f948c31a606d5309ae03e2 
> 
> Diff: https://git.reviewboard.kde.org/r/128763/diff/
> 
> 
> Testing
> ---
> 
> Using nvidia with proprietory drivers (which puts me 
> QSG_RENDER_LOOP=threaded) mouse over the panel a lot. VRAM didn't increase. 
> Previews still appear. 
> "Used Dedicated Memory:" in nvidia-settings remained roughly static, rather 
> than constantly increasing.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

Re: Review Request 128763: WindowThumbnail: Do GL calls in the correct thread

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128763/
---

(Updated Sept. 1, 2016, 10:50 a.m.)


Review request for KDE Frameworks and Plasma.


Changes
---

Don't pass WindowThumbnail as argument to runnable, but instead pass the 
relevant data.


Repository: plasma-framework


Description
---

WindowThumbnail did some open GL operations, discarding old textures, in the 
GUI thread. Whislt it's not going to cause a threading issue (as 
updatePaintNode always ran when the main thread was blocked) we're not meant to 
mix threads with openGL contexts.

It also seems to have a GL leak on nvidia, which was previously masked
by the double delete fixed in https://git.reviewboard.kde.org/r/126131/diff/2/
It seems only one worked, and in the applied version we went with the wrong one.

This patch makes use of QQuickItem::releaseResources to delete the GL
textures on window change and destructor; it's then removed from
stopRedirecting so that start/stop redirecting handles xcb on the GUI thread 
and updatePaintNode/discardPixmap is the GL stuff on the render thread. 

See http://doc.qt.io/qt-5/qquickitem.html#graphics-resource-handling

REVIEW:


Diffs (updated)
-

  src/declarativeimports/core/windowthumbnail.h 
7276f95de16e71006618f3282d8eaf419a199d1d 
  src/declarativeimports/core/windowthumbnail.cpp 
d106994315099ab6e6f948c31a606d5309ae03e2 

Diff: https://git.reviewboard.kde.org/r/128763/diff/


Testing
---

Using nvidia with proprietory drivers (which puts me QSG_RENDER_LOOP=threaded) 
mouse over the panel a lot. VRAM didn't increase. Previews still appear. 
"Used Dedicated Memory:" in nvidia-settings remained roughly static, rather 
than constantly increasing.


Thanks,

David Edmundson

Re: Review Request 128763: WindowThumbnail: Do GL calls in the correct thread

[David Edmundson]

> On Aug. 26, 2016, 11:16 a.m., Martin Gräßlin wrote:
> > Ship It!

Not merging yet as someone (loa) on IRC reports a crash with this - I'm quite 
sure I know what it'll be, the runnable trying to access WindowThumbnail after 
it's been deleted. I think I'll have to split all the vars that I marked should 
only be used from the render thread into a separate struct.


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128763/#review98684
---


On Aug. 26, 2016, 1:04 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128763/
> ---
> 
> (Updated Aug. 26, 2016, 1:04 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> WindowThumbnail did some open GL operations, discarding old textures, in the 
> GUI thread. Whislt it's not going to cause a threading issue (as 
> updatePaintNode always ran when the main thread was blocked) we're not meant 
> to mix threads with openGL contexts.
> 
> It also seems to have a GL leak on nvidia, which was previously masked
> by the double delete fixed in https://git.reviewboard.kde.org/r/126131/diff/2/
> It seems only one worked, and in the applied version we went with the wrong 
> one.
> 
> This patch makes use of QQuickItem::releaseResources to delete the GL
> textures on window change and destructor; it's then removed from
> stopRedirecting so that start/stop redirecting handles xcb on the GUI thread 
> and updatePaintNode/discardPixmap is the GL stuff on the render thread. 
> 
> See http://doc.qt.io/qt-5/qquickitem.html#graphics-resource-handling
> 
> REVIEW:
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.h 
> 7276f95de16e71006618f3282d8eaf419a199d1d 
>   src/declarativeimports/core/windowthumbnail.cpp 
> d106994315099ab6e6f948c31a606d5309ae03e2 
> 
> Diff: https://git.reviewboard.kde.org/r/128763/diff/
> 
> 
> Testing
> ---
> 
> Using nvidia with proprietory drivers (which puts me 
> QSG_RENDER_LOOP=threaded) mouse over the panel a lot. VRAM didn't increase. 
> Previews still appear. 
> "Used Dedicated Memory:" in nvidia-settings remained roughly static, rather 
> than constantly increasing.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

Re: Review Request 128763: WindowThumbnail: Do GL calls in the correct thread

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128763/#review98684
---


Ship it!




Ship It!

- Martin Gräßlin


On Aug. 26, 2016, 3:04 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128763/
> ---
> 
> (Updated Aug. 26, 2016, 3:04 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> WindowThumbnail did some open GL operations, discarding old textures, in the 
> GUI thread. Whislt it's not going to cause a threading issue (as 
> updatePaintNode always ran when the main thread was blocked) we're not meant 
> to mix threads with openGL contexts.
> 
> It also seems to have a GL leak on nvidia, which was previously masked
> by the double delete fixed in https://git.reviewboard.kde.org/r/126131/diff/2/
> It seems only one worked, and in the applied version we went with the wrong 
> one.
> 
> This patch makes use of QQuickItem::releaseResources to delete the GL
> textures on window change and destructor; it's then removed from
> stopRedirecting so that start/stop redirecting handles xcb on the GUI thread 
> and updatePaintNode/discardPixmap is the GL stuff on the render thread. 
> 
> See http://doc.qt.io/qt-5/qquickitem.html#graphics-resource-handling
> 
> REVIEW:
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.h 
> 7276f95de16e71006618f3282d8eaf419a199d1d 
>   src/declarativeimports/core/windowthumbnail.cpp 
> d106994315099ab6e6f948c31a606d5309ae03e2 
> 
> Diff: https://git.reviewboard.kde.org/r/128763/diff/
> 
> 
> Testing
> ---
> 
> Using nvidia with proprietory drivers (which puts me 
> QSG_RENDER_LOOP=threaded) mouse over the panel a lot. VRAM didn't increase. 
> Previews still appear. 
> "Used Dedicated Memory:" in nvidia-settings remained roughly static, rather 
> than constantly increasing.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

Re: Review Request 128763: WindowThumbnail: Do GL calls in the correct thread

[Martin Gräßlin]

> On Aug. 26, 2016, 9:49 a.m., Martin Gräßlin wrote:
> > src/declarativeimports/core/windowthumbnail.cpp, lines 682-686
> > 
> >
> > we probably need to do the same for EGL, don't we?
> 
> David Edmundson wrote:
> GLX and ELG are the same.
> I was dropping the xcb_free_pixmap from here, as that is also in 
> stopRedirecting.

sorry for the noise


- Martin


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128763/#review98673
---


On Aug. 26, 2016, 3:04 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128763/
> ---
> 
> (Updated Aug. 26, 2016, 3:04 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> WindowThumbnail did some open GL operations, discarding old textures, in the 
> GUI thread. Whislt it's not going to cause a threading issue (as 
> updatePaintNode always ran when the main thread was blocked) we're not meant 
> to mix threads with openGL contexts.
> 
> It also seems to have a GL leak on nvidia, which was previously masked
> by the double delete fixed in https://git.reviewboard.kde.org/r/126131/diff/2/
> It seems only one worked, and in the applied version we went with the wrong 
> one.
> 
> This patch makes use of QQuickItem::releaseResources to delete the GL
> textures on window change and destructor; it's then removed from
> stopRedirecting so that start/stop redirecting handles xcb on the GUI thread 
> and updatePaintNode/discardPixmap is the GL stuff on the render thread. 
> 
> See http://doc.qt.io/qt-5/qquickitem.html#graphics-resource-handling
> 
> REVIEW:
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.h 
> 7276f95de16e71006618f3282d8eaf419a199d1d 
>   src/declarativeimports/core/windowthumbnail.cpp 
> d106994315099ab6e6f948c31a606d5309ae03e2 
> 
> Diff: https://git.reviewboard.kde.org/r/128763/diff/
> 
> 
> Testing
> ---
> 
> Using nvidia with proprietory drivers (which puts me 
> QSG_RENDER_LOOP=threaded) mouse over the panel a lot. VRAM didn't increase. 
> Previews still appear. 
> "Used Dedicated Memory:" in nvidia-settings remained roughly static, rather 
> than constantly increasing.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

Re: Review Request 128763: WindowThumbnail: Do GL calls in the correct thread

[David Edmundson]

> On Aug. 26, 2016, 7:49 a.m., Martin Gräßlin wrote:
> > src/declarativeimports/core/windowthumbnail.cpp, lines 682-686
> > 
> >
> > we probably need to do the same for EGL, don't we?

GLX and ELG are the same.
I was dropping the xcb_free_pixmap from here, as that is also in 
stopRedirecting.


- David


---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128763/#review98673
---


On Aug. 26, 2016, 1:04 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128763/
> ---
> 
> (Updated Aug. 26, 2016, 1:04 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> WindowThumbnail did some open GL operations, discarding old textures, in the 
> GUI thread. Whislt it's not going to cause a threading issue (as 
> updatePaintNode always ran when the main thread was blocked) we're not meant 
> to mix threads with openGL contexts.
> 
> It also seems to have a GL leak on nvidia, which was previously masked
> by the double delete fixed in https://git.reviewboard.kde.org/r/126131/diff/2/
> It seems only one worked, and in the applied version we went with the wrong 
> one.
> 
> This patch makes use of QQuickItem::releaseResources to delete the GL
> textures on window change and destructor; it's then removed from
> stopRedirecting so that start/stop redirecting handles xcb on the GUI thread 
> and updatePaintNode/discardPixmap is the GL stuff on the render thread. 
> 
> See http://doc.qt.io/qt-5/qquickitem.html#graphics-resource-handling
> 
> REVIEW:
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.h 
> 7276f95de16e71006618f3282d8eaf419a199d1d 
>   src/declarativeimports/core/windowthumbnail.cpp 
> d106994315099ab6e6f948c31a606d5309ae03e2 
> 
> Diff: https://git.reviewboard.kde.org/r/128763/diff/
> 
> 
> Testing
> ---
> 
> Using nvidia with proprietory drivers (which puts me 
> QSG_RENDER_LOOP=threaded) mouse over the panel a lot. VRAM didn't increase. 
> Previews still appear. 
> "Used Dedicated Memory:" in nvidia-settings remained roughly static, rather 
> than constantly increasing.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

Re: Review Request 128763: WindowThumbnail: Do GL calls in the correct thread

[Martin Gräßlin]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128763/#review98673
---




src/declarativeimports/core/windowthumbnail.cpp (lines 680 - 684)


we probably need to do the same for EGL, don't we?


- Martin Gräßlin


On Aug. 26, 2016, 3:04 a.m., David Edmundson wrote:
> 
> ---
> This is an automatically generated e-mail. To reply, visit:
> https://git.reviewboard.kde.org/r/128763/
> ---
> 
> (Updated Aug. 26, 2016, 3:04 a.m.)
> 
> 
> Review request for KDE Frameworks and Plasma.
> 
> 
> Repository: plasma-framework
> 
> 
> Description
> ---
> 
> WindowThumbnail did some open GL operations, discarding old textures, in the 
> GUI thread. Whislt it's not going to cause a threading issue (as 
> updatePaintNode always ran when the main thread was blocked) we're not meant 
> to mix threads with openGL contexts.
> 
> It also seems to have a GL leak on nvidia, which was previously masked
> by the double delete fixed in https://git.reviewboard.kde.org/r/126131/diff/2/
> It seems only one worked, and in the applied version we went with the wrong 
> one.
> 
> This patch makes use of QQuickItem::releaseResources to delete the GL
> textures on window change and destructor; it's then removed from
> stopRedirecting so that start/stop redirecting handles xcb on the GUI thread 
> and updatePaintNode/discardPixmap is the GL stuff on the render thread. 
> 
> See http://doc.qt.io/qt-5/qquickitem.html#graphics-resource-handling
> 
> REVIEW:
> 
> 
> Diffs
> -
> 
>   src/declarativeimports/core/windowthumbnail.h 
> 7276f95de16e71006618f3282d8eaf419a199d1d 
>   src/declarativeimports/core/windowthumbnail.cpp 
> d106994315099ab6e6f948c31a606d5309ae03e2 
> 
> Diff: https://git.reviewboard.kde.org/r/128763/diff/
> 
> 
> Testing
> ---
> 
> Using nvidia with proprietory drivers (which puts me 
> QSG_RENDER_LOOP=threaded) mouse over the panel a lot. VRAM didn't increase. 
> Previews still appear. 
> "Used Dedicated Memory:" in nvidia-settings remained roughly static, rather 
> than constantly increasing.
> 
> 
> Thanks,
> 
> David Edmundson
> 
>

Review Request 128763: WindowThumbnail: Do GL calls in the correct thread

[David Edmundson]

---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/128763/
---

Review request for KDE Frameworks and Plasma.


Repository: plasma-framework


Description
---

WindowThumbnail did some open GL operations, discarding old textures, in the 
GUI thread. Whislt it's not going to cause a threading issue (as 
updatePaintNode always ran when the main thread was blocked) we're not meant to 
mix threads with openGL contexts.

It also seems to have a GL leak on nvidia, which was previously masked
by the double delete fixed in https://git.reviewboard.kde.org/r/126131/diff/2/
It seems only one worked, and in the applied version we went with the wrong one.

This patch makes use of QQuickItem::releaseResources to delete the GL
textures on window change and destructor; it's then removed from
stopRedirecting so that start/stop redirecting handles xcb on the GUI thread 
and updatePaintNode/discardPixmap is the GL stuff on the render thread. 

See http://doc.qt.io/qt-5/qquickitem.html#graphics-resource-handling

REVIEW:


Diffs
-

  src/declarativeimports/core/windowthumbnail.h 
7276f95de16e71006618f3282d8eaf419a199d1d 
  src/declarativeimports/core/windowthumbnail.cpp 
d106994315099ab6e6f948c31a606d5309ae03e2 

Diff: https://git.reviewboard.kde.org/r/128763/diff/


Testing
---

Using nvidia with proprietory drivers (which puts me QSG_RENDER_LOOP=threaded) 
mouse over the panel a lot. VRAM didn't increase. Previews still appear. 
"Used Dedicated Memory:" in nvidia-settings remained roughly static, rather 
than constantly increasing.


Thanks,

David Edmundson