Doing std::move when returning/assigning a local or temporary object is
preventing the compiler from performing copy elision.
Differential Revision: https://phabricator.services.mozilla.com/D5019
--HG--
extra : moz-landing-system : lando
Doing std::move when returning/assigning a local or temporary object is
preventing the compiler from performing copy elision.
In the case of UniquePtr, it's easier to `return MakeUnique<T>(...)` instead of
the move verbose `UniquePtr<T> r(new T(...)); return r;`
Differential Revision: https://phabricator.services.mozilla.com/D5019
--HG--
extra : moz-landing-system : lando
We need to use the same visual for X drawable and glxContext,
otherwise we get BadMatch when we try to make the glxContext current.
The correct glx visual is already configured at nsWindow::Create()
so just use it if it also matches the frame buffer config.
MozReview-Commit-ID: 78IIfiwOnsf
--HG--
extra : rebase_source : 5ddfc0f94abafc7a1441eea095e546568bc31596
The DirectMapTextureSource could let the compositor to read the buffer directly.
That could get rid of some memory copy operations during texture uploading.
MozReview-Commit-ID: CHhoR96P7VG
--HG--
extra : rebase_source : 65c167644096a1b72fe5dfbb55837842f41377bb
The DirectMapTextureSource could let the compositor to read the buffer directly.
That could get rid of some memory copy operations during texture uploading.
MozReview-Commit-ID: CHhoR96P7VG
--HG--
extra : rebase_source : 65c167644096a1b72fe5dfbb55837842f41377bb
The DirectMapTextureSource could let the compositor to read the buffer directly.
That could get rid of some memory copy operations during texture uploading.
MozReview-Commit-ID: CHhoR96P7VG
--HG--
extra : rebase_source : fbca3bd3b8af29939626e697909cc67e9a5b34cc
After Bug 1451183 is landed, sEGLLibrary is undefined and we should use
gl::GLLibraryEGL::Get() instead of sEGLLibrary directly.
MozReview-Commit-ID: DNEkPIEqDpK
--HG--
extra : rebase_source : b07e04ce8a9fe50d72fd857e41c1448fa917d2a9
This was done automatically replacing:
s/mozilla::Move/std::move/
s/ Move(/ std::move(/
s/(Move(/(std::move(/
Removing the 'using mozilla::Move;' lines.
And then with a few manual fixups, see the bug for the split series..
MozReview-Commit-ID: Jxze3adipUh
GLContextProviderWayland provides both GLX and EGL GL backends on Wayland enabled builds
according to an active Gtk+ backend (X11/Wayland).
MozReview-Commit-ID: TTBDwWMBAP
--HG--
extra : rebase_source : 26e0455ae3775bdcea83deffbb8ad43aacdb3e42
In order to have useful Wayland builds we need ability to switch
between GL backends run-time - to use EGL backend for Wayland and GLX backend for X11.
GL_PROVIDER_GLX is used exclusively for GLX GL backend, so let's replace GL_PROVIDER_GLX
build-time check by more general MOZ_X11 check which determines X11 dependent code
and it's valid for both X11 and Wayland builds.
MozReview-Commit-ID: HYobrHveoaP
--HG--
extra : rebase_source : 2d359355ee747f5898d27d8a28d66114f4135f5b
Wayland on desktop does not support/implement PBuffer. As a workaround
we create a dummy wl_egl_window instead and render to it.
As a side effect we need to store and release this wl_egl_window along
the associated EGLSurface on Wayland.
MozReview-Commit-ID: 1NlzZsOzXz9
--HG--
extra : rebase_source : 13f776ad0a9079f7155ba523b61f93441bf7fd5f
Patch author is Takuro Ashie <ashie@clear-code.com>
Use wl_display to get EGLDisplay on Wayland because some drivers doesn't support EGL_DEFAULT_DISPLAY.
For example Intel's driver causes crash without this patch.
MozReview-Commit-ID: ILtRJrW6MDs
--HG--
extra : rebase_source : a513bfa3c1fc408743bd5b4aed6e416f4d8cc0d7
