WebKit Bugzilla
New
Browse
Log In
×
Sign in with GitHub
or
Remember my login
Create Account
·
Forgot Password
Forgotten password account recovery
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-
Details
Formatted Diff
Diff
View All
Add attachment
proposed patch, testcase, etc.
Kenneth Russell
Comment 1
2010-11-24 14:09:42 PST
Created
attachment 74791
[details]
Patch
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
Committed
r72703
: <
http://trac.webkit.org/changeset/72703
>
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.
Top of Page
Format For Printing
XML
Clone This Bug