New asserts:
- verify that after layout, the size fits the constraints
- verify that after layout, the size isn't infinite
- verify that you don't set the size in performLayout() if you have
sizedByParent set
- verify that nobody reads your size during layout except you, or your
parent if they said parentUsesSize:true
Fixes some bugs found by those asserts:
- RenderBlock, RenderStack, and RenderScaffold were not always setting
parentUsesSize correctly
- RenderScaffold was setting its slot entries to null rather than
removing them when the slot went away, which led to null derefs in
certain circumstances
Also, rename a local variable in RenderStack.performLayout() because
it was shadowing a variable on the object itself, which was really
confusing when I first tried to debug this function...
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/1213473003.
This also fixes the C++ side to give the right baseline information.
Previously it was giving the baseline distance for the font, but not
for the actual laid-out text.
I considered also providing a "defaultBaseline" accessor that returns
the distance for the actual dominant baseline, but it turns out right
now we never decide the baseline is ideographic. We always use the
alphabetic baseline. We should probably fix that...
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1200233002.
This returns us to a more stocks1-like arrow style.
Also it uses math rather than transforms to rotate the arrow, since transforms are expensive.
It also removes the save/restore calls, which are _really_ expensive.
Also some minor style fixes.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1203443007.
The relayout subtree root concept is intended to handle the case where
a node, when it lays itself out for a second time, changes its opinion
about what dimensions it should be. In such a situation, the parent,
if it based its own opinion about what size _it_ should be on the
child's dimensions, would also need to lay itself out again. Thus,
when this scenario is possible, the child remembers the parent, and
when it would be told to relayout, we actually start the layout with
the parent.
In practice, this chains, and we end up with nodes that point to
ancestors ten or more steps up the tree such that when the inner most
child re-lays-out, the whole app ends up relaying out.
This patch tries to short-circuit this for the case where the
constraints being applied to the child are such that actually, the
child has no choice about its dimensions. In that case, the parent
can't change dimensions when the child re-lays-out.
This makes a huge difference on the stocks demo app. Without this, on
the third rendered frame, there are 72 relayoutSubtreeRoot links, the
deepest chain is 8 deep, and 9 of the chains are only 1 level deep.
With it, there are 63 relayoutSubtreeRoot links, the deepest chain is
only 4 deep, and 38 of the chains are only 1 level deep.
R=eseidel@chromium.org
Review URL: https://codereview.chromium.org/1196553004.
Currently you lose your scroll and drawer state when coming back from the settings pane.
I think we should solve this by having the Navigator maintain a Stack and
keeping the StockHome alive underneath it. But this is good enough for a first iteration.
R=abarth@chromium.org, abarth
Review URL: https://codereview.chromium.org/1191153002.
tree of InlineStyle and InlineText elements.
StyledText builds an Inline that renders the tree.
For example this StyledText object:
new StyledText(["FOO", [boldLargerStyle, [greenStyle "BAR"], "BAZ"] BORF]);
Renders the same way the following HTML would,
assuming that TextStyles boldLargerStyle and
greenStyle were defined.
<style>
div {
display: inline;
}
</style>
<p>
<div>
FOO
<div style="font-weight:bold; font-size:larger">
<div style="color:green">
BAR
</div>
BAZ
</div>
BORF
</div>
</p>
R=abarth@chromium.org
Review URL: https://codereview.chromium.org/1194693002.
