reflow branch
L. David Baron
now. They're still nowhere near compiling, but I should probably share
what I'm doing sooner rather than later.
The checkins so far are:
http://bonsai.mozilla.org/cvsquery.cgi?branch=REFLOW_200%2841213%7C50111%29_BRANCH&branchtype=regexp&sortby=Date&date=explicit&mindate=2004-12-13&cvsroot=%2Fcvsroot
The basic idea of what I'm doing is what I've described on this list in
the past. In summary:
* removing reflow types, reflow reasons, reflow commands, and the
reflow tree in favor of dirty bits (which we already have, but with
slightly different semantics):
+ NS_FRAME_IS_DIRTY, which says that a frame and all its descendants
need reflow
+ NS_FRAME_HAS_DIRTY_CHILDREN, which says (roughly) that at least one
of a frame's children has either NS_FRAME_IS_DIRTY or
NS_FRAME_HAS_DIRTY_CHILDREN set
This affects both nsIFrame and nsIBox layout.
* replacing the use of Reflow for intrinsic width calculation
(reflowing with width as NS_UNCONSTRAINEDSIZE for preferred width;
setting a special flag on the metrics to get minimum width) with
separate methods to compute these two intrinsic widths. This affects
only nsIFrame layout and makes nsIFrame easier to integrate with
nsIBox.
The goals are:
* simplification of code
* fixing incremental reflow ("{inc}") bugs
* allowing better integration of nsIBox and nsIFrame layout
* allowing easier implementation of new features like 'inline-block'
So far I've done most of the core (i.e., pres shell) work that I know of
that's necessary as well as a good bit of the conversion for nsIBox
layout and its integration with nsIFrame layout, and I've been working
on block and inline layout.
I've commented out HTML forms and tables on the branch -- I'd like to
get the rest compiling and somewhat tested first before attacking forms
and tables, since testing (including profiling) may show some design
changes that need to be made.
I'm definitely at a point where I'd be interested in feedback on the
design of the new code, especially the changes to nsIFrame,
nsLayoutUtils, and ns{I,}PresShell, and to a lesser extent the changes
in nsHTMLReflowState, layout/xul/base/src/*.{h,cpp}, and
layout/generic/nsBlock*. (See a cvs diff between REFLOW_20050111_BASE
and REFLOW_20050111_BRANCH of those files.)
I'm probably to a point where I'd be interested in help if others are
willing to work on this as well, although only from people who
understand what needs to be done without too much help. I think the
high priority things are:
* getting block intrinsic width computation figured out (I'm doing
this, and mostly done with something that should work, although isn't
ideal, since it leaves a good bit of the mess regarding inline stuff
still around)
* fixing the rest of the frame classes in layout/generic and layout/xul
so that they use the new API to move to a point where the branch can
be compiled and tested. Many of the frame classes are pretty simple
to fix; some aren't.
If some of you want to help on the branch, feel free to check in things
you're confident I wouldn't object to; otherwise ask. But try not to
step on each others toes; I'm currently working on nsBlock* and nsLine*,
and I'll try to send status updates on what else I start working on,
especially if others start helping; others should do the same.
The branch is only of layout/ and client.mk; the rest of the tree should
be pulled from the 1.8a6 release; client.mk on the branch should do
this, although I haven't checked (since I last pulled right at the 1.8a6
release).
-David
--
L. David Baron <URL: http://dbaron.org/ >
roc
Is there going to be some version of the "resize reflow" optimization?
I really need to work on graphics more than anything else so I don't
think I'll be on the branch anytime soon.
Rob
L. David Baron
> Is there going to be some version of the "resize reflow" optimization?
I've removed it because I didn't see a good way to do it. I'd probably
either have to find a way to suppress coalescing or maintain a different
set of dirty bits.
Justin Wood (Callek)
> I've been working on reflow architecture changes on a branch for a while
> I'm definitely at a point where I'd be interested in feedback on the
> design of the new code, especially the changes to nsIFrame,
...
>
> -David
>
Well I have been checking periodic diffs through bonsai, and even though
the code involved I still have much to learn about, I like what I have
seen...good job, I cannot wait to see what comes of this,
(and the fact that it will likely be 10-fold easier for me to understand
this code once it is done, is a huge plus).
Not to mention potential benefits of Tp and Txul, etc. I anticipate with
this refactor.
I'll be watching changes, and once I hear that it does build/work (even
minus forms/tables) I'll be glad to test as best I can.
~Justin Wood (Callek)
roc
marked dirty, right?
Rob
Robert Accettura
>
> The goals are:
> * simplification of code
> * fixing incremental reflow ("{inc}") bugs
> * allowing better integration of nsIBox and nsIFrame layout
> * allowing easier implementation of new features like 'inline-block'
>
Is there any change in performance +/- (preferably +)? Or to put it
better. Do you expect to gain or loose any performance?
L. David Baron
Gains in some places; losses in others. I'm hoping more gains than
losses, mainly due to code simplification, which has been known in the
past to help performance. But to get those simplifications I'm removing
some optimizations that I don't think are worthwhile.
-David
--
L. David Baron <URL: http://dbaron.org/ >
Technical Lead, Layout & CSS, The Mozilla Foundation