941408 - Can we evolve TextureClient to replace GrallocImage and GraphicBufferLocked?

Status: RESOLVED INVALID

(Core :: Graphics, defect)

Description

[Benoit Jacob [:bjacob] (mostly away)]

As part of the "Surfaces" effort (see bug 941399 and https://wiki.mozilla.org/Platform/GFX/Surfaces) we are trying to evolve TextureClient to be general (and good) enough to replace as many other surface classes as possible.

I would like to know to what extent it would make sense to unify GrallocImage and/or GraphicBufferLocked into a suitably evolved TextureClient.

Tentatively marking this as blocking bug 941399.

Comment 1

[Nicolas Silva [:nical]]

GrallocImage is a realization of the Image abstraction, so unless we decide to replace Image by MozSurface, it doesn't yet make much sense to replace GrallocImage by GrallocTextureClient. In the mean time, shared image types *must* be implemented on top of TextureClient (which is already the case for GrallocImage).

GraphicBufferLocked (as far as I understand it, which is not very far) is (at least partly) a mechanism to notify the GonkNativeWindow that a gralloc buffer can be reused. It may have other uses. Sotaro seemed to think that it is not the best abstraction for the job, but in any case I think it fulfills a different purpose that our usual "surface" abstractions.

Maybe this bug could about "Should we unify Image and MozSurface?", which seems to be a valid question. I think I would be in favor of unifying the two at some point.

Comment 2

[Sotaro Ikeda [:sotaro]]

(In reply to Nicolas Silva [:nical] from comment #1)
> 
> Maybe this bug could about "Should we unify Image and MozSurface?", which
> seems to be a valid question. I think I would be in favor of unifying the
> two at some point.

Yeah, I also think so. It seems too early to discuss about this. There is even no implementation of MozSurface.

Comment 3

[Benoit Jacob [:bjacob] (mostly away)]

Right, closing.