Once we support sharing textures between the compositor and WebGL, it should be relatively simple to extend that sharing to support gralloc for b2g (he said, waving his hands).

WebGL stuff is already on the GPU side of things. How does gralloc help us?

We can't do fast cross-process webgl without gralloc. (Until we do GL proxying, anyway.)

(In reply to Chris Jones [:cjones] [:warhammer] from comment #2) > We can't do fast cross-process webgl without gralloc. (Until we do GL > proxying, anyway.) Why not?

How do you propose sharing the WebGL render target across processes?

Right, sorry. The extension I was thinking of doesn't exist yet. I'm doing a refactoring of these backends. Are there any documents on how to create a PBuffer, GL texture, or GL renderbuffer backed by gralloc?

The android source code! ;) Not my area of expertise though. You can get an EGLImage out of gralloc buffers, if that helps.

(In reply to Jeff Gilbert [:jgilbert] from comment #5) > Right, sorry. The extension I was thinking of doesn't exist yet. > I'm doing a refactoring of these backends. Are there any documents on how to > create a PBuffer, GL texture, or GL renderbuffer backed by gralloc? There's no documentation, but you can create an EGLImage from gralloc buffers, render into those, and then bind them as a texture on the other side. That *should* work across processes.

the patch add support of gralloc-backed WebGL rendering. I confirm the rendering on my hardware(MSM8960). it has some problems need to address, but it could be a start.

This seems much more complicated than is needed for gralloc-based OMTC/inter-process pass-through. It would seem to me that all we need is the (Content) CanvasLayer, when supplied with a gralloc buffer from the Compositor, is to build an EGLImage backed by the gralloc buffer, and copy from the GLContext backing surface to the gralloc EGLImage. (Similar to bug 728524)

I have often read in many places about "performance is very important in b2g". Then, I created attachment 643291 [details] [diff] [review]. In bug 728524, fCopyTexSubImage2D() is used to copy data, it could affect to the performance. If we want to do cross-process webgl, multiple gralloc-ed buffers are necessary. From my understanding about android, there is no simple way to do multiple gralloc-buffered OpenGL rendering. Therefore data copy to gralloc-ed buffers becomes necessary. But in android(gonk), ANativeWindow and eglWindowSurface provide this capability. They could provide multiple gralloc-buffered GL context. By using them, we do not need to call data-copy to gralloc-ed buffers. IMHO, if we want to get best performance in cross-process webgl in b2g, we need to use ANativeWindow and eglWindowSurface. But their implementation provide complexities...

Performance is certainly important, but when performance impact is relatively negligable, it's preferable to go with the simpler solution. In the simple general cross-thread/process approach, double-buffering is sufficient. (for now) The way we do this for cross-threads is by copying from our GLContext's backing surface into the EGLImage, which writes to the compositor's surface directly. Currently, we use CopyTexSubImage, since we are concerned about the massive state save-restore required for drawing the texture to an EGLImage-backed framebuffer. (Even though drawing a textured quad appears to be faster than CopyTexSubImage, in general) My understanding is that it should be simple to gralloc a buffer and attach it to an EGLImage-backed texture, and likewise content-side, attach an EGLImage to that same gralloc buffer, and just copy into it. This would seem relatively simple, and would get use the vast majority of the performance we need. An 'easy' to use abstraction which does proper triple-buffering (when needed) is coming soon, but should only be a marginal win over our method here. (for any non-trivial webgl apps)

I agree, when performance impact is relatively negligable, we should use simpler solution.

How are we doing here?

The prereq work in bug 716859 is about ready to go up for review. This will be a 200 line patch on top of that.

Renom if you think we can't ship a v1 without this.

Per IRC conversations with a few other folks, I think the best course of action if there is disagreement on whether this blocks or not is to do the following: - Move the blocking-basecamp flag to ? for re-evaluation - Indicate a rationale for why you disagree

From Bug 917444 and Bug 894847, I am going to rethink about this again.

This is a wip patch. Confirmed that the patch works on master hamachi.

By applying the patch, crystalskull draws about 33 fps both HWComposer composition and OpenGL composition on master hamachi.

(In reply to Sotaro Ikeda [:sotaro] from comment #18) > Created attachment 819267 [details] [diff] [review] > WIP patch - Support ANativeWindow backed EGLSurface attachment 819267 [details] [diff] [review] does not handle correctly the following case, a dead lock happen in GonkNativeWindowClient. - app go to background and go to foreground again.

attachment 819267 [details] [diff] [review] is [3]'s wip patch. Updated the patch for current master.

The following is a fps of crystalskull on master hamachi. Compare the fps of HwComposer composition and OpenGL composition. [3] got good fps on the both cases. [1] - HwComposer : 32-33fps - OpenGL: 0fps(< 1 fps), a lot of frame drops? [2] - HwComposer : 30-33fps - OpenGL:25-26fps [3] - HwComposer : 32-33fps - OpenGL : 32-33fps

Sorry, [1], [2], [3] is the following. [1] Do nothing about frame complete(current behavior) [2] Ensure frame complete by reading one pixcel [3] ANativeWindow backed EGLSurface

(In reply to Sotaro Ikeda [:sotaro] from comment #21) > attachment 819267 [details] [diff] [review] is [3]'s wip patch. Updated the > patch for current master. It does not work on SkiaGL backed 2D canvas.

We just recently did cleanup in bug 814159... which remove backing surface and X-backed GL Context. Can we expose some interface which would allow to build EGLSurface backed with X window, NativeSurface, or something else, instead ifdef-ing half of GLContext implementation?

attachment 819267 [details] [diff] [review] is just a prototype to show ANativwWindow backed EGLSurface working on b2g. I created a patch for next week's graphics work week in Paris. If I could get good feed back about it there, I am going to implement it more clean way. Comment 25 is also a good input.

(In reply to Oleg Romashin (:romaxa) from comment #25) > Can we expose some interface which would allow to build EGLSurface backed > with X window, NativeSurface, or something else, instead ifdef-ing half of > GLContext implementation? Sounds reasonable!

By the discussion in graphics work week in Paris, feed backs to the idea of using ANativeWindow backed EGLSurface were positive.

Why not make GLSreenBuffer to inherit EGLNativeBase directly? use SurfaceTexture and SurfaceTextureClient introduce BinderIPC when deQ/Q. And why not update CreateConfig to enable EGL_SWAP_BEHAVIOUR_PRESERVED_BIT if needed, which is the default for 2D canvas.

And why not update fBindFramebuffer implementation? The FBO under GLScreenBuffer should be removed now, and fbo 0 means EGLSurface now.

Instead native_window_set_buffers_geometry, why not mWindowClient->perform?

(In reply to Chiajung Hung [:chiajung] from comment #29) > Why not make GLSreenBuffer to inherit EGLNativeBase directly? use > SurfaceTexture and SurfaceTextureClient introduce BinderIPC when deQ/Q. It does not use Binder IPC. enqueue/dequeue happens between GonkNativeWindowClient and GonkNativeWindow. It is just simple callback.

Intent of it's implementation is to run OpenGL as same as android one.

My inital attemp to implement this is to make GLScreenBuffer inherit EGLNativeBase and hook dequeue to SwapConsumer, queue to SwapProducer. which runs same as Android as well but code path simpler and avoid to depend on android::SurfaceTexture at all.

Change to 1.3? again. Right now, there is not urgent necessity to uplift to 1.2.

Bug 925444 requires proper handling of fence syncs which were introduced in Jellybean. In AOSP fence syncs are handled as a feature of SurfaceTexture [1] and GLConsumer [2]. Sotaro believes this can be addressed in this bug. If that is the case then this bug need to be blocking 1.3. [1] https://www.codeaurora.org/cgit/quic/la/platform/frameworks/base/tree/core/jni/android/graphics/SurfaceTexture.cpp?h=jb_3.2#n79 [2] https://www.codeaurora.org/cgit/quic/la/platform/frameworks/native/tree/include/gui/GLConsumer.h?h=b2g_jb_3.2#n68

Sotaro, is this still on target to get resolved for 1.3 FC, if so what is the eta of resolution here ? Given the activity not sue what the next steps are, can you please help outline them with progress ?

I don't think this is blocking or needs to be tracked for 1.3.

(In reply to bhavana bajaj [:bajaj] (on vacation until 12/02/2013) from comment #37) > Sotaro, is this still on target to get resolved for 1.3 FC, if so what is > the eta of resolution here ? Given the activity not sue what the next steps > are, can you please help outline them with progress ? From Comment 37, this bug is not resolved for 1.3 FC. Next step is to update a patch for not to use a lot of ifdef. To to it, need some re-structure around SurfaceStream.

(In reply to Sotaro Ikeda [:sotaro] from comment #39) > (In reply to bhavana bajaj [:bajaj] (on vacation until 12/02/2013) from > comment #37) > > Sotaro, is this still on target to get resolved for 1.3 FC, if so what is > > the eta of resolution here ? Given the activity not sue what the next steps > > are, can you please help outline them with progress ? > > From Comment 37, this bug is not resolved for 1.3 FC. Next step is to update > a patch for not to use a lot of ifdef. To to it, need some re-structure > around SurfaceStream. mvines - Can we remove this from the FxOS v1.3 FC blocking list?

Ah, it was there only because it blocked bug 925444 but that is no longer the case

By Bug 917444, WebGL performance was degraded on b2g. This bug could could solve the performance problem.

I change my mind. Bug 1001417 seems better way to enhance WebGL on b2g.

milan, how do you think about Comment 43? I changed the "blocking-b2g:" flag to "2.0?".

I definitely like the approach in bug 1001417.

bug 1001417 is a way to go. Set this bus to INCOMPLETE.

Reopen this bug. I am going to compere performance to Bug 1001417.

Patch for gonk JB.

This bug's way is faster than bug 1001417. But attachment 8428449 [details] [diff] [review] seems to have some problems. Some rendering objects are not rendered(missing).

I recognized that I forgot to add release fence handling correctly.

Add ICS support.

Add release fence handling. Still some specific items are not drawn. I am going to think that GLContextEGLGonkNativeWindow is missing some correct function overwrites.

At first fps is very high. But after that some how fps becomes lower.

(In reply to Sotaro Ikeda [:sotaro] from comment #54) > At first fps is very high. But after that some how fps becomes lower. This performance drop is not always happen. This problem might not be related to graphics.

(In reply to Sotaro Ikeda [:sotaro] from comment #53) > Created attachment 8428948 [details] [diff] [review] > WIP patch - Support ANativeWindow backed EGLSurface > > Add release fence handling. Still some specific items are not drawn. I am > going to think that GLContextEGLGonkNativeWindow is missing some correct > function overwrites. It became clear that the problem happened because z-buffer was missing.

Fix rendering problem. Still the patch break video playback.

(In reply to Sotaro Ikeda [:sotaro] from comment #57) > Created attachment 8429549 [details] [diff] [review] > WIP patch - Support ANativeWindow backed EGLSurface > > Fix rendering problem. Still the patch break video playback. The patch is based on Bug 1001417.

Fix crash problem in Youtue site.

Add KK support.

Add missing files.

Update EGLSurface configuration.

Add acquire fence handling to GonkNativeWindow.

Add "webgl.eglsurface.gonk-native-window" preference.

Update EGL config creation.

At first, I thought that it seems necessary to handle SurfaceStream's frame copy. But it seem to be used only 2DCanvas not on WebGL. CanvasClientSurfaceStream::Update(gfx::IntSize aSize, ClientCanvasLayer* aLayer) { // snip if (aLayer->mStream) { stream = aLayer->mStream; // Copy our current surface to the current producer surface in our stream, then // call SwapProducer to make a new buffer ready. stream->CopySurfaceToProducer(aLayer->mTextureSurface, aLayer->mFactory); stream->SwapProducer(aLayer->mFactory, gfx::IntSize(aSize.width, aSize.height)); } http://mxr.mozilla.org/mozilla-central/source/gfx/layers/client/CanvasClient.cpp

Fix build failures on other platforms.

Change ISurfaceAllocator's MessageLoop.

https://tbpl.mozilla.org/?tree=Try&rev=0db4d4a34dc5 On tryserver, some tests are failed.

un-bitrot.

Un-bitrot.

SurfaceStream's performance becomes almost same to this bug's patch. In this case, just use SurfaceStream is a good idea.