Another idea which came up during offline conversations: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.
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.
If the image argument is an HTMLImageElement object that is not fully decodable,
When an img element is in the completely available state and the user agent can decode the media data without errors, then the img element is said to be fully decodable.
The user agent has obtained all of the image data and at least the image dimensions are available.
-Ken