[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