Reworking frame painting

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Reworking frame painting

Robert O'Callahan-2
Various bugs with the view painting system (including at least one
acid2 blocker) suggest that we need to refactor frame painting
significantly. I also want to get rid of views entirely. I propose to
do this in one step by moving all display-list related code from views
to frames. Here are more details on the proposal. Comments appreciated!
I think I can do this about now.

http://wiki.mozilla.org/Gecko:Frame_Painting

Rob

_______________________________________________
mozilla-layout mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reworking frame painting

Boris Zbarsky
roc wrote:
> http://wiki.mozilla.org/Gecko:Frame_Painting

So are you thinking about rebuilding the display list every time it's needed
like we do now?  Or building it once and then maintaining it on relevant changes
(so changes to frame geometry or what would right now be "sync view" changes)?

Also, I assume we plan to do some list length optimization (instead of having
2-3 display list elements per frame in the tree), right?

-Boris
_______________________________________________
mozilla-layout mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reworking frame painting

Robert O'Callahan-2
Yes, I intend to rebuild the display list every time. That will require
a traversal of the visible frame tree (we can prune subtrees whose
bounding box doesn't intersect the dirty rect, just as we currently
do). Note that today we currently traverse the visible frame tree three
times (once per layer) per paint.

We only need to create display items for actual rendered parts of
frames, and only for the visible frames. Most frames don't have borders
and most frames don't have backgrounds. So, I hope the display list
length will be reasonable. We could optimize things so that when
multiple display items for a single frame occur together in z-order
(e.g., border, background and text of an inline element), they're all
represented as one display item ... do you think that's worth it?

Rob

_______________________________________________
mozilla-layout mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reworking frame painting

Boris Zbarsky
roc wrote:
> We could optimize things so that when
> multiple display items for a single frame occur together in z-order
> (e.g., border, background and text of an inline element), they're all
> represented as one display item ... do you think that's worth it?

I think it might be, but that's something to maybe test once we have the basic
setup in place?

-Boris
_______________________________________________
mozilla-layout mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reworking frame painting

Eli Friedman
In reply to this post by Robert O'Callahan-2
A couple of questions:

How does this proposal deal with transformed content?  Does
GetAbsoluteBounds calculate the bounds relative to the nearest widget?
How will frames know their transform?  (this functionality isn't
currently available, but it needs to be addressed at some point)

Removing views completely is a significantly bigger project than just
moving display-list related code.  Hopefully I can find time to help get
rid of some of the view references, but there is a lot of work involved
outside display lists.  Besides miscellaneous code that shouldn't need
views (which there is a lot of), getting rid of views would mean moving
all the widget management code onto frames along with the display-list
code.  Are you planning on moving the widget management code at the same
time?

roc wrote:

> Various bugs with the view painting system (including at least one
> acid2 blocker) suggest that we need to refactor frame painting
> significantly. I also want to get rid of views entirely. I propose to
> do this in one step by moving all display-list related code from views
> to frames. Here are more details on the proposal. Comments appreciated!
> I think I can do this about now.
>
> http://wiki.mozilla.org/Gecko:Frame_Painting
>
> Rob
>
_______________________________________________
mozilla-layout mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-layout
Reply | Threaded
Open this post in threaded view
|

Re: Reworking frame painting

Robert O'Callahan-2
> How does this proposal deal with transformed content?

Not sure what you mean. If you mean SVG foreignobject stuff, then
here's how I expect that to work:
-- there's an nsDisplayItemSVG which an outermost SVG frame pushes onto
the display list
-- nsDisplayItemSVG::Paint just calls into SVG's own paint system to
paint the entire subtree of SVG content
-- if SVG painting encounters a foreignobject, then it calls
BuildDisplayListForStackingContext to build a display list for the
non-SVG subtree, then paints the contents of the display list into a
gfxContext with appropriate transforms already set in it.

Pretty straightforward really. That's basically what my original
foreignobject demo did except it had to be hacked into the view system.
It'll simpler with this approach to viewless painting.

> Does GetAbsoluteBounds calculate the bounds relative to the nearest widget?

No, relative to some arbitrary reference point that is fixed for the
display list. Probably we would choose the origin of the rootmost
widget.

> Removing views completely is a significantly bigger
> project than just moving display-list related code.

Yes. Removing views completely is a longer term project, but moving out
the display-list code is a good first step.

> Are you planning on moving the widget management code at the same time?

My not-so-secret agenda is also to remove all widgets :-) (except for
rootmost widgets (including popups), and plugin-related widgets). I
swear I had  some wiki notes about this but I can't find them... I
believe the main issues are plugins and scrolling, and possibly some
API issues if subdocuments (IFRAMEs) no longer have an nsIWidget.

Rob

_______________________________________________
mozilla-layout mailing list
[hidden email]
http://mail.mozilla.org/listinfo/mozilla-layout