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

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



For reference, the 2D Canvas API says about drawImage:

"If the image argument is an HTMLImageElement object that is not fully
decodable, or if the image argument is an HTMLVideoElement object
whose readyState attribute is either HAVE_NOTHING or HAVE_METADATA,
then the implementation must return without drawing anything."

http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#drawing-images-to-the-canvas

For symmetry, that would argue to make both texImage2D and
texSubImage2D be no-ops if passed incomplete images or video elements.

Note that the current unspecified behavior of generating an
INVALID_OPERATION error already does this.

If we get rid of this error and simply log a warning to the console,
are we improving the situation for developers? Or are we removing the
only avenue by which they can tell via the API that something is flaky
in their application?

-Ken


On Wed, Oct 31, 2012 at 6:49 PM, Brandon Jones <bajones@google.com> wrote:
> I agree with Colin as well, no matter what we do we should work on making
> sure the developer understands the results they are getting.
>
> Unfortunately if you do that via a console.log you may spam the console with
> warnings about intended behavior in the case of Gregg's no-op video playlist
> example.
>
> On Oct 31, 2012 5:41 PM, "Gregg Tavares (社用)" <gman@google.com> wrote:
>>
>>
>>
>>
>> On Wed, Oct 31, 2012 at 5:03 PM, Brandon Jones <bajones@google.com> wrote:
>>>
>>> On Wed, Oct 31, 2012 at 4:44 PM, Gregg Tavares (社用) <gman@google.com>
>>> wrote:
>>>>
>>>> Is that more developer friendly? It means if you want to show the same
>>>> frame between videos you have to do extra work.
>>>
>>>
>>> I'm a little unclear on what you're referring to here. I assume you mean
>>> "show the last frame from a previous video in a playlist while a the next
>>> video is loading?" I can see how that may be a nice side effect, but it also
>>> feels a bit hacky. If I want my video player to nicely transition from one
>>> video to the next I have all the events at my disposal to monitor that and
>>> do the Right Thing.
>>
>>
>> Sorry, I'm assuming you don't have all the events. That you are not
>> running the entire thing yourself. That some site like youtube, vimeo or G+
>> hangouts provides a javascript API that gives you video tag controlled by
>> their Javascript and that you're trying incorporate it into some WebGL app
>> and it may or may not give you all the events you need to know every detail.
>>
>> I'm also assuming that even if you write it yourself, most developers
>> would prefer to show the last frame of a video than black.
>>
>>
>> var cue = 0;
>> var playlist = [
>>   "video1.mp4",
>>   "video2.mp4",
>>   "video3.mp4",
>>   "video4.mp4",
>> ];
>>
>> video.addEventListener('ended', cueNextVideo);
>>
>> function cueNextVideo() {
>>   if (cue >= playlist.length) {
>>     return;
>>   }
>>   video.src = playlist[cue++];
>>   video.play();
>> }
>>
>> function render() {
>>     gl.texImage2D(...., video);
>>     gl.drawXXX(...);
>>     requestAnimationFrame(render);
>> }
>>
>> cueNextVideo();
>> render();
>>
>> That seems developer friendly to me. It just works. (assumes my fiction
>> that developers would prefer the last frame between videos ;-p)
>>
>> Here's what I guess the alternative is
>>
>>
>> var cue = 0;
>> var playlist = [
>>   "video1.mp4",
>>   "video2.mp4",
>>   "video3.mp4",
>>   "video4.mp4",
>> ];
>> var update = false;
>>
>> video.addEventListener('ended', cueNextVideo);
>> video.addEventListener('playing', function() {
>>   update = true;
>> });
>>
>> function cueNextVideo() {
>>   if (cue >= playlist.length) {
>>     return;
>>   }
>>   update = false;
>>   video.src = playlist[cue++];
>>   video.play();
>> }
>>
>> function render() {
>>     if (update) {
>>       gl.texImage2D(...., video);
>>     }
>>     gl.drawXXX(...);
>>     requestAnimationFrame(render);
>> }
>>
>> cueNextVideo();
>> render();
>>
>> Not that burdensome either.  I feel strongly that texSubImage2D should be
>> a no-op if nothing is available. For texImage2D it seems like it should be a
>> no-op or a 0x0 texture. Not 1x1. My preference is no-op but I don't feel
>> that strongly.
>>
>> I agree with Colin, a console warning might would be useful either way.
>> Although it could also get in the way of legit apps. Especially if we decide
>> to allow progressive loading.
>>
>>
>

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