<html>
    <head>
      <base href="https://bugs.webkit.org/">
    </head>
    <body>
      <p>
        <div>
            <b><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - ImageBitmap has poor performance on iOS"
   href="https://bugs.webkit.org/show_bug.cgi?id=234920#c5">Comment # 5</a>
              on <a class="bz_bug_link 
          bz_status_NEW "
   title="NEW - ImageBitmap has poor performance on iOS"
   href="https://bugs.webkit.org/show_bug.cgi?id=234920">bug 234920</a>
              from <span class="vcard"><a class="email" href="mailto:kkinnunen@apple.com" title="Kimmo Kinnunen <kkinnunen@apple.com>"> <span class="fn">Kimmo Kinnunen</span></a>
</span></b>
        <pre>ImageBitmap seems the correct abstraction for this use-case, but the use-case does not seem to make sense to me just based on this explanation. 

Currently in WebKit ImageBitmap is not implemented to be an optimisation across multiple Context2D and WebGL elements.

Technically, currently, each texImage2D causes the ImageBitmap to be copied multiple times and then sent across the IPC. This is mainly due to Context2D and ImageBitmap existing in GPU process while WebGL is in WebContent process. Additionally "texImage2D" doesn't establish a handle for the converted temporary object that would naturally be simple to use to persist the temporary (converted and shared bitmap data).

It does sound that quite a lot of problems come from the fact that you want to support arbitrary amount of WebGL contexts. This is probably not very good, as it uses excessive amounts of memory. E.g. in your example, you are uploading the same video to multiple textures for no real reason other than webgl restrictions.

Most use-cases can be organised around having one global WebGL and mostly use the WebGL frame buffer for displaying the drawing. For sharing images of WebGL rendering to multiple viewports, currently the best option is to draw the image to the frame buffer and then draw the webgl element to the multiple Context2Ds. It will not perform terribly well.

<span class="quote">>Goal... the current frame of a video element into an object that can then be efficiently used in other canvas contexts (multiple WebGL contexts for example)</span >

Everything of course should be optimal but in practice not everything will be made optimal. It would be useful to understand what is the source of the requirement. 

Without more info, I'd imagine the above is not a source requirement? It is counterintuitive that you'd want to upload, for example, 4k bitmap 2,3 or 87 times to different textures efficiently. The textures would just duplicate the bitmap pointlessly.

To me it sounds that probably what you want in the end is a "shared WebGL context" feature that can show webgl images from one context in multiple places? I.e. a feature where the video can be uploaded once to a texture but be used in rendering pictures of multiple canvases. I.e. 1 context, n canvases.</pre>
        </div>
      </p>


      <hr>
      <span>You are receiving this mail because:</span>

      <ul>
          <li>You are the assignee for the bug.</li>
      </ul>
    </body>
</html>