New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 646680 link

Starred by 2 users

Issue metadata

Status: WontFix
Owner: ----
Closed: Sep 2016
Cc:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

What is up with ScopedReadLockSkImage?

Project Member Reported by danakj@chromium.org, Sep 14 2016

Issue description

There are 2 consumers of this class. They are both in SoftwareRenderer.

The class has a branch on gl_id though. Is that needed? It's the only use of the compositor context's GrContext in ResourceProvider. And it's a bit weird future-wise to expect the compositor context to have a GrContext.

Thoughts?
 

Comment 1 by enne@chromium.org, Sep 14 2016

Cc: weiliangc@chromium.org
It was for https://codereview.chromium.org/2092913002.  I wanted to change SoftwareRenderer to operate on SkImage where possible instead of SkBitmap so that it could become closer to SkiaRenderer.

Maybe it's too speculative.  If it's in the way, you can get rid of it and we can figure out how to redo it later.

Comment 2 by danakj@chromium.org, Sep 14 2016

I think it looks very display-compositor-specific, and I wonder if the GrContext dependency could move outside of the ResourceProvider class.

Comment 3 by danakj@chromium.org, Sep 14 2016

Status: WontFix (was: Untriaged)
FWIW It was scaring me to recommend using ResourceProvider to manage resources for things outside of cc/ because of this thing. But then BlockingTaskRunner scared me even more which is all thread-specific. So I feel like ResourceProvider is just too many things to too many places right now probably and maybe we can make something finer that's more reusable. For now I recommended not using ResourceProvider outside of cc (eg OffscreenCanvas).

So I can close this but thanks for the info!

Sign in to add a comment