|Issue 2925||perspective + filters + gpu + conservative_rasterclip ?|
|Starred by 3 users||Project Member Reported by email@example.com, Sep 10 2014||Back to list|
SkGpuDevice has an override for forceConservativeRasterClip. If this returns true, we compute a conservative version of the rasterclip for any clipFoo calls made to the canvas. The intent is that the gpu-device doesn't care about the rasterclip anyway, so its fine to cheat and go faster. However, if we draw certain gms through perspective with this enabled, we get different bits than with this disabled. [*] 12 ExpectationsMismatch: blurrects_gpu.png bigblurs_gpu.png imageblurtiled_gpu.png matrixconvolution_gpu.png dropshadowimagefilter_gpu.png skbug1719_gpu.png imageresizetiled_gpu.png xfermodeimagefilter_gpu.png blurquickreject_gpu.png imagefilterscropped_gpu.png verttext_gpu.png imagefiltersclipped_gpu.png Why is this happening? Bug in the conservative code, or bug in canvas or bug in filters?
Sep 11 2014,
Pixel-moving image filters (blur, matrixconvolution, drop shadow) are pretty broken with a perspective matrix -- they do a best-effort to apply the CTM, but they do a pretty poor job if there's anything but scale & translate. So if just rebaselining the tests and calling it a day is an option, I'd do that. However, I notice that there are more than just image filters changed here: blurrects and bigblurs are both mask blurs, IIRC. Maybe Greg could speak to those.
Sep 11 2014,
yes, I think the problems are in image-filters and mask-filters
Oct 14 2014,
Dec 7 2015,
Dec 14 2015,
Is this a dupe of http://skbug.com/3288 ("Pixel-moving image filters (e.g., blur) do not support skew or rotation correctly")? I.e., if we fixed that, would the clip bounds be correctly computed?
Jan 5 2016,
I'll look at it
|► Sign in to add a comment|