Don't paint below image's baseline unless it is selected.

Source/core/rendering/RenderReplaced.cpp

Index: Source/core/rendering/RenderReplaced.cpp
diff --git a/Source/core/rendering/RenderReplaced.cpp b/Source/core/rendering/RenderReplaced.cpp
index 353f974bcd0a68e8ae1361e7457ee17ef4d388dc..f9a9be749b507f318f4f996936083ecda0b1f839 100644
--- a/Source/core/rendering/RenderReplaced.cpp
+++ b/Source/core/rendering/RenderReplaced.cpp
@@ -575,7 +575,15 @@ void RenderReplaced::setSelectionState(SelectionState state)
     // The selection state for our containing block hierarchy is updated by the base class call.
     RenderBox::setSelectionState(state);
 
-    if (inlineBoxWrapper() && canUpdateSelectionOnRootLineBoxes())
+    if (!inlineBoxWrapper())
+        return;
+
+    // We only include the space below the baseline in our layer's cached repaint rect if the
+    // image is selected. Since the selection state has changed update the rect.
+    if (hasLayer())
+        layer()->repainter().computeRepaintRects(containerForRepaint());

[Julien - ping for review, 2014/05/16 12:41:46]

Whenever RenderLayer needs to recompute its repaint rects, repaint-after-layout
requires a similar update: both RenderLayer and repaint-after-layout updates
their rectangles after layout, which isn't scheduled to happen here.

For repaint-after-layout, it's only a matter of calling
setPreviousRepaintRectangle(clippedOverflowRectForRepaint(containerForRepaint())
(gated by RuntimeEnabledFeatures::repaintAfterLayoutEnabled).

Also I am concerned about the call to containerForRepaint(), are we sure that
the compositing information is up-to-date? Else this is introducing a new
chicken-and-egg issue that repaint-after-layout wanted to solve.

[rhogan, 2014/05/16 21:05:47]

The RAL call to setPreviousRepaintRectangle happens in computeRepaintRects()
already, so I get it by calling that function, no?
I'm not clear on what could happen to change the repaintContainer between
layouts. It looks like the main potential culprit is a change in compositing
state. Can you give me some pointers?

What is the worst case scenario here? Is it an unnecessary invalidation or a
painting artefact?

[Julien - ping for review, 2014/05/19 09:31:36]

Good point, you don't need to call it twice indeed.
Those are great questions. I don't actually know the exact worst case (it's
possible someone looked at it though but I haven't heard about any such
results). My hunch would be an unneeded invalidation (assuming the GPU does an
invalidation to the appropriate GraphicsLayer when it loses some child backing).

My point was more conceptual: we want to remove chicken and egg issues so if we
end up adding a new one, that's bad.

+
+    if (canUpdateSelectionOnRootLineBoxes())
         inlineBoxWrapper()->root().setHasSelectedChildren(isSelected());
 }
 
@@ -601,7 +609,6 @@ bool RenderReplaced::isSelected() const
     ASSERT(0);
     return false;
 }
-
 LayoutRect RenderReplaced::clippedOverflowRectForRepaint(const RenderLayerModelObject* repaintContainer) const
 {
     if (style()->visibility() != VISIBLE && !enclosingLayer()->hasVisibleContent())
@@ -609,7 +616,7 @@ LayoutRect RenderReplaced::clippedOverflowRectForRepaint(const RenderLayerModelO
 
     // The selectionRect can project outside of the overflowRect, so take their union
     // for repainting to avoid selection painting glitches.
-    LayoutRect r = unionRect(localSelectionRect(false), visualOverflowRect());
+    LayoutRect r = isSelected() ? localSelectionRect() : visualOverflowRect();
 
     RenderView* v = view();
     if (!RuntimeEnabledFeatures::repaintAfterLayoutEnabled() && v) {