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
Original patch author is Takuro Ashie <ashie@clear-code.com>
NS_NATIVE_EGL_WINDOW is exported by Gtk toolkit code and provides both X11 window
handle for X11 Gtk backend and EGL window handle for Wayland backend.
MozReview-Commit-ID: DEmlaLL7zGY
--HG--
extra : rebase_source : 4e3fb33e68472d61cbc8c555347d4b10343e2628
This function is no longer used since we introduced TransactionWrapper class in
bug 1451469.
MozReview-Commit-ID: FGxi6thbxcP
--HG--
extra : rebase_source : ef5628f8bffb5c1fedf6de80056d4ebba41a9edf
With non-WebRender, the composite is triggered unconditionally when we receive
the transaction from the content side, so we never needed this. The previous
patch adds the composite for the equivalent WebRender codepath, but it's better
to do it explicitly in NotifyLayersUpdated as well. The reason for this is that
with WebRender, this code runs on the updater thread which is not the same as
the compositor thread - so the composition that is scheduled from
WebRenderBridgeParent upon receiving the transaction might happen before the
scroll offset update is actually applied. Triggering a composition from
NotifyLayersUpdated should be a no-op in the cases where a composition is already
scheduled, but in cases where it has not been scheduled, it will schedule one
to ensure the scroll offset update gets composited properly.
MozReview-Commit-ID: Luf76J6QDkr
--HG--
extra : rebase_source : a130f1cf22973910767e96c69962d8b621c0d368
This is mostly just refactoring to make the code more understandable. However,
there are a couple of functional changes:
- If we have scroll offset updates we now schedule a composite instead of
sending the DidComposite right away. This is needed because we want to
actually composite the scroll offset change.
- If there are WebRenderParentCommands provided, we process them and update the
epoch in a single transaction, instead of splitting it across two transactions
for no good reason.
MozReview-Commit-ID: 2HCa19EGxUD
--HG--
extra : rebase_source : f7cdc1b46fbca96b2124582f29c791f8944c1fc9
With non-WebRender, the composite is triggered unconditionally when we receive
the transaction from the content side, so we never needed this. The previous
patch adds the composite for the equivalent WebRender codepath, but it's better
to do it explicitly in NotifyLayersUpdated as well. The reason for this is that
with WebRender, this code runs on the updater thread which is not the same as
the compositor thread - so the composition that is scheduled from
WebRenderBridgeParent upon receiving the transaction might happen before the
scroll offset update is actually applied. Triggering a composition from
NotifyLayersUpdated should be a no-op in the cases where a composition is already
scheduled, but in cases where it has not been scheduled, it will schedule one
to ensure the scroll offset update gets composited properly.
MozReview-Commit-ID: Luf76J6QDkr
--HG--
extra : rebase_source : 3e8cc6c9cd6fb79ab1f7ec3d1e38a34a2c7f6011
This is mostly just refactoring to make the code more understandable. However,
there are a couple of functional changes:
- If we have scroll offset updates we now schedule a composite instead of
sending the DidComposite right away. This is needed because we want to
actually composite the scroll offset change.
- If there are WebRenderParentCommands provided, we process them and update the
epoch in a single transaction, instead of splitting it across two transactions
for no good reason.
MozReview-Commit-ID: 2HCa19EGxUD
--HG--
extra : rebase_source : e5643b83914b47889e4bde6c0f8658fedb3d54fc
This is to accommodate non-networking fd usage (IPC transports, various
databases, .xpi files, etc.), so it's separate from Necko's existing
manipulation of the fd limit, which is tied into Necko's internal limits
on how many sockets it will try to poll at once.
Note that resource limits are inherited by child processes, so this needs
to be done only in the parent.
This patch also removes similar code used on Solaris and Mac OS X. The
Mac case (bug 1036682) refers to fd use by graphics textures, which
shouldn't be consuming fds anymore (even transiently) as of bug 1161166.
MozReview-Commit-ID: 2uodrkW5sUn
--HG--
extra : rebase_source : 5306f4995000459b89bed048ecafba3c262bbbdf
Right now GLContextProviderEGL requires the widget to have a valid
EGLSurface when creating a non-offscreen GLContext. This patch falls
back to a dummy pbuffer surface or EGL_NO_SURFACE if supported, allowing
the GLContext creation to succeed. This will give us some more flexibility
on Android where the widget surface is not always readily available.
Additinally, we use the fallback surface any time MakeCurrent() is
called without a valid surface. This is needed to allow things like
Compositor shutdown when there is no widget surface available.
MozReview-Commit-ID: 1kbLIGNiOkV
Right now GLContextProviderEGL requires the widget to have a valid
EGLSurface when creating a non-offscreen GLContext. This patch falls
back to a dummy pbuffer surface or EGL_NO_SURFACE if supported, allowing
the GLContext creation to succeed. This will give us some more flexibility
on Android where the widget surface is not always readily available.
Additinally, we use the fallback surface any time MakeCurrent() is
called without a valid surface. This is needed to allow things like
Compositor shutdown when there is no widget surface available.
MozReview-Commit-ID: 1kbLIGNiOkV
We are going to re-enable the assertion with a proper fix in bug 1459775.
MozReview-Commit-ID: 2jy6vIImqD
--HG--
extra : rebase_source : ce81b8b2f7dfb47f7db07e820989a65eac38859a
The majority of this patch is just plumbing. The interesting parts are
in WebRenderLayerManager and APZUpdater/WebRenderScrollData. Unlike
ClientLayerManager, which updates the FrameMetrics on the client side
and sends the modified version over to the compositor, this WR version
just sends the update info over to the compositor, which then applies
the update to the metrics saved in APZUpdater before triggering the
hit-testing tree rebuild.
MozReview-Commit-ID: 4latUMa8RFw
--HG--
extra : rebase_source : d0aeaf5a9c8107bbcaf8b0da6d68a0f47f455be5
This allows frames to be generated by the render backend thread even
while the scene builder thread is busy with a long scene build. The
GenerateFrame transaction also contains APZ and OMTA information, so
this allows the user to scroll and view OMTAnimations during long scene
builds.
MozReview-Commit-ID: KG5YC2KwIaH
--HG--
extra : rebase_source : 3ba559aa22a3a036a3b3a034ea20caacdc8c864a
