[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Public WebGL] WebGL API request: asynchronous texture uploads



Thanks all for the fast and informed responses.

Consider this request closed. But I am looking forward to support for WebGL and Canvas in WebWorkers :)

A bit of background info, to explain "slow":
- Map and globe applications, like Google Maps, have more-or-less standardized on 256x256 pixel image tiles
- A low-resolution screen is 1024x768 pixels
- This requires 5x4 = 20 image tiles (5x4 rather than 4x3 because 4x3 only applies if your screen is perfectly aligned on tile boundaries)
- So, when the user clicks zoom, you need to upload 20 textures
- If it takes 1ms second per texture (and the Chrome developers have witnessed 2-5ms per texture on mobile) then you completely blow your frame budget

Right now, I'm getting better performance from using Canvas 2D than I'm getting from WebGL. This is annoying, because WebGL is lower level and should be able to do better. Texture uploads are a key source of jank, even though we limit texture uploads to one per second. Try the following demos:

WebGL: http://ol3js.org/ol3/master/examples/full-screen-drag-rotate-and-zoom.html?renderer=webgl
Canvas: http://ol3js.org/ol3/master/examples/full-screen-drag-rotate-and-zoom.html?renderer=canvas

WebGL of course offers a lot more, but it would be nice to at least match Canvas 2D performance :)

Thanks again - will wait for WebGL support in WebWorkers, because this is certainly a better long solution in the long term.
Tom


On 25 April 2013 20:29, Kenneth Russell <kbr@google.com> wrote:
Agreed -- the best solution is to support real multithreading in
WebGL. We should push forward integrating sharing and Canvas in
workers, and not get distracted adding async APIs for every expensive
WebGL operation.

-Ken



On Thu, Apr 25, 2013 at 9:33 AM, Gregg Tavares <gman@google.com> wrote:
> Rather than making 50 async APIs the solution to asynchronous features in
> WebGL is allowing WebGL in web workers.
>
> http://www.khronos.org/webgl/wiki/SharedResouces
>
> http://wiki.whatwg.org/wiki/CanvasInWorkers
>
> Which are being actively worked on.
>
>
>
> On Thu, Apr 25, 2013 at 3:44 AM, Tom Payne <tom.payne@camptocamp.com> wrote:
>>
>> Texture uploads are slow on mobile devices [1], and have unpredictable
>> performance, and it's hard to avoid jank. Applications that stream textures
>> on demand, like map and virtual globe applications, are particularly
>> sensitive to this.
>>
>> Can the WebGL API be extended to allow asynchronous texture uploads?
>>
>> Something like:
>>
>>   var texture = gl.createTexture();
>>   gl.bindTexture(gl.TEXTURE_2D, texture);
>>   gl.texImage2DAsync(
>>     gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, image,
>>     function() {
>>       // texture now uploaded, do something
>>     });
>>   // gl.texImage2DAsync also implicitly unbinds the texture
>>
>> This might lead to the second advantage of eventually allowing the browser
>> to JPEG/PNG decode the image in a separate, low-priority, thread.
>>
>> Does this make sense?
>>
>> Many thanks,
>> Tom
>>
>>
>> [1] http://www.chromium.org/developers/design-documents/impl-side-painting
>> section "Texture Upload"
>>
>>
>>
>> --
>> Camptocamp SA
>> Tom PAYNE
>> PSE A
>> CH-1015 Lausanne
>>
>> +41 21 619 10 13 (direct)
>> +41 21 619 10 10 (centrale)
>> +41 21 619 10 00 (fax)
>
>



--
Camptocamp SA
Tom PAYNE
PSE A
CH-1015 Lausanne

+41 21 619 10 13 (direct)
+41 21 619 10 10 (centrale)
+41 21 619 10 00 (fax)