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

[Public WebGL] Progressive loading



Some WebGL applications suffer from delays in inlitialization due to several reasons: texture downloads, shader compiling, mesh data downloads.

Applications with many and/or very large textures have to way for them to be fully downloaded before they can be loaded into WebGL. Usually their onload event is used. Before that textures are "black". It would be beneficial to support progressive texture loading so that the user does not see a frozen scene but sees some progress going on.

If one tries to do texImage2D before the "onload" event has triggered, there is no data to load (a null image is passed), even if part of the image has already been received. Why not provide the partial image here? (leaving black pixels where no data has arrived). Images in the HTML page (regular <img>) do display progressively.

This would be especially useful with progressive JPEG or progressive PNG that provide a full low-quality version of the image with just a little fraction of the complete image data.


For shader compile times we have been discussing issues and solutions in other threads. It's true that compiling currently freezes the browser. I don't know if it could be done in a WebWorker.

And for mesh data solutions are being developed in several places using binary streams that either load directly into typed arrays, or which can be parsed in _javascript_ (mozArray*, DataView, ...). I have not seen progressive mesh download so far (the closest might be the XB PointStream).

Best regards,





El 12/04/2011 10:45, Vladimir Vukicevic escribiÃ:

It's a bit roundabout, but you can:

- Load the image as an image
- Draw it into an offscreen 2D <canvas> of the same size
- Use getImageData
- Use the returned ImageData's data buffer with buffer[Sub]Data

Requires an extra step with the canvas drawing (and associated extra memory usage), but should be possible.

    - Vlad

----- Original Message -----
It currently doesn't appear possible to load a WebGLBuffer from an
image, to use an image as vertex data. I can't do this manually, by
writing the image to a 2d Canvas and passing its ImageData to
bufferData, due to same-origin restrictions.

WebGLBuffer's bufferData and bufferSubData APIs should support similar
entry points as WebGLTexture.texImage2D, accepting HTMLImageElement,
HTMLCanvasElement and HTMLVideoElement, for the same reasons:
performance and dealing with same-origin restrictions. Of course,
this would affect the origin-clean flag, just as with WebGLTexture.

It would also be consistent to allow reading WebGLTextures into
WebGLBuffer--another operation you can do natively--though its
usefulness is limited by the present lack of floating-point texture
support.

-- Glenn Maynard
----------------------------------------------------------- You are
currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------
-----------------------------------------------------------
You are currently subscribed to public_webgl@khronos.org.
To unsubscribe, send an email to majordomo@khronos.org with
the following command in the body of your email:
unsubscribe public_webgl
-----------------------------------------------------------


--
ÃlvaroÂSeguraÂLasa
InvestigadorÂ/ Researcher
SistemasÂdeÂtransporteÂinteligentesÂeÂIngenierÃaÂ/ IntelligentÂTransportÂSystemsÂandÂEngineering
asegura@vicomtech.org
MikeletegiÂPasealekua,Â57
ParqueÂTecnolÃgicoÂ20009
DonostiaÂ-ÂSanÂSebastiÃn
Spain
Tel:Â +[34]Â943Â30Â92Â30
Fax:Â +[34]Â943Â30Â93Â93
www.vicomtech.org

Este mensaje se dirige exclusivamente a su destinatario. La informaciÃn incluida en el presente correo es confidencial sometida a secreto profesional, especialmente en lo que respecta a los datos de carÃcter personal, cuya divulgaciÃn està prohibida, en virtud de la legislaciÃn vigente. Si usted no es el destinatario legÃtimo y lo ha recibido por error o tiene conocimiento del mismo por cualquier motivo, le rogamos que nos lo comunique por este medio y proceda a destruirlo o borrarlo. En todo caso abstÃngase de utilizar, reproducir, alterar, archivar o comunicar a terceros el presente mensaje asà como los ficheros anexos, todo ello bajo pena de incurrir en responsabilidades legales. Cualquier opiniÃn contenida en este correo es exclusiva de su autor y no representa necesariamente la opiniÃn de ASOCIACIÃN CENTRO DE TECNOLOGÃAS DE INTERACCIÃN VISUAL Y COMUNICACIONES VICOMTECH (en adelante Vicomtech-IK4) El emisor no garantiza la integridad, rapidez o seguridad del presente correo, ni se responsabiliza de posibles perjuicios derivados de la captura, incorporaciones de virus o cualesquiera otras manipulaciones efectuadas por terceros. Con motivo de la entrada en vigor de la Ley 34/2002, de 11 de julio, de Servicios de la Sociedad de la InformaciÃn y de Comercio ElectrÃnico, le informamos que pueden revocar en cualquier momento, de forma sencilla y gratuita, el consentimiento para la recepciÃn de mensajes de vicomtech.org en info.lopd@vicomtech.org.