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

Re: [Public WebGL] WEBGL_dynamic_texture redux

On 2012/11/01 7:00, Kenneth Russell wrote:
Hi Mark,

Thanks for putting together this sample. A few thoughts.

  - Keeping the video stream separate from the video element seems cleaner. I think we should avoid APIs which require mutating HTML elements, and in particular, adding new properties.
Yes I agree. I was thinking it would be convenient to have the stream in the video object so the stream can be accessed whereever the video object is passed. But the application can easily add the object with the stream interface to the video object if it wants.

I'd like to hear from David Sheets as he was the person primarily pushing for the interface to be available on the producer elements and I'm not sure I understood completely what he was proposing.

  - When thinking about creating streams for arbitrary canvases, not just video elements, how will the producerFrame be handled? Today, when _javascript_ code modifies a 2D canvas, the results are made available (a) when the web page is composited, (b) when a readback API like toDataURL / getImageData is called, or (c) when WebGL uploads the canvas via texImage2D / texSubImage2D. It's a "pull" model. When a stream is connected, and the canvas is modified in the current _javascript_ callback, should acquireImage() cause a flush of the upstream canvas and an update of the producerFrame at the same time? I think it should. Is there any issue with spec'ing this behavior?
Doesn't the JS code modify the canvas as it runs? Isn't it just display or acquisition of the results that awaits a pull? Regardless I agree that acquireImage() is the place to pull the result. If nothing is drawn on the canvas until the pull request then acquireImage() may take some time.

Given the pull model, I wondered is there any point supporting HTMLCanvasElement? The browser can probably avoid a data copy when pulling the canvas via texImage2D especially if it is using GL for rendering the canvas2D. But supporting texSubImage2D requires having a copy of the data so yes I think there is a point to support canvas2D.

  - You point out that cpc won't update when the tab is backgrounded, but there are other issues: (a) the WebGL app might decide to not produce new frames sometimes (if the scene isn't updating); (b) msc won't update if the browser decides not to repaint because the page didn't update at all; (c) for backgrounded tabs it's unlikely that msc will update, and requestAnimationFrame will stop, but setTimeout based timers will still probably fire. Are there issues with any of these behaviors? I think probably not; applications will use the page visibility API to know when they've been backgrounded and suspend any measurements of frame rate.
I don't think there are any issues. Behavior just needs to be clearly specified then the application can suspend measurements and re-base initial counts as necessary.

My intention is that msc will be incremented on each screen refresh; in CRT terms that would be each vertical blanking interval. But perhaps that isn't necessary in the context of a web browser.

  - Should this spec reference http://dvcs.w3.org/hg/webperf/raw-file/tip/specs/HighResolutionTime/Overview.html for the high-resolution timestamps instead of defining another concept?
Excellent. I did not know about this. I would like to see them tighten up the accuracy requirement though. Currently it doesn't have to any more accurate than millisecond. I think it should be as I wrote in the sample:

    //   The average frequency at which the counter is

    //   updated should be 5x the highest MSC frequency supported. For
    //   example if highest MSC is 48kHz (audio) the update frequency
    //   should be 240kHz. Most OSes have this kind of counter available.

That's makes 1 tick about 4.17 microseconds. I think the web audio folks would appreciate this.

Also "thousandth of a millisecond" needs to be replaced with "microsecond".



注意:この電子メールには、株式会社エイチアイの機密情報が含まれている場合が有ります。正式なメール受信者では無い場合はメール複製、 再配信または情報の使用を固く禁じております。エラー、手違いでこのメールを受け取られましたら削除を行い配信者にご連絡をお願いいたし ます.

NOTE: This electronic mail message may contain confidential and privileged information from HI Corporation. If you are not the intended recipient, any disclosure, photocopying, distribution or use of the contents of the received information is prohibited. If you have received this e-mail in error, please notify the sender immediately and permanently delete this message and all related copies.