Closed Bug 1251122 Opened 8 years ago Closed 8 years ago

Use native IPC call for Fullscreen API on e10s

Categories

(Core :: DOM: Core & HTML, defect, P3)

defect

Tracking

()

RESOLVED INCOMPLETE
Tracking Status
e10s + ---

People

(Reporter: xidorn, Unassigned)

References

(Blocks 1 open bug, )

Details

(Whiteboard: btpp-backlog)

When I implemented bug 1161802, I wasn't aware of the native way to communicate between parent and child process, and thus JavaScript is used for redirecting every message.

It seems to me it is easier and probably also faster to just add things to PBrowser.ipdl and implement things inside PuppetWidget so that we do IPC call directly rather than having JS code to redirect messages.

Using this may relieve some performance issue like bug 1243014.
Trying to recall how the setup then works in non-e10s... Hopefully we can keep e10s and non-e10s as similar as possible. And in some cases message managers (which work in both cases) is one way to achieve that. But in some cases not.
Performance isn't really critical aspect here, but whatever which makes the code easiest to maintain.
The current setting makes e10s and non-e10s pretty different... I think. We still need different code paths for e10s and non-e10s anyway, but I imagine using native IPC call could simplify the current code.

Performance isn't too critical, but still important, as we don't have much time for the fullscreen changing. The reflow can sometimes take ~200ms, if other steps take too long, we would miss the 500ms black screen timeout and throw the user to an intermediate state. Actually from my observation, a message could sometimes take nearly 100ms, which is too long here. (But I have no idea how can I profile this issue...)
tracking-e10s: --- → +
Whiteboard: btpp-backlog
Priority: -- → P3
Priority: -- → P3
Assignee: nobody → bugzilla
Whiteboard: btpp-backlog → btpp-active
After some investigation, it seems not using native IPC call is unlikely where the actual performance issue is.

Using native IPC call may simplify some part of code for starting the fullscreen toggle, but it is probably not equally good for reporting MozAfterPaint after the toggle.
Assignee: bugzilla → nobody
Whiteboard: btpp-active → btpp-backlog
Close it for now as I don't see the necessity of this change anymore. But we might probably want to do it one day.
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → INCOMPLETE
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.