[Webkit-unassigned] [Bug 86422] New: [chromium] GraphicsLayerChromium::setFilters does no checks on if the filters can be handled by our compositor
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Mon May 14 18:05:45 PDT 2012
https://bugs.webkit.org/show_bug.cgi?id=86422
Summary: [chromium] GraphicsLayerChromium::setFilters does no
checks on if the filters can be handled by our
compositor
Product: WebKit
Version: 528+ (Nightly build)
Platform: Unspecified
OS/Version: Unspecified
Status: NEW
Severity: Normal
Priority: P2
Component: New Bugs
AssignedTo: webkit-unassigned at lists.webkit.org
ReportedBy: jamesr at chromium.org
CC: simon.fraser at apple.com, cmarrin at apple.com,
senorblanco at chromium.org, jamesr at chromium.org,
danakj at chromium.org
GraphicsLayer::setFilters() returns a bool indicating whether the compositor can handle that set of filters or if they need to fall back to software. It looks like the CA implementation currently checks this (returning false for custom, reference, or drop shadows outside the final position), but chromium always returns true and then silently drops non-supported filters on the ground. This probably isn't right - I would expect reference filters that we could render in software will be simply ignored in compositing mode instead of drawn in software.
I can't find any layout tests for reference filters, so it's hard to confirm that the behavior is different. It doesn't look right.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list