Last Comment Bug 653657 - Implement WebGL MOZ_window_region_texture extension
: Implement WebGL MOZ_window_region_texture extension
Status: RESOLVED WONTFIX
[tilt] webgl-extension
:
Product: Core
Classification: Components
Component: Canvas: WebGL (show other bugs)
: unspecified
: All All
: -- normal (vote)
: ---
Assigned To: Cedric Vivier [:cedricv]
:
: Milan Sreckovic [:milan]
Mentors:
Depends on: 653656
Blocks: 703910 710565
  Show dependency treegraph
 
Reported: 2011-04-28 22:43 PDT by Cedric Vivier [:cedricv]
Modified: 2013-10-30 16:25 PDT (History)
6 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments

Description Cedric Vivier [:cedricv] 2011-04-28 22:43:33 PDT

    
Comment 1 Rob Campbell [:rc] (:robcee) 2011-06-29 05:27:48 PDT
We're running out of time on getting this in for the final version of Tilt. Any progress to report?
Comment 2 Cedric Vivier [:cedricv] 2011-06-29 07:12:42 PDT
This is a placeholder for the native/optimized implementation of the extension, reusing underlying textures (or FBOs?) when possible.

First we need to all agree on a sane design for #653656, and it does not seem necessary for now as Tilt's framerate seems quite acceptable as it does not do interactive refresh yet afaik (the native implementation will be probably needed for interactive refresh rates - especially on pages using canvas or video heavily).

Additionally it might not make sense to implement this natively before Azure is ready, depending whether or not access to underlying gfx objects is going to significantly change. Benoit?
Comment 3 Benoit Jacob [:bjacob] (mostly away) 2011-06-29 07:31:56 PDT
(In reply to comment #2)
> This is a placeholder for the native/optimized implementation of the
> extension, reusing underlying textures (or FBOs?) when possible.

It's really textures, not FBOs, that you want to reuse here. This kind of texture sharing is already used all over the place for this kind of optimizations (avoiding readbacks).

When the DOM element that you want to access is its own layer, which is the case for a <img> or <video> or <canvas> element, you can get the texture from the Layer right away today. The hooks to get the textures are already in place.

When the element does not have its own layer and is painted into a larger layer, I'm not even sure what the wanted result is. Anyway, in that case that layer would be a ThebesLayer until Azure changes that name which afaik isn't happening soon. If the DOM element has a well-defined location within the layer, maybe the layers API allows you to query it, I don't know.

> Additionally it might not make sense to implement this natively before Azure
> is ready, depending whether or not access to underlying gfx objects is going
> to significantly change. Benoit?

Azure should not really affect you since it's only an API for drawing stuff into layers, and you're only concerned with stuff that's already drawn in layers. You come into play after Azure has left the game. It could be that ThebesLayer gets changed/renamed at some point as Azure takes over, I don't know. For now, even on central in gfx/layers/d3d10 there is only a ThebesLayerD3D10, nothing there about Azure.
Comment 4 Cedric Vivier [:cedricv] 2011-06-29 08:10:52 PDT
Thanks Benoit. I've posted more thoughts in #653656.
Comment 5 Jeff Gilbert [:jgilbert] 2013-10-30 16:25:03 PDT
Inheriting WONTFIX from discussion in bug 653656.

Note You need to log in before you can comment on or make changes to this bug.