505358 - nsTablePainter bitrotten

Status: NEW

(Core :: Layout: Tables, defect)

Description

[fantasai]

The TableBackgroundPainter is bitrotten, parts of the code have no effect. See e.g. attachment 389440 [details] [diff] [review] which has no effect on our output. We need to evaluate the state of table background painting and put things back in working order.

The code also hasn't been revamped since the introduction of display lists, and probably needs some changes to fit into our new painting system.

Comment 1

[Bernd]

do you see visible damages in your test cases at http://mxr.mozilla.org/mozilla-central/source/layout/reftests/table-background/backgr_index.html. If so we need to create reftests to make sure that this will not repeat.

Comment 2

[fantasai]

Yes, http://mxr.mozilla.org/mozilla-central/source/layout/reftests/table-background/backgr_layers-opacity.html has regressed since FF3.0. I figured that out after looking at roc's patch... (The problem exists but is hard to see on some of the other testcases, due to the coloring.)

I agree that we need to create reftests for these.

Comment 3

[Bernd]

this could be my fix for bug 155955

Comment 4

[fantasai]

(Yes, I'm referring to the white stripe.) It's probably a combination of patches that resulted in the current behavior, but fundamentally the problem there is that the table painter expects nsCSSRendering to use its parameters in a way that it no longer does. Your patch might have exposed the problem in these testcases, but it's existed for a while.

Comment 5

[Julien "_FrnchFrgg_" RIVAUD]

Replacing the TablePainter with something which creates a separate display item (or even one display item for each layer of the table bg & border spec) for each cell) is one of the things I'd like to try (except for the borders in BC case for now).

Perhaps the best is even to make a standard traversal of the children and remove the table special casing (but I doubt it, since it would probably mean a lot of things computed/fetched anew for each cell, such as the column background); the main question is how to find the right amount between computing a lot at display list creation time, which means special display items that use more member values, and computing the least possible at display list creation and fetching what we need at paint time (with possibly a lot of the display items optimized away).

Anyway, in https://bugzilla.mozilla.org/show_bug.cgi?id=452319#c15 bernd suggested that the right time to do that was later in his BC refactoring cycle.

I'm open to suggestions (and I have some free time, not like during the 5-6 last months)

Comment 6

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

The bug assignee is inactive on Bugzilla, so the assignee is being reset.