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

Re: [Public WebGL] texImage2D on unfinished images and video



On Thu, Nov 1, 2012 at 9:05 AM, Chris Marrin <cmarrin@apple.com> wrote:
>
> On Oct 31, 2012, at 3:15 PM, Kenneth Russell <kbr@google.com> wrote:
>
>>
>>>
>>> Also, while an unloaded video/image could return 1x1, off the top of my
>>> head, what it returns while changing resolutions or queuing the next video
>>> could be implementation defined. Some browsers might return 1x1 while
>>> switching. Others might return the last valid frame until such time as a
>>> frame from the new source is ready. As long as there is no error that seems
>>> better to me.
>>
>> It seems that the consensus is to change the WebGL specification as you suggest.
>>
>> The changes would essentially be:
>>
>>  - If an incomplete HTMLImageElement or HTMLVideoElement is passed to
>> either texImage2D or texSubImage2D, then the source is treated as a
>> 1x1 texture containing the RGBA value (0, 0, 0, 1). This means that
>> texImage2D will cause the level of the passed texture object to be
>> redefined as size 1x1; texSubImage2D will upload a single black pixel
>> at the given xoffset and yoffset. It would be defined that an OpenGL
>> error would never occur as a result of these calls.
>>
>> Are there any objections to these changes? If not, I'll update the spec.
>
> It would be really nice if we could handle incremental image downloads. To do this, we'd need some way to know "enough of the image is downloaded that it's size is accurate and it has something (perhaps low res) to display", folllowed by "more of the image is available" events and then an "image complete" event.
>
> Maybe that's a separate issue, but it would be a really useful thing to support.

Another idea which came up during offline conversations:

It would be a backward-compatible change (from applications' point of
view) to change the return type of the texImage2D and texSubImage2D
overloads taking HTMLImageElement and HTMLVideoElement (and, I
suppose, HTMLCanvasElement) to return some sort of status code. We
could indicate whether the element was fully uploaded, whether it was
only partially uploaded due to progressive downloads, whether there
wasn't enough information to do any data uploading, etc.

That way, applications could still determine what had happened
programmatically, without querying for any OpenGL errors.

-Ken

-----------------------------------------------------------
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
-----------------------------------------------------------