| graesslin |
| Plasma |
For software QtQuick rendering we want to create a pixmap buffer and
render our contents in there.
m_rendercontrol->grab does this, but also covers the GL side in pretty
much the same way that we were currently doing.
Some calls are redundant in software mode, but they don't do any harm,
and I didn't want to pollute the code.
In doing so I found a bug in Qt, that's submitted upstream, and also worked round.
Tested with forced software mode, could see an Aurorae decorations
Tested without (so normal code), could see an Aurorae
Whether we then end up using GL, painter or xrender rendering is irrelevant
(but I tested two of them anyway)
| Automatic diff as part of commit; lint not applicable. |
| Automatic diff as part of commit; unit tests not applicable. |
| plugins/kdecorations/aurorae/src/aurorae.cpp | ||
|---|---|---|
| 347 | #if QT_VERSION < QT_VERSION_CHECK(5,10,0)? | |
| plugins/kdecorations/aurorae/src/aurorae.cpp | ||
|---|---|---|
| 357–358 | stupid question: but why is this code working? I would assume that making the context current will fail here and then we return? And even if the creation of the FBO should fail and then also return? | |
| plugins/kdecorations/aurorae/src/aurorae.cpp | ||
|---|---|---|
| 347 | Yeah, makes sense, it got +2'd quicker than I expected. | |
| 357–358 | Changing the rendering doesn't block making calls to any of the openGL calls in QtBase. So: why m_view->setRenderTarget and m_view->resetOpenGLState still work are the more interesting questions With this code: | |
| plugins/kdecorations/aurorae/src/aurorae.cpp | ||
|---|---|---|
| 357–358 | then I would suggest to guard it to only do it in the OpenGL case. Especially on Wayland without OpenGL support this could be very nasty. | |
Avoid all GL in software mode.
Had a bit of a reshuffle to create the view first, so we can use the graphicsAPI from that
rather than the static methods.