764117 - Prefer performance over avoiding seaming

Status: RESOLVED FIXED

(Core :: Layout, defect)

Description

[Bas Schouten (:bas.schouten)]

Attachment: Seam for more complex borders

Right now, for complex combinations of border characteristics we create temporary surfaces and use complex operators for each border corner. This is particular expensive on D2D but also isn't free on other drawing systems. This patch changes us to seam in those complex cases, there's precedent for this, IE9 actually almost always seams even on much simpler border cases. Chrome seams sometimes but not others, I don't know exactly when.

Comment 2

[Bas Schouten (:bas.schouten)]

How do you feel about this roc?

Comment 3

[Robert O'Callahan (:roc) (email my personal email if necessary)]

Comment on attachment 632373 [details] [diff] [review]
Seam for more complex borders

Review of attachment 632373 [details] [diff] [review]:
-----------------------------------------------------------------

I feel fine.

Comment 4

[Phil Ringnalda (:philor)]

Comment on attachment 632373 [details] [diff] [review]
Seam for more complex borders

Might have been good to ask OS X how it felt about it, since as it turns out, it felt like it would have to do https://tbpl.mozilla.org/php/getParsedLog.php?id=12844359&tree=Mozilla-Inbound

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/68be2d36dd3f

Comment 5

[Bas Schouten (:bas.schouten)]

Invisible tiny single-subpixel difference. Any objection if I just add fuzz on OSX to this test?

Comment 6

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I would just add border:none to the test and reference iframes.

Comment 7

[Bas Schouten (:bas.schouten)]

Attachment: Part 0: Slightly change transform stresstest reftest.

Comment 8

[Bas Schouten (:bas.schouten)]

Attachment: Part 0: Mark reftest fuzzy on OS X

The previous patch had reftest issues on OS X 10.6 on try. I've reverted the test and now marked it fuzzy.

Comment 9

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Should we consider making this change only in some cases rather than in all cases?  Perhaps based on either (1) the 'image-rendering' property or a new property like it (2) the width of the border or (3) a combination of the two?

(My sense is that some authors actually do care about getting correct rendering here, but the bulk of the performance problems are not for those authors.)

Comment 10

[Robert O'Callahan (:roc) (email my personal email if necessary)]

I'd rather not introduce any Web-facing API here. Eventually I think we can have correct rendering and performance.

Comment 11

[Robert O'Callahan (:roc) (email my personal email if necessary)]

A heuristic based on the width might be helpful, but I'm not sure what that should be.

Comment 12

[Bas Schouten (:bas.schouten)]

Right now this fallback codepath is also only called in the case of particularly complex borders that don't go through any of our fastpaths. (Unless we go through the 'don't stroke' codepath)

IE9 just seams everywhere. Should we run into web authors having trouble with the seams we could also look at introducing a fastpath for their particular usecase.

Comment 13

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/878a3e1f9591
https://hg.mozilla.org/mozilla-central/rev/9d076b46d1b7