Previously we snapped the results of nsDisplayItem::GetBounds and
nsDisplayItem::GetOpaqueRegion internally. By tracking which display items were
inside transforms, we disabled snapping quite conservatively whenever an ancestor
had a transform, which is undesirable.
With this patch, we don't snap inside GetBounds or GetOpaqueRegion, but just return
a boolean flag indicating whether the item will draw with snapping or not. This flag
is conservative so that "true" means we will snap (if the graphics context has a transform
that allows snapping), but "false" means we might or might not snap (so it's always safe
to return false).
FrameLayerBuilder takes over responsibility for snapping item bounds. When it converts
display item bounds to layer pixel coordinates, it checks the snap flag returned from
the display item and checks whether the transform when we draw into the layer will be
a known scale (the ContainerParameters scale factors) plus integer translation. If both
are true, we snap the item bounds when converting to layer pixel coordinates. With
this approach, we can snap item bounds even when the items have ancestors with active
transforms.
Add an extra change hint, UpdateOverflow, that can be used to specify that
a frame's overflow areas may have changed and that they need to be recalculated.
When a transform on a frame changes, instead of marking it for reflow, set this
hint instead.
There is an added virtual function on nsIFrame, UpdateOverflow, which is called
recursively on a frame when the corresponding hint is set, to allow it to
update its overflow areas.
Make nsCSSFrameConstructor::ConstructTable return a null frame if
creating the inner table frame fails. Simplify some code since we can
now depend on the invariant that a properly created outer table frame
always has a non-null inner table frame.
Since this affects only the *visual* overflow and not the *scrollable*
overflow, this patch should result in no behavior changes, since the
necessary visual overflow is added in
nsTextFrame::UnionAdditionalOverflow (since the text frame now draws the
shadows of text decorations, just like it draws text decorations
themselves).
This changes the only remaining callers (in nsMathMLChar) to pass the
correct language, which they were not previously doing, which should
improve the correctness of font selection and also reduce the number of
unique font metrics objects requested (which helps nsFontCache
effectiveness). Those callers, however, remain the odd font users
within all of layout.
There was nothing wrong with SetFontFromStyle, except that it's just one
more API to think about (and one more API to audit and modify for font
inflation work to happen in bug 627842).
This changes a number of callers that were previously bypassing the use
of the correct language (with either no language or the charset-detected
language on the pres context via nsPresContext::GetMetricsFor) and/or
the correct user font set to pass the correct values, which should
improve the correctness of the behavior of whatever they were using the
fonts for, and also reduce the number of unique sets of font metrics
requested (which helps nsFontCache effectiveness).
