Closed Bug 1227706 Opened 9 years ago Closed 8 years ago

Make each nsWindow/GeckoView manage their own compositor/GLController

Categories

(Core Graveyard :: Widget: Android, defect)

All
Android
defect
Not set
normal

Tracking

(firefox46 fixed)

RESOLVED FIXED
mozilla46
Tracking Status
firefox46 --- fixed

People

(Reporter: jchen, Assigned: jchen)

References

Details

Attachments

(7 files)

Each nsWindow should have its own compositor, and each GeckoView should manage its own GLController instance, because GLController is responsible for creating/pausing/resuming the compositor.
Depends on: 1227727
Depends on: 1227728
Depends on: 1227731
GLController will no longer be a singleton, but we should keep
initializing EGL only once, so this patch makes EGL initialization
static.
Attachment #8698188 - Flags: review?(snorp)
GeckoViewSupport better reflects the purpose of the class and will match
the GLControllerSupport class that another patch is adding. This patch
also changes the way GeckoViewSupport is constructed in order to be more
encapsulating.
Attachment #8698189 - Flags: review?(snorp)
One nsWindow will have one corresponding GLController, and using native
GLController methods instead of GeckoEvents lets us control the
compositor for each nsWindow separately.
Attachment #8698190 - Flags: review?(snorp)
GLController instances are associated with a particular nsWindow, rather
than a particular View. Therefore, we need to let GeckoView manage
GLController instances, as part of GeckoView's handling of saving and
restoring states.
Attachment #8698191 - Flags: review?(snorp)
This patch adds native method implementations in GLControllerSupport to
manage compositor creation/pause/resume.
Attachment #8698192 - Flags: review?(snorp)
Now that we properly support individual compositors for nsWindows, we
should get rid of the static singletons that held the compositor
objects.
Attachment #8698193 - Flags: review?(snorp)
Remove GLController calls and events in GeckoAppShell and GeckoEvent
that were made obsolete by the new native calls.
Attachment #8698194 - Flags: review?(snorp)
Attachment #8698188 - Flags: review?(snorp) → review+
Attachment #8698189 - Flags: review?(snorp) → review+
Attachment #8698190 - Flags: review?(snorp) → review+
Attachment #8698191 - Flags: review?(snorp) → review+
Comment on attachment 8698192 [details] [diff] [review]
Implement nsWindow::GLControllerSupport (v1)

Review of attachment 8698192 [details] [diff] [review]:
-----------------------------------------------------------------

This seems ok, but please test very thoroughly. This stuff is fragile.

::: widget/android/nsWindow.cpp
@@ +448,5 @@
> +    template<class Functor>
> +    static void OnNativeCall(Functor&& aCall)
> +    {
> +        if (aCall.IsTarget(&GLControllerSupport::CreateCompositor) ||
> +                aCall.IsTarget(&GLControllerSupport::PauseCompositor)) {

Fix indentation
Attachment #8698192 - Flags: review?(snorp) → review+
Comment on attachment 8698193 [details] [diff] [review]
Get rid of compositor singletons in nsWindow (v1)

Review of attachment 8698193 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/android/nsWindow.cpp
@@ +3018,5 @@
>      return sWidgetPaintsBackground;
>  }
>  
>  bool
>  nsWindow::NeedsPaint()

I don't even think this really gets used anymore...
Attachment #8698193 - Flags: review?(snorp) → review+
Attachment #8698194 - Flags: review?(snorp) → review+
Depends on: 1233812
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: