Created attachment 632373 [details] [diff] [review] 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.
How do you feel about this roc?
Comment on attachment 632373 [details] [diff] [review] Seam for more complex borders Review of attachment 632373 [details] [diff] [review]: ----------------------------------------------------------------- I feel fine.
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
Invisible tiny single-subpixel difference. Any objection if I just add fuzz on OSX to this test?
I would just add border:none to the test and reference iframes.
Created attachment 635571 [details] [diff] [review] Part 0: Slightly change transform stresstest reftest.
Created attachment 635598 [details] [diff] [review] 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.
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.)
I'd rather not introduce any Web-facing API here. Eventually I think we can have correct rendering and performance.
A heuristic based on the width might be helpful, but I'm not sure what that should be.
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.