Last Comment Bug 374980 - (compositor) Implement Compositor
(compositor)
: Implement Compositor
Status: NEW
:
Product: Core
Classification: Components
Component: Layout (show other bugs)
: Trunk
: All All
-- normal with 77 votes (vote)
: ---
Assigned To: Nobody; OK to take it and work on it
:
: Jet Villegas (:jet)
Mentors:
Depends on: 465216 130078 510008
Blocks: 318474 337801 374762 481128 big-long-large-32767 339548 372039 400925 418351 433646 452048 457862 607346
  Show dependency treegraph
 
Reported: 2007-03-22 15:38 PDT by Robert O'Callahan (:roc) (email my personal email if necessary)
Modified: 2016-10-03 08:00 PDT (History)
111 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
WIP (443.23 KB, patch)
2007-03-22 21:03 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review
oops, here are the new files (33.05 KB, patch)
2007-03-22 21:16 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details | Diff | Splinter Review

Description User image Robert O'Callahan (:roc) (email my personal email if necessary) 2007-03-22 15:38:22 PDT
See http://wiki.mozilla.org/Gecko:Compositor
Comment 1 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2007-03-22 21:03:39 PDT
Created attachment 259384 [details] [diff] [review]
WIP

This is very incomplete and does not build. I just want it backed up somewhere.
Comment 2 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2007-03-22 21:16:00 PDT
Created attachment 259386 [details] [diff] [review]
oops, here are the new files
Comment 3 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2007-03-22 22:50:45 PDT
What this patch has so far:
-- view hierarchies are unified
-- the prescontext for the root of the Gecko window tree is an nsRootPresContext
-- nsRootPresContext implements the compositor functionality
-- nsRootPresContext manages one or more nsWindowControllers --- usually just one but additional ones for popups
-- nsWindowControllers manage popups
-- move scrolling implementation to layout
-- nsScrollPortView just forwards its API calls to the scrollframe
-- scrolling is handled by a RequestCopyArea method on frames, which works a lot like Invalidate
-- scroll requests are queued along with invalidates in the nsRootPresContext
-- the compositor repaints according to the frame rate unless RequestUrgentUpdate is called; all painting is asynchronous
-- before processing paints and scrolls, we run queued "pre-update" events
-- smooth scrolling reimplemented as an animation source; we update the scrollbar positions when (and only when) we're about to paint
-- scrolling's "onscroll" and scrollport events run as pre-update events so script can modify the DOM before painting
-- defined a new nsIWidget::UpdateWindow API that simultaneously repositions plugins, applies scroll operations, and repaints invalid window areas
-- some gfx utility methods
-- removed existing paint suppression/batching code in various places. It's mostly no longer needed. In some places we will need to put something else back.
Comment 4 User image Eli Friedman 2007-03-27 00:25:44 PDT
Hmm, it'd probably be a good idea to split out as many of the changes as possible.  I think the easy bits to split out are the parts involving changing the nsIScrollPositionListener API, changing nsIScrollableViewProvider to nsIScrollableFrameProvider, adding the new APIs to nsIScrollableFrame, and changing all the users outside of the scroll-frame code of nsIScrollableView to nsIScrollableFrame.

The WIP doesn't seem to respect the current behavior of nsIScrollableViewProvider; for some frames, it provides a view associated with a child scrollframe.  That's why it should probably be changed to nsIScrollableFrameProvider rather than just being zapped (or we could add a virual method on nsIFrame...).

