RESOLVED FIXED 45400
chromium/mac: let image layer data row order match skia
https://bugs.webkit.org/show_bug.cgi?id=45400
Summary chromium/mac: let image layer data row order match skia
Nico Weber
Reported 2010-09-08 10:54:48 PDT
chromium/mac: let image layer data row order match skia
Attachments
Patch (1.70 KB, patch)
2010-09-08 10:58 PDT, Nico Weber
no flags
Patch (7.98 KB, patch)
2010-09-08 13:50 PDT, Nico Weber
no flags
Patch (8.39 KB, patch)
2010-09-13 18:20 PDT, Nico Weber
no flags
Nico Weber
Comment 1 2010-09-08 10:58:21 PDT
Nico Weber
Comment 2 2010-09-08 10:59:21 PDT
With this, images are no longer upside down when using the compositor with chrome mac. This is http://crbug.com/54834
David Levin
Comment 3 2010-09-08 11:05:48 PDT
What layout test does this fix? If none, please add one.
David Levin
Comment 4 2010-09-08 11:06:32 PDT
Comment on attachment 66915 [details] Patch See comment in bug. (If this fixes an existing layout test, add the info to the bug.)
Nico Weber
Comment 5 2010-09-08 11:12:30 PDT
This happens on a lot of images (every image with a css transform i believe), so I'm pretty sure this is covered by existing layout tests. The problem is that we don't run layout tests with compositing enabled yet, which is why this wasn't caught by tests.
David Levin
Comment 6 2010-09-08 11:17:04 PDT
(In reply to comment #5) > This happens on a lot of images (every image with a css transform i believe), so I'm pretty sure this is covered by existing layout tests. The problem is that we don't run layout tests with compositing enabled yet, which is why this wasn't caught by tests. Pls say something simple in the ChangeLog (and I'll gladly r+ it). Something like "Test: This will be caught by layout tests that have images with a css transform when the compositor is turned on for layout tests."
Kenneth Russell
Comment 7 2010-09-08 11:20:10 PDT
There is already Core Graphics-specific logic in ContentLayerChromium (see ContentLayerChromium::SharedValues::SharedValues(), fragmentShaderString) which performs a vertical flip. The origin difference between CG and Skia also affects scrolling; see LayerRendererChromium::drawLayers. Have these been taken into consideration with this patch?
Nico Weber
Comment 8 2010-09-08 13:50:40 PDT
Nico Weber
Comment 9 2010-09-08 13:52:43 PDT
(In reply to comment #7) > There is already Core Graphics-specific logic in ContentLayerChromium (see ContentLayerChromium::SharedValues::SharedValues(), fragmentShaderString) which performs a vertical flip. The origin difference between CG and Skia also affects scrolling; see LayerRendererChromium::drawLayers. Have these been taken into consideration with this patch? It hasn't. I just noticed that stuff looked wrong, and with this patch it looks right. After looking at things, it seems to be much cleaner to have the in-memory representation for skia and cg be identical and then remove all these tweaks (like we do in the software path). I've uploaded a revised patch that does this.
Nico Weber
Comment 10 2010-09-08 14:04:13 PDT
Comment on attachment 66934 [details] Patch Please wait with reviewing this in detail.
Nico Weber
Comment 11 2010-09-13 16:43:51 PDT
Comment on attachment 66934 [details] Patch I'm not sure why this is not necessary for ImageLayerChromium too, but ImageCG.cpp calls CGContextScaleCTM(context, 1, -1) as well, so I suppose CGImageRefs are already flipped for some reason. This change is ready for review.
Kenneth Russell
Comment 12 2010-09-13 17:20:56 PDT
Comment on attachment 66934 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=66934&action=prettypatch Thanks for cleaning this up. Would appreciate it if you could clean up two very minor things before commit. > WebCore/ChangeLog:20 > + (WebCore::ImageLayerChromium::updateContents): Could you regenerate the ChangeLog? ImageLayerChromium.cpp isn't touched in the diffs below. > WebCore/platform/graphics/chromium/ContentLayerChromium.cpp:-87 > - " vec4 texColor = texture2D(s_texture, vec2(v_texCoord.x, 1.0 - v_texCoord.y)); \n" Could you please clean up the comment at the top of the fragmentShaderString too, in particular the reference to the differences in origin?
Nico Weber
Comment 13 2010-09-13 18:20:04 PDT
Kenneth Russell
Comment 14 2010-09-13 18:46:02 PDT
Comment on attachment 67500 [details] Patch View in context: https://bugs.webkit.org/attachment.cgi?id=67500&action=prettypatch Looks good to me. The commit queue might reject this because you cq+'d it before it was r+'d; if that happens just cq+ it again.
WebKit Commit Bot
Comment 15 2010-09-14 14:02:48 PDT
Comment on attachment 67500 [details] Patch Clearing flags on attachment: 67500 Committed r67493: <http://trac.webkit.org/changeset/67493>
WebKit Commit Bot
Comment 16 2010-09-14 14:02:53 PDT
All reviewed patches have been landed. Closing bug.
Note You need to log in before you can comment on or make changes to this bug.