Bug 107487 - [Safari][CSS Filters] Inconsistent color in element drawn across compositing tiles with filter applied
Summary: [Safari][CSS Filters] Inconsistent color in element drawn across compositing ...
Status: NEW
Alias: None
Product: WebKit
Classification: Unclassified
Component: Layout and Rendering (show other bugs)
Version: 528+ (Nightly build)
Hardware: Macintosh Intel OS X 10.8
: P2 Normal
Assignee: Nobody
URL:
Keywords:
Depends on:
Blocks: 68469
  Show dependency treegraph
 
Reported: 2013-01-21 16:43 PST by Max Vujovic
Modified: 2014-03-02 09:23 PST (History)
6 users (show)

See Also:


Attachments
Reproduction (314 bytes, text/html)
2013-01-21 16:43 PST, Max Vujovic
no flags Details
Safari Screenshot (17.73 KB, image/png)
2013-01-21 16:44 PST, Max Vujovic
no flags Details
Safari Screenshot with Compositing Borders (20.77 KB, image/png)
2013-01-21 16:45 PST, Max Vujovic
no flags Details
Reproduction 2 - Green Div vs. Green Div with Pass Through Filter (607 bytes, text/html)
2013-01-31 10:05 PST, Max Vujovic
no flags Details
Reproduction 2 Safari Screenshot with Tiled Drawing Enabled (1.78 KB, image/png)
2013-01-31 10:07 PST, Max Vujovic
no flags Details
Reproduction 2 Safari Screenshot with Tiled Drawing Disabled (1.68 KB, image/png)
2013-01-31 10:07 PST, Max Vujovic
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Max Vujovic 2013-01-21 16:43:47 PST
Created attachment 183852 [details]
Reproduction

Open the attached reproduction in Safari WebKit nightly r140335.

The portion of green div located between y=512px and y=1024px of the document renders with a different shade of green than the rest of the div.

Using different color spaces on your monitor may make the issue more or less obvious.

This only reproduces in Safari. Chromium and Firefox render the entire div with the same shade of green as Safari does between y=512px and y=1024px.
Comment 1 Max Vujovic 2013-01-21 16:44:55 PST
Created attachment 183853 [details]
Safari Screenshot
Comment 2 Max Vujovic 2013-01-21 16:45:20 PST
Created attachment 183854 [details]
Safari Screenshot with Compositing Borders
Comment 3 Max Vujovic 2013-01-21 16:48:47 PST
If you remove the sepia(0%) filter in the reproduction, the issue disappears. sepia(0%) should be a pass through. It is possible to reproduce this with other filters like blur and drop-shadow as well.
Comment 4 Max Vujovic 2013-01-31 10:05:58 PST
Created attachment 185800 [details]
Reproduction 2 - Green Div vs. Green Div with Pass Through Filter

Attaching a different reproduction of possibly the same issue. This reproduction might be easier to see.

On Safari, Reproduction 2 shows a color difference between:
- a div with background-color: #0f0
- a div with background-color: #0f0 and a pass-through filter like grayscale(0).

Interestingly, when you "Disable Tiled Drawing in New Tabs" from the Debug menu, the two divs' colors match. Screenshots will follow.
Comment 5 Max Vujovic 2013-01-31 10:07:12 PST
Created attachment 185801 [details]
Reproduction 2 Safari Screenshot with Tiled Drawing Enabled
Comment 6 Max Vujovic 2013-01-31 10:07:49 PST
Created attachment 185802 [details]
Reproduction 2 Safari Screenshot with Tiled Drawing Disabled
Comment 7 Rik Cabanier 2013-02-28 20:46:59 PST
(In reply to comment #6)
> Created an attachment (id=185802) [details]
> Reproduction 2 Safari Screenshot with Tiled Drawing Disabled

(In reply to comment #0)
> Created an attachment (id=183852) [details]
> Reproduction
> 
> Open the attached reproduction in Safari WebKit nightly r140335.
> 
> The portion of green div located between y=512px and y=1024px of the document renders with a different shade of green than the rest of the div.
> 
> Using different color spaces on your monitor may make the issue more or less obvious.
> 
> This only reproduces in Safari. Chromium and Firefox render the entire div with the same shade of green as Safari does between y=512px and y=1024px.

This seems to be a problem with wkIOSurfaceContextCreate.
It sometimes seems to pick an sRGB colorspace instead of an DeviceRGB one. You can verify this by creating a cgContext with sRGBColorSpaceRef() in ImageBufferCG.cpp. After making that change, there are no more seams.

Maybe wkIOSurfaceContextCreate tries to create a devicecolorspace and if that fails, it falls back to no color managment