Original patch author is Takuro Ashie <ashie@clear-code.com>
Provide ability to create native EGL window and provide it under NS_NATIVE_EGL_WINDOW
to GL code. The native EGL window is owned/managed by mozcontainer.
MozReview-Commit-ID: 4d0Kk6DRSaD
--HG--
extra : rebase_source : e4677ce51fbf918eb1b0257c66ca4b7220174bbb
These GENERATED_FILES appear to be leftover from when parts
widget/android/bindings were still in Makefile.in, and are now redundant
with the GENERATED_FILES tuple in this moz.build file.
MozReview-Commit-ID: CxVDJQNCWeG
--HG--
extra : rebase_source : 9bed76436a458b680695ccc7ff9e19dc8497a80d
Implement SetCompositorHint() which sets _NET_WM_BYPASS_COMPOSITOR GtkWindow property when it's recreated
at nsWindow::SetDrawsInTitlebar().
Window role/class is handled by nsWindow::RefreshWindowClass(), it uses stored window class
passed to nsWindow::SetWindowClass().
MozReview-Commit-ID: 1JJsK1ZQyvu
--HG--
extra : rebase_source : 004fe2e379bf1ca2f157ef8df66c5875ab2c135c
"alloc-failure" is completely unused apart from the description text in nsI-
Memory.idl (and has been since before Firefox 17), while "lowering-priority" is
still being checked for in the PuppetWidget, but otherwise unused as well since
the feature using it was decommissioned in bug 1234176.
Since we're touching the PuppetWidget code anyway, we take the opportunity to
add a check for "low-memory-ongoing" instead, since similar as to how things
used to be with "lowering-priority", we want to drop the LayerManager's cached
resources only when receiving a real full memory-pressure event, but not for
subsequent ongoing notifications.
MozReview-Commit-ID: HL03SOU8axe
--HG--
extra : rebase_source : c988769df36d8d77f4770c71d5c5e0d75c3b99af
Currently we don't create the Compositor until we have a valid surface
to render into. This causes a race that can result in us not being able
to display anything at all once a surface is provided and the compositor
is started. It seems the easiest thing to do right now is to avoid the
race by starting the Compositor immediately.
MozReview-Commit-ID: HkdVL3LBNZB
Read more information from the printing device to setup the unwritable region.
Translate the printing context's coordinate system so that the point (0,0)
refers to the top-left of the physical paper instead of the top-left of the
printable region.
MozReview-Commit-ID: 9ei2FgEUDyO
--HG--
extra : rebase_source : c2e2715f47499538035101a285152eca2aba3202
Instead of the helper methods in GeckoBundle, add SDK JNI calls for the
boxing/unboxing operations, and use those calls directly. Moreover, for
unboxing Boolean/Double/Integer, use their internal "value" field value
directly if possible, to avoid making a JNI method call.
MozReview-Commit-ID: Azvov1gCeje
--HG--
extra : rebase_source : 34cd4a821d2b47e48957f241bbf165439635be59
Currently we don't create the Compositor until we have a valid surface
to render into. This causes a race that can result in us not being able
to display anything at all once a surface is provided and the compositor
is started. It seems the easiest thing to do right now is to avoid the
race by starting the Compositor immediately.
MozReview-Commit-ID: HkdVL3LBNZB
The clip chain API in webrender allows us to build the clip state in WR
so that it matches the gecko display list more closely. This patch throws
away ScrollingLayersHelper.* and introduces ClipManager.* which pushes
the clip state to WR using the new method. A quick summary of the new
method is below.
Each display item in gecko has a DisplayItemClipChain which is a chain
of individual clips. The individual clips are defined in WR, and the
clip ids for those clips are put into a WR clip chain using the new
define_clip_chain API. Furthermore, each clip chain can also have a
parent chain, which is used to link a DisplayItemClipChain to the parent
display item's DisplayItemClipChain. This allows the WR clip state to
closely match the structure of the gecko display list clip state,
resulting in more correct behaviour.
There are a few other major changes that are lumped into this patch and
that were tricky to separate into their own patches:
- The collapsing of WrScrollId and WrStickyId into WrClipId. On the WR
side all the clip ids are treated the same anyway. Trying to preserve
the arbitrary distinction on the gecko side was resulting in
increasingly convoluted code, with different kinds of Variant<..>
types in the method signatures. It was much simpler and resulted in a
bunch of code deletion to just collapse the types.
- Moving the "override" mechanism from WebRenderAPI to ClipManager. The
override mechanism (explained in ClipManager.h) was simplified by
moving it into ClipManager, because it removed the need for tracking
additional clip stack state in WebRenderAPI.
MozReview-Commit-ID: GGbdFyJGprK
--HG--
extra : rebase_source : baa56ff179e917b0ab5a5c186a3a415761f8050a
