Move SkShader usage to paint ops |
|||||
Issue descriptionCurrently, painting uses SkShaders (mostly image and picture types) to do various effects. These effects seem largely to be pattern-like effects, where an image or picture is repeated multiple times with some scale and frequency. However, SkShaders are (sometimes) too opaque to find images in and so the cc image hijack canvas and decode cache don’t know about them. One way to fix this once vmiura’s patch lands is to turn SkShaders on paint into saveLayer/restoreLayer-esque draw ops that take in all the parameters for a repeating pattern. This would make the drawImage transparent to the anslysis canvas and would be a short term win for image decoding as well.
,
Dec 8 2016
I think we'll need to think about the best way to make the cross product of Draw types and Shaders.
i.e. {drawRect, drawPath, drawCircle, drawOval, drawArc} x {ImageShader, PictureShader, Gradient, etc.}.
Initially in the prototype, CdlPaint uses CdlShaders that we can make introspectable for image decoding.
,
Jan 3 2017
I don't think there's any need to do a cross product. Blink does not do all of these things with shaders. These shaders are mostly about repeating patterns, and so can just become saveLayer/restoreLayer-like draw operations that can bracket other commands. We don't need to support shaders on a per op level, in my opinion.
,
Feb 16 2018
This issue has been Available for over a year. If it's no longer important or seems unlikely to be fixed, please consider closing it out. If it is important, please re-triage the issue. Sorry for the inconvenience if the bug really should have been left as Available. If you change it back, also remove the "Hotlist-Recharge-Cold" label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Feb 16 2018
This is done, right? Can we close?
,
Feb 16 2018
Yeah, this was fixed with PaintShader. |
|||||
►
Sign in to add a comment |
|||||
Comment 1 Deleted