Closed Bug 1227706 Opened 10 years ago Closed 10 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: