cc::SkiaRenderer hack prototype

cc::SkiaRenderer hack prototype

Not for landing.  Mostly just to understand what needs to be changed in
SoftwareRenderer to make this possible.  Also, to potentially have
something to do initial performance tests against.
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel

[enne (OOO), 2016-06-23 22:15:03]

Description was changed from

==========
cc::SkiaRenderer hack prototype
==========

to

==========
cc::SkiaRenderer hack prototype
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[enne (OOO), 2016-06-23 22:16:41]

Description was changed from

==========
cc::SkiaRenderer hack prototype
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

to

==========
cc::SkiaRenderer hack prototype
==========

[enne (OOO), 2016-06-23 22:17:35]

Description was changed from

==========
cc::SkiaRenderer hack prototype
==========

to

==========
cc::SkiaRenderer hack prototype

Not for landing.  Mostly just to understand what needs to be changed in
SoftwareRenderer to make this possible.  Also, to potentially have
something to do initial performance tests against.
==========

[enne (OOO), 2016-06-23 22:19:02]

Gets pixels on screen.  Unsupported features like filters and masks just #if 0'd
out.  Videos probably just won't work.  Render passes with bsp trees look weird
(see poster circle).

[enne (OOO), 2016-06-23 23:01:44]

Description was changed from

==========
cc::SkiaRenderer hack prototype

Not for landing.  Mostly just to understand what needs to be changed in
SoftwareRenderer to make this possible.  Also, to potentially have
something to do initial performance tests against.
==========

to

==========
cc::SkiaRenderer hack prototype

Not for landing.  Mostly just to understand what needs to be changed in
SoftwareRenderer to make this possible.  Also, to potentially have
something to do initial performance tests against.
CQ_INCLUDE_TRYBOTS=tryserver.blink:linux_blink_rel
==========

[piman, 2016-06-23 23:27:08]

piman@chromium.org changed reviewers:
+ piman@chromium.org

[piman, 2016-06-23 23:27:09]

Exciting!!

https://codereview.chromium.org/2092913002/diff/20001/cc/output/skia_renderer.cc
File cc/output/skia_renderer.cc (right):

https://codereview.chromium.org/2092913002/diff/20001/cc/output/skia_renderer...
cc/output/skia_renderer.cc:305: // TODO(enne): doot dee doo
lol.

https://codereview.chromium.org/2092913002/diff/20001/cc/output/skia_renderer...
cc/output/skia_renderer.cc:497: const SkImage* image = lock.sk_image();
I wonder if we could make software and GL look closer, e.g. by using a SkImage
in the software case too (I think that's possible?), and maybe by merging
ScopedReadLockSoftware and ScopedReadLockGr into a ScopedReadLockSkImage... I
think the GrContext (in the GL case) could come from the ResourceProvider, since
it's using the same context as the OutputSurface.

[danakj, 2016-06-23 23:31:20]

danakj@chromium.org changed reviewers:
+ danakj@chromium.org

[danakj, 2016-06-23 23:31:20]

https://codereview.chromium.org/2092913002/diff/20001/cc/output/skia_renderer.cc
File cc/output/skia_renderer.cc (right):

https://codereview.chromium.org/2092913002/diff/20001/cc/output/skia_renderer...
cc/output/skia_renderer.cc:497: const SkImage* image = lock.sk_image();
On 2016/06/23 23:27:09, piman wrote:
> I wonder if we could make software and GL look closer, e.g. by using a SkImage
> in the software case too (I think that's possible?), and maybe by merging
> ScopedReadLockSoftware and ScopedReadLockGr into a ScopedReadLockSkImage... I
> think the GrContext (in the GL case) could come from the ResourceProvider,
since
> it's using the same context as the OutputSurface.

Ya. ResourceProvider used to have a GrContext* accessor. I killed it as part of
removing the dependency on OutputSurface from ResourceProvider.

But we could pass a GrContext to the ResourceProvider if we wanted to do that.
Or construct and pass it in from LayerTreeHostImpl to the renderer (less
plumbing?)

[piman, 2016-06-23 23:52:27]

On Thu, Jun 23, 2016 at 4:31 PM, <danakj@chromium.org> wrote:

>
>
>
https://codereview.chromium.org/2092913002/diff/20001/cc/output/skia_renderer.cc
> File cc/output/skia_renderer.cc (right):
>
>
>
https://codereview.chromium.org/2092913002/diff/20001/cc/output/skia_renderer...
> cc/output/skia_renderer.cc:497: const SkImage* image = lock.sk_image();
> On 2016/06/23 23:27:09, piman wrote:
> > I wonder if we could make software and GL look closer, e.g. by using a
> SkImage
> > in the software case too (I think that's possible?), and maybe by
> merging
> > ScopedReadLockSoftware and ScopedReadLockGr into a
> ScopedReadLockSkImage... I
> > think the GrContext (in the GL case) could come from the
> ResourceProvider, since
> > it's using the same context as the OutputSurface.
>
> Ya. ResourceProvider used to have a GrContext* accessor. I killed it as
> part of removing the dependency on OutputSurface from ResourceProvider.
>
> But we could pass a GrContext to the ResourceProvider if we wanted to do
> that. Or construct and pass it in from LayerTreeHostImpl to the renderer
> (less plumbing?)
>

I was thinking a sk_sp<SkImage>
ResourceProvider::MakeSkImageFromResource(ResourceId resource_id), that
would do the right thing depending on the type or resource (grabbing the
GrContext from the RP's context_provider). I'm even envisioning software
and GL textures magically interoperating magically... truth, beauty,
freedom, love?


>
> https://codereview.chromium.org/2092913002/
>

-- 
You received this message because you are subscribed to the Google Groups
"Chromium-reviews" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to chromium-reviews+unsubscribe@chromium.org.

[enne (OOO), 2016-06-24 00:27:52]

If cc::SkiaRenderer is the future, then I eventually seeing
Renderer/DirectRenderer/*Renderer all collapsing together into a single
cc::SkiaRenderer.  But I think to get there we'll probably want to stage it by
making smaller changes to SoftwareRenderer.

100% agreed that ResourceProvider needs to be less explicit about the kinds of
resources it's vending out, and just needs to hand out SkSurfaces and SkImages
and somehow abstract this difference away.  Using the GrContext coming from the
ResourceProvider is a great idea to get there.

[bsalomon, 2016-06-24 15:25:06]

bsalomon@google.com changed reviewers:
+ bsalomon@google.com

[bsalomon, 2016-06-24 15:25:07]

For some reason inline commenting on skia_renderer.cc isn't working for me.
Anyway, (somewhat confusingly) GrSurfaceDesc::fSampleCnt should be 0 not 1 for
non-MSAA rendering.

https://codereview.chromium.org/2092913002/diff/20001/cc/output/skia_renderer.cc
File cc/output/skia_renderer.cc (right):

https://codereview.chromium.org/2092913002/diff/20001/cc/output/skia_renderer...
cc/output/skia_renderer.cc:497: const SkImage* image = lock.sk_image();
On 2016/06/23 23:27:09, piman wrote:
> I wonder if we could make software and GL look closer, e.g. by using a SkImage
> in the software case too (I think that's possible?), and maybe by merging
> ScopedReadLockSoftware and ScopedReadLockGr into a ScopedReadLockSkImage... I
> think the GrContext (in the GL case) could come from the ResourceProvider,
since
> it's using the same context as the OutputSurface.

SkImage should be able to replace SkBitmap in the SW renderer as well.