rename SkDevice::eraseColor to clear, make virtual, implement on SkGpuDevice

[bsalomon, 2011-04-14 18:17:57]

PDF will probably want to implement this. Note, the API on device was already
there, it just only worked for raster.

[Steve VanDeBogart, 2011-04-14 18:25:18]

On 2011/04/14 18:17:57, bsalomon wrote:
> PDF will probably want to implement this. Note, the API on device was already
> there, it just only worked for raster.

Is there an easy way to unify this with drawPaint or implement one with the
other?

[reed1, 2011-04-14 18:31:07]

LGTM

[bsalomon, 2011-04-14 18:31:20]

The key difference is that clear ignores the clip. It's equivalent to save,
opening the clip, drawPaint, restore. I guess the default impl could do that
but it seems inefficient.

On Thu, Apr 14, 2011 at 2:25 PM, <vandebo@chromium.org> wrote:

> On 2011/04/14 18:17:57, bsalomon wrote:
>
>> PDF will probably want to implement this. Note, the API on device was
>>
> already
>
>> there, it just only worked for raster.
>>
>
> Is there an easy way to unify this with drawPaint or implement one with
> the other?
>
>
> http://codereview.appspot.com/4419043/
>

[Steve VanDeBogart, 2011-04-14 18:56:15]

On 2011/04/14 18:17:57, bsalomon wrote:
> PDF will probably want to implement this. Note, the API on device was already
> there, it just only worked for raster.

Looking closer, it isn't used from from SkCanvas, and is almost only used
internally (bitmap_platform_device_linux being the exception, but that can be
change to device->accessBitmap(true)->eraseColor(...)).  Would it make sense to
make it private or protected?  Or do you want to use it as part of the public
Device interface?

My concern is simply the expansion of the Device interface...

[Steve VanDeBogart, 2011-04-14 19:37:50]

Ok, part of a large plan.  LGTM.

[bsalomon, 2011-04-14 19:47:10]

closed with r1130