Merge lp:~albaguirre/qtubuntu/use-mir-rs-api into lp:qtubuntu
| Status: | Needs review |
|---|---|
| Proposed branch: | lp:~albaguirre/qtubuntu/use-mir-rs-api |
| Merge into: | lp:qtubuntu |
| Diff against target: |
592 lines (+154/-188) 7 files modified
debian/control (+3/-4) src/ubuntumirclient/qmirclientcursor.cpp (+68/-25) src/ubuntumirclient/qmirclientinput.cpp (+0/-4) src/ubuntumirclient/qmirclientintegration.cpp (+1/-2) src/ubuntumirclient/qmirclientintegration.h (+1/-2) src/ubuntumirclient/qmirclientwindow.cpp (+80/-150) src/ubuntumirclient/ubuntumirclient.pro (+1/-1) |
| To merge this branch: | bzr merge lp:~albaguirre/qtubuntu/use-mir-rs-api |
| Related bugs: |
| Reviewer | Review Type | Date Requested | Status |
|---|---|---|---|
| Unity8 CI Bot | continuous-integration | Needs Fixing on 2017-05-27 | |
| Gerry Boland | Needs Information on 2017-05-22 | ||
| Alan Griffiths | 2017-03-31 | Needs Information on 2017-05-19 | |
|
Review via email:
|
|||
Commit Message
Avoid use of deprecated mir EGL related apis.
With the new mesa update, the EGLNativeDispla
Ignore deprecation warnings on use of MirRenderSurface - its "deprecated" because it'll be renamed in mir 1.0.
| Alan Griffiths (alan-griffiths) wrote : | # |
This would be nicely simplified by lp:~alan-griffiths/mir/deprecation-macros plus -DMIR_DEPRECATE
| Alan Griffiths (alan-griffiths) wrote : | # |
Looks mostly sensible, but I need to get more familiar with qtubuntu to be sure.
Can we aim to land lp:~alan-griffiths/mir/deprecation-macros and use -DMIR_DEPRECATE
| Gerry Boland (gerboland) wrote : | # |
I have a question about how pixel formats work with the newer Mir API. I see you've removed code where Qt could set a desired pixel format on the mir surface - is this feature impossible to replicate?
This was done because sometimes the EGL config chosen may have an alpha buffer enabled, even if Qt doesn't need it. We used the mir pixel format to inform the Mir compositor that blending is not required in that case - a nice optimisation.
| Gerry Boland (gerboland) wrote : | # |
I agree with Alan that using his deprecation bits would be nice, but I'd be ok with landing this in the current state if we need this to land first.
| Alan Griffiths (alan-griffiths) wrote : | # |
> I have a question about how pixel formats work with the newer Mir API. I see
> you've removed code where Qt could set a desired pixel format on the mir
> surface - is this feature impossible to replicate?
Mir currently has "Window" and "RenderSurface" but not "surface". I assume you mean "RenderSurface"?
> This was done because sometimes the EGL config chosen may have an alpha buffer
> enabled, even if Qt doesn't need it. We used the mir pixel format to inform
> the Mir compositor that blending is not required in that case - a nice
> optimisation.
I don't see that in the RS code, but I'm still learning my way around it.
| Gerry Boland (gerboland) wrote : | # |
And the obvious question: can we jump to using non-deprecated APIs in one go?
| Alan Griffiths (alan-griffiths) wrote : | # |
> And the obvious question: can we jump to using non-deprecated APIs in one go?
It depends.
The reason for the current situation being that we can't introduce the intended "surface" APIs until we delete the current ones.
The RS APIs are a temporary workaround to enable the "surface" functionality without a name clash.
If we decide not to rename MirRenderSurface => MirSurface in 1.0 we can just remove the deprecation of render surface.
| Gerry Boland (gerboland) wrote : | # |
+ // Assume that the buffer size matches the surface size at creation time
I'd rather not make that assumption. Does the new API loose this functionality?
| Gerry Boland (gerboland) wrote : | # |
+bool UbuntuSurface:
+{
+ return mNeedsRepaint;
This can totally go away AFAICS, since this changes the buffer "ownership" drastically. Before when we got a surface resize event, we had to keep swapping buffers until we got one sized at the new size - so we had to keep force repainting until that happened. Now since Qt owns the buffer, it can resize immediately.
Removing all the needsRepaint stuff also makes resizing smoother IMO in my tests here.
| Gerry Boland (gerboland) wrote : | # |
overall looks ok, I just
- miss the pixel format optimisation
- would ultimately like to remove any deprecated api use (but not necessarily in this MP)
| Alberto Aguirre (albaguirre) wrote : | # |
> I have a question about how pixel formats work with the newer Mir API. I see
> you've removed code where Qt could set a desired pixel format on the mir
> surface - is this feature impossible to replicate?
>
> This was done because sometimes the EGL config chosen may have an alpha buffer
> enabled, even if Qt doesn't need it. We used the mir pixel format to inform
> the Mir compositor that blending is not required in that case - a nice
> optimisation.
The pixel format for EGL rendering is now set through the chosen EGLConfig. The new mir mesa path will actually obey the pixel format selected.
If you want to use mir_pixel_format enums, you can specify a EGL_NATIVE_
| Alberto Aguirre (albaguirre) wrote : | # |
> + // Assume that the buffer size matches the surface size at creation time
> I'd rather not make that assumption. Does the new API loose this
> functionality?
If the size chosen by the server is changed, it now gets delivered as a resize event as long as the event handler was registered through the window spec. This means that the same resizing logic is applied.
I tested this slightly by using the fullscreen window manager option in mir's demo server.
| Unity8 CI Bot (unity8-ci-bot) wrote : | # |
FAILED: Continuous integration, rev:396
https:/
Executed test runs:
FAILURE: https:/
SUCCESS: https:/
FAILURE: https:/
SUCCESS: https:/
deb: https:/
FAILURE: https:/
SUCCESS: https:/
deb: https:/
FAILURE: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild:
https:/
| Alberto Aguirre (albaguirre) wrote : | # |
> overall looks ok, I just
> - miss the pixel format optimisation
I'll look into that, I should just be able to use EGL_NATIVE_
| Alberto Aguirre (albaguirre) wrote : | # |
> Looks mostly sensible, but I need to get more familiar with qtubuntu to be
> sure.
>
> Can we aim to land lp:~alan-griffiths/mir/deprecation-macros and use
> -DMIR_DEPRECATE
Shouldn't be an issue on a local machine, but qtubuntu's CI would be.
- 397. By Alberto Aguirre on 2017-05-27
-
Cleanup #pragmas and unneeded repaints when resizing.
| Unity8 CI Bot (unity8-ci-bot) wrote : | # |
FAILED: Continuous integration, rev:397
https:/
Executed test runs:
FAILURE: https:/
SUCCESS: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
FAILURE: https:/
Click here to trigger a rebuild:
https:/
Unmerged revisions
- 397. By Alberto Aguirre on 2017-05-27
-
Cleanup #pragmas and unneeded repaints when resizing.
- 396. By Alberto Aguirre on 2017-04-06
-
Avoid using mir_window_
get_parameters, it will be deprecated - 395. By Alberto Aguirre on 2017-04-05
-
Remove mir_event_type_key and mir_event_
type_motion as they are deprecated. - 394. By Alberto Aguirre on 2017-04-05
-
Use MirRenderSurface for pixmap cursors.
Creating buffer streams directly will be deprecated in mir in the near future, instead use render surfaces.
- 393. By Alberto Aguirre on 2017-04-05
-
Update resizing now that client can drive the buffer size through mir_render_
surface_ set_size. - 392. By Alberto Aguirre on 2017-03-31
-
Avoid use of deprecated mir EGL related apis.
With the new mesa update, the EGLNativeDispla
yType is MirConnection and the EGLNativeWindowType is a MirRenderSurface.
Ignore deprecation warnings on use of MirRenderSurface - its "deprecated" because it'll be renamed in mir 1.0.

FAILED: Continuous integration, rev:392 /unity8- jenkins. ubuntu. com/job/ lp-qtubuntu- ci/222/ /unity8- jenkins. ubuntu. com/job/ build/4820/ console /unity8- jenkins. ubuntu. com/job/ build-0- fetch/4848 /unity8- jenkins. ubuntu. com/job/ build-2- binpkg/ arch=amd64, release= xenial+ overlay/ 4659/console /unity8- jenkins. ubuntu. com/job/ build-2- binpkg/ arch=amd64, release= zesty/4659 /unity8- jenkins. ubuntu. com/job/ build-2- binpkg/ arch=amd64, release= zesty/4659/ artifact/ output/ *zip*/output. zip /unity8- jenkins. ubuntu. com/job/ build-2- binpkg/ arch=armhf, release= xenial+ overlay/ 4659/console /unity8- jenkins. ubuntu. com/job/ build-2- binpkg/ arch=armhf, release= zesty/4659 /unity8- jenkins. ubuntu. com/job/ build-2- binpkg/ arch=armhf, release= zesty/4659/ artifact/ output/ *zip*/output. zip /unity8- jenkins. ubuntu. com/job/ build-2- binpkg/ arch=i386, release= xenial+ overlay/ 4659/console /unity8- jenkins. ubuntu. com/job/ build-2- binpkg/ arch=i386, release= zesty/4659 /unity8- jenkins. ubuntu. com/job/ build-2- binpkg/ arch=i386, release= zesty/4659/ artifact/ output/ *zip*/output. zip
https:/
Executed test runs:
FAILURE: https:/
SUCCESS: https:/
FAILURE: https:/
SUCCESS: https:/
deb: https:/
FAILURE: https:/
SUCCESS: https:/
deb: https:/
FAILURE: https:/
SUCCESS: https:/
deb: https:/
Click here to trigger a rebuild: /unity8- jenkins. ubuntu. com/job/ lp-qtubuntu- ci/222/ rebuild
https:/