I also might add that the attached version has two copies of nsGfxScrollFrame.cpp, and seems to be missing nsObjectFrame.cpp; I'm assuming that's because the patch isn't finished yet.
Comment 5 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2007-03-27 02:30:33 PDT
(In reply to comment #4)
> Hmm, it'd probably be a good idea to split out as many of the changes as
> possible.

I know. I spent an awfully long time trying to figure out how to break all this work down into separate pieces but ultimately that seemed so hard, thanks to cyclic dependencies, it'd be easier to do most of it in one go.

> I think the easy bits to split out are the parts involving changing
> the nsIScrollPositionListener API, changing nsIScrollableViewProvider to
> nsIScrollableFrameProvider, adding the new APIs to nsIScrollableFrame,

Moving nsIScrollPositionListener from views to layout may be possible as a pre-patch, yeah. I should probably try to do that. But the rest would be tricky without moving scrolling from views to layout, and that's tied intimately into the rest of the patch.

> and
> changing all the users outside of the scroll-frame code of nsIScrollableView to
> nsIScrollableFrame.

I'm actually not doing that, I've left nsIScrollableView around forwarding everything to the frame, so that we have to change less code. Of course ultimately we do want to change all the users to use the frame.

> The WIP doesn't seem to respect the current behavior of
> nsIScrollableViewProvider; for some frames, it provides a view associated with
> a child scrollframe.  That's why it should probably be changed to
> nsIScrollableFrameProvider rather than just being zapped (or we could add a
> virual method on nsIFrame...).

I'll look into that.

> I also might add that the attached version has two copies of
> nsGfxScrollFrame.cpp, and seems to be missing nsObjectFrame.cpp; I'm assuming
> that's because the patch isn't finished yet.

It's actually because I goofed up some incremental updates to the patch as I was reviewing it. Nothing's lost, I have it in a dedicated tree.
Comment 6 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2007-04-28 13:11:15 PDT
Note that this is not going to make Gecko 1.9.
Comment 7 User image Gábor Stefanik 2007-05-01 05:29:45 PDT
Does that mean that Gecko 1.9 will come out with bug 324819 unfixed? That would be a terrible regression from 1.8!
Comment 8 User image Martijn Wargers [:mwargers] 2007-05-01 05:32:45 PDT
(In reply to comment #7)
> Does that mean that Gecko 1.9 will come out with bug 324819 unfixed? That would
> be a terrible regression from 1.8!

No, because that bug has the blocking flag 1.9+ set.
Comment 9 User image Gábor Stefanik 2007-05-01 06:14:57 PDT
But will it be possible without this one? The dependence chain of bug 324819 leads up to this one.
Comment 10 User image Martijn Wargers [:mwargers] 2007-05-01 07:39:01 PDT
Yes, it will be possible.
Comment 11 User image WL 2008-03-02 19:36:17 PST
Bug 130078 depends on this one. Could it be done in 1.9? Or when?
Comment 12 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2008-03-02 20:09:42 PST
No way for 1.9. Top priority after 1.9.
Comment 13 User image Deven Phillips 2008-05-20 14:34:42 PDT
This is a major issue in 1.9!!! There are a large number of canned applications which are broken because of Bug 130078. These include, but are not limited to, XWiki and OpenNMS. These applications are critical to our company and to many others. Additionally, there are countless other sites which use the "overflow: auto" property and will be broken on the initial release of Firefox 3.0. This will be VERY bad for end users.
Comment 14 User image Martijn Wargers [:mwargers] 2008-05-20 14:45:55 PDT
Deven, please file new bugs for whatever problems you see in Firefox 3 with XWiki and OpenNMS. Also try to mention some of the other sites that also have problems in that bug.
Comment 15 User image Mike Schroepfer 2008-05-21 08:22:35 PDT
Deven if we can get specific bugs for any incompatibility issues we will look at those for FF3 - but this bug is a feature request for a major re-work of parts of our graphics pipeline which cannot be done in FF3.
Comment 16 User image Deven Phillips 2008-05-21 13:17:37 PDT
This bug is blocking bug #215055 and that has the specific errors and test cases attached.
Comment 17 User image Ryan Jones 2008-05-21 13:53:14 PDT
Read comment #12. This is NEVER going to happen for 1.9 so there is no point requesting it as a blocker.
Comment 18 User image Deven Phillips 2008-05-21 14:35:18 PDT
That is all well and good, as I understand that this is a difficult recode. So, there needs to be a fix that does not require the compositor. That fix needs to be a stopper for 1.9. If the compositor cannot be complete for 1.9, then what can we do to fix the large block elements problem?
Comment 19 User image Gábor Stefanik 2008-05-21 14:53:28 PDT
Deven, bug 215055 is not a regression - it's there since the beginnings of Mozilla.
Comment 20 User image Bob Miller 2009-02-26 12:36:52 PST
Could we get a status update on this fix?  Is it at all likely to make it into 3.2 or are we waiting for some much later release?  I understanding reworking the whole page composition process is a fairly large change and will take a while to do.
Comment 21 User image Ildar Nurislamov 2009-03-04 04:02:57 PST
Lot of performance issues associated with fixed background. It's because in such cases browser need to completely redraw all page for each scrolling event.

What if compositor will draw such pages in two window mode (in modern OSes). First window will draw fixed background and never will be scrolled. And second window above will draw page content with translucent background. All composition will be made by OS using hardware resources and - it will be very fast on Vista, Mac OS X and Linux with Composite WMs
Comment 22 User image Oleg Romashin (:romaxa) 2009-04-02 22:15:01 PDT
> First window will draw fixed background and never will be scrolled.
Instead "never" it can be scrolled only when scrolling is finished (Button Release event)
Comment 23 User image Gábor Stefanik 2009-07-24 12:52:21 PDT
Any updates on this? Perhaps a newer WIP since the 2007 one? Is this now targeted @ 1.9.2/1.9.3, or is this a 2.0 goal?
Comment 24 User image Robert O'Callahan (:roc) (email my personal email if necessary) 2009-07-24 14:19:14 PDT
A big chunk landed on trunk this week in bug 339548 and bug 352093. I'm working on the rest.
Comment 25 User image Jesse Ruderman 2009-07-25 13:17:52 PDT
For information about the compositor "phases", see
http://groups.google.com/group/mozilla.dev.platform/browse_thread/thread/e2b791ffc84ee3f4#
Comment 26 User image Danial Horton 2009-08-16 23:13:50 PDT
Wow, this is a massive amount work Robert, how much more do you expect to have to do?

Note You need to log in before you can comment on or make changes to this bug.