RESOLVED FIXED 50039
[chromium] Disable antialiasing for compositor
https://bugs.webkit.org/show_bug.cgi?id=50039
Summary [chromium] Disable antialiasing for compositor
Kenneth Russell
Reported 2010-11-24 13:50:25 PST
Chromium's compositor uses GraphicsContext3D for its rendering, and by default requests antialiasing via GraphicsContext3D::Attributes. Currently antialiasing is only implemented for off-screen contexts, not those which render directly to the HostWindow -- except on Mac OS X, which has offscreen context behavior in both cases. This causes a feature disparity between platforms and also negatively impacts performance on Mac because multisampling consumes fill rate. To achieve platform parity we need to explicitly disable antialiasing for the compositor.
Attachments
Patch (3.41 KB, patch)
2010-11-24 14:09 PST, Kenneth Russell
fishd: review+
kbr: commit-queue-
Kenneth Russell
Comment 1 2010-11-24 14:09:42 PST
Vangelis Kokkevis
Comment 2 2010-11-24 14:24:12 PST
Comment on attachment 74791 [details] Patch Looks good.
Kenneth Russell
Comment 3 2010-11-24 15:23:16 PST
Nico Weber
Comment 4 2010-11-24 16:38:10 PST
This makes us look considerably worse than Safari.
Kenneth Russell
Comment 5 2010-11-24 16:43:13 PST
(In reply to comment #4) > This makes us look considerably worse than Safari. As indicated in the comment, more work is needed in order for us to successfully enable antialiasing for the compositor. We need the on-screen case to work on Windows and Linux, but more importantly, we need to measure and address the significant performance issues particular to our Mac OS X port.
Nico Weber
Comment 6 2010-11-24 16:51:24 PST
Other windows and linux browsers don't support compositing, so there's no direct comparison there. Do you have any data how much performance we get from this? On OS X, "pretty" usually beats "a bit faster".
Kenneth Russell
Comment 7 2010-11-24 17:17:51 PST
(In reply to comment #6) > Other windows and linux browsers don't support compositing, so there's no direct comparison there. Do you have any data how much performance we get from this? On OS X, "pretty" usually beats "a bit faster". With two copies of the aquarium demo open ( http://webglsamples.googlecode.com/hg/aquarium/aquarium.html ) on my MacBook Pro, with antialiasing on and http://codereview.chromium.org/5317007 landed we get 15 FPS per window. With antialiasing off we get 20 FPS per window. Firefox 4.0b7, which does all of its compositing in-process, gets 45 FPS per window. The performance impact is significant. However, we are still far behind even with antialiasing disabled. I've filed http://crbug.com/64385 to track one necessary performance optimization on our side. Once that is landed we can re-measure and consider turning antialiasing back on for the compositor. I don't think we should do so before this. We also need to figure out whether there is anything we can be doing differently or better with IOSurfaces. I have a feeling that their copying semantics are causing us to run into fill rate limitations more quickly than browsers that can do all of their compositing in a single process.
Nico Weber
Comment 8 2010-11-24 17:31:07 PST
Thanks for the data and the pointer to that bug. SGTM.
Note You need to log in before you can comment on or make changes to this bug.