437749 - Excessive repaint in Firefox 3.0 while not in Firefox 2.0

Status: RESOLVED WORKSFORME

(Core :: Layout, defect)

Description

[Bug Filler]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a1pre) Gecko/2008060502 Minefield/3.1a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1a1pre) Gecko/2008060502 Minefield/3.1a1pre

Mouse movement inside the top left canvas is quite slow on FireFox 3 comparing to FireFox 2.0, http://wenq.org/index.cgi?Canvas .

When I run firefox with debug paint on,

  MOZ_DEBUG_PAINTS=1 firefox --no-remote -P wenq 

I can see that when a mouse is moving over the canvas, the whole page was repainted in FF 3.0 while only a little bit unnecessary repaint occurred on FF 2.0. This unconditional repaint will definitely cause a big slow down on the mouse move.



Reproducible: Always

Comment 1

[Sylvain Pasche]

Confirming the regression on trunk

Comment 2

[Sylvain Pasche]

Attachment: reduced testcase

When you mouse over the canvas, a JavaScript function is called to update the mouse position. However, not only the mouse position element is updated, but all the containing div. This only happens if the containing div is floated. The attached testcase tries to reproduce this behavior.

Reporter: if you want to work around this issue in your application, you should look at removing some floats. Removing the float on div.wikiwrapper (wiki2.css) helps, but there may be others because there is still to much repaint afterwards.

Core/GFX Thebes may not be the right place for this, I'm not sure where it should go yet.

Comment 3

[Bug Filler]

Attachment: another testcase of extra repaint on table.

I deduced another situation in where extra repaint happens. If a <div> have css dimensions and a table in it, updating the content of one cell will unconditionally update all the cells after it, even if the height and width of the cell did not changed.

Leaving out the dimension of the <div> will have the table only update the changed cell.

Firefox 2 will just update the cell what so ever.

No float property involved in this case.

Comment 4

[Bug Filler]

Attachment: The 3rd test for form repaint with <input type="text"> field.

When a form has a <input type="text"/> field in it, it will repaint when something is changed somewhere else in the page.

Comment 5

[Bug Filler]

This page repaint the whole table even though only 1 cell changes. Happens in both firefox 3.0 and 2.0. Hogging CPU like crazy.

http://appledaily.atnext.com/template/apple/sec_main.cfm

Comment 6

[Eli Friedman]

The invalidate in question comes from http://hg.mozilla.org/mozilla-central/annotate/5088957eb541/layout/generic/nsBlockFrame.cpp#l2319. Apparently, it's including floats in the combined area it's invalidating, which seems wrong.

I have no clue why this isn't triggering in Firefox 2.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Sounds like the non-float testcases are different bugs (that should be filed separately).

Comment 8

[Wayne Mery (:wsmwk)]

you can still reproduce this?

I can't using Mozilla/5.0 (Windows NT 6.0; rv:12.0a1) Gecko/20111221 Firefox/12.0a1

Comment 9

[BugBot [:suhaib / :marco/ :calixte]]

In the process of migrating remaining bugs to the new severity system, the severity for this bug cannot be automatically determined. Please retriage this bug using the new severity system.

Comment 10

[Daniel Holbert [:dholbert]]

Calling WORKSFORME given comment 8 (and my own observations, where I'm not seeing anything that would indicate that paints are happening in inert areas of the viewport on the given testcase).

(Also, the whole paint pipeline is radically different than it was when this bug was filed, particularly with WebRender now.)

I think we can also remove MOZ_DEBUG_PAINTS=1; I'm not sure it does anything useful at this point. I spun off bug 1832692 for that.