863540 - [layers-refactoring] What to do about the B2G-specific "image" classes sitting in gfx/layers/ ?

Status: RESOLVED WONTFIX

(Core :: Graphics, defect)

Description

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

Continuing the epic enterprise of making B2G gfx code tractable and maybe even clean... We have a few files in gfx/layers/ that introduce B2G-specific image/surface types. Questions:
 - What are they used for?
 - Is there a better place for them to fit in the new-layers code?
 - If not, what can we do to avoid having platform-specific custom image classes at the root level of gfx/layers/ ?

hg.mozilla.org/mozilla-central/file/tip/gfx/layers/GonkIOSurfaceImage.cpp
hg.mozilla.org/mozilla-central/file/tip/gfx/layers/GonkIOSurfaceImage.h
hg.mozilla.org/mozilla-central/file/tip/gfx/layers/GrallocImages.cpp
hg.mozilla.org/mozilla-central/file/tip/gfx/layers/GrallocImages.h

Comment 1

[Nicolas Silva [:nical]]

I wonder if we could have a MemoryBuffer interface with the minimum apis (Lock/Unlock,GetPtr,AddRef,Release) for it to cover regular ram, shmem and gralloc. And then we'd have more classes use this abstraction rather than specific memory.

It would probably be a bit of a hassle to be forced to lock/unlock even when not using gralloc, but on the other hand we could reduce the number of classes quite a bit I think (we would also not need separate classes for SharedPlanarYCbCrImage and PlanarYCbCrImage for instance). And we already need to support lock/unlock for b2g so it would make it easier if all our logic supports locking.

we could even add a "SupportsDirectTexturing()" method and "AsTextureSource()" to make it even more transparent to upload textures efficiently.

heck, I would even use that for the new TextureClient/Host model (which needs lock/unlock).

Comment 2

[Nicolas Silva [:nical]]

After discussion with Bas and bjacob, we reached the conclusion that usage of gralloc should only happen within TextureCLient/TextureHost, so we probably don't need a MemoryBuffer abstraction that would only be used in TextureClient/Host.

This refers to TextureClient/Host as they will be after bug 858914.

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

Is MozSurface meant to deal with some of these issues?

Comment 4

[Nicolas Silva [:nical]]

(In reply to Milan Sreckovic [:milan] from comment #3)
> Is MozSurface meant to deal with some of these issues?

MozSurface will bring a nicer API to get rid of gonk specific image classes (whilst not adding any feature that we don't already have with TextureClient to fix that particular problem).

Comment 5

[Sylvestre Ledru [:Sylvestre]]

Mass closing as we are no longer working on b2g/firefox os.

Comment 6

[Sylvestre Ledru [:Sylvestre]]

Mass closing as we are no longer working on b2g/firefox os.