Closed
Bug 450350
Opened 16 years ago
Closed 16 years ago
CSS background image painting chooses tiled vs non-tiled path based on dirty area
Categories
(Core :: Layout, defect)
Core
Layout
Tracking
()
RESOLVED
FIXED
People
(Reporter: roc, Assigned: roc)
References
Details
Attachments
(1 file)
2.54 KB,
patch
|
dbaron
:
review+
dbaron
:
superreview+
|
Details | Diff | Splinter Review |
See bug 421438. Tiled and non-tiled code paths draw the same tile in different ways. However, the code in PaintBackgroundSC decides which path to take based on the dirty area. I don't have a testcase, but this could definitely lead to repainting artifacts in certain cases. It's easy enough to fix, especially now that bug 449324 is fixed.
Attachment #333496 -
Flags: superreview?(dbaron)
Attachment #333496 -
Flags: review?(dbaron)
It seems to me like it would be a bug if these codepaths produced different results in different cases. (I suspect it's probably true for at least some zoomed cases, though.)
Assignee | ||
Comment 2•16 years ago
|
||
See bug 421438 comment #1, item 3. I don't think making DrawTile and DrawImage fully consisistent is an option.
Comment on attachment 333496 [details] [diff] [review] fix ok, r+sr=dbaron. I think you want borderAreaOriginSnapped rather than aBorderArea.TopLeft(), though. (I'm not completely sure... I could think about it more if you want.)
Attachment #333496 -
Flags: superreview?(dbaron)
Attachment #333496 -
Flags: superreview+
Attachment #333496 -
Flags: review?(dbaron)
Attachment #333496 -
Flags: review+
Assignee | ||
Comment 4•16 years ago
|
||
Yeah, I do want borderAreaOriginSnapped because that's what sourceRect, absTileRect and hence the current tiled-path test depend on.
Assignee | ||
Comment 5•16 years ago
|
||
Pushed 1d6f5b3d7ec3.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → FIXED
Comment 6•16 years ago
|
||
Websites such as http://www.cssmagazine.it/ and http://www.98rock.com/cc-common/new/6/indexrock.html scroll much more slowly in the 2008-08-26 nightly build than in the 2008-08-25 one or in Firefox 3.0.1. In addition to slow scrolling, some page elements (like the Google ads on cssmagazine.it) lag behind while scrolling. Is it possible that this regression was caused by this check-in? (Note: I tried this on WinXP.)
Assignee | ||
Comment 7•16 years ago
|
||
Yes. But I'd appreciate it if you filed a new bug with a reduced testcase.
You need to log in
before you can comment on or make changes to this bug.
Description
•