From cal...@ Tue Apr 2 02:08:35 2013 From: cal...@ (Mark Callow) Date: Tue, 02 Apr 2013 18:08:35 +0900 Subject: [Public WebGL] video/tv production issues In-Reply-To: References: Message-ID: <515AA013.8080808@artspark.co.jp> On 2013/03/12 20:06, Florian B?sch wrote: > I'm getting some interest in the video/television industry to the > effect of using WebGL. > I have a related question. Do any of the video formats used on the web support an alpha channel? I want to do shaped video. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Tue Apr 2 02:09:44 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 2 Apr 2013 11:09:44 +0200 Subject: [Public WebGL] video/tv production issues In-Reply-To: <515AA013.8080808@artspark.co.jp> References: <515AA013.8080808@artspark.co.jp> Message-ID: As far as I know none include alpha channel support. What you'd usually do is chroma keying. On Tue, Apr 2, 2013 at 11:08 AM, Mark Callow wrote: > On 2013/03/12 20:06, Florian B?sch wrote: > > I'm getting some interest in the video/television industry to the effect > of using WebGL. > > I have a related question. > > Do any of the video formats used on the web support an alpha channel? I > want to do shaped video. > > Regards > > -Mark > -- > ???????????????????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????? ??. > > 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. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Tue Apr 2 02:58:30 2013 From: cal...@ (Mark Callow) Date: Tue, 02 Apr 2013 18:58:30 +0900 Subject: [Public WebGL] video/tv production issues In-Reply-To: References: <515AA013.8080808@artspark.co.jp> Message-ID: <515AABC6.8060409@artspark.co.jp> On 2013/04/02 18:09, Florian B?sch wrote: > As far as I know none include alpha channel support. What you'd > usually do is chroma keying. > > > On Tue, Apr 2, 2013 at 11:08 AM, Mark Callow > > wrote: > > > Do any of the video formats used on the web support an alpha > channel? I want to do > That's a shame. MPEG-4 has supported shape coding and alpha for, in web terms, eternity. Don't any browsers support MPEG-4? Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Tue Apr 2 12:30:22 2013 From: jgi...@ (Jeff Gilbert) Date: Tue, 2 Apr 2013 12:30:22 -0700 (PDT) Subject: [Public WebGL] video/tv production issues In-Reply-To: Message-ID: <1838516869.1699986.1364931022808.JavaMail.root@mozilla.com> For getting textures from videos, I don't think you need the dynamic texture extension, though it could help some. All you should need is for the browsers to pull the most recently decoded frame from the GPU. This is an optimization which I believe Chrome is working on, but Firefox is still getting around to. -Jeff ----- Original Message ----- From: "Florian B?sch" To: "public webgl" Sent: Tuesday, March 12, 2013 4:06:49 AM Subject: [Public WebGL] video/tv production issues I'm getting some interest in the video/television industry to the effect of using WebGL. For realtime production a typical setup would grab video frames off a monitors output at the monitors refresh frequency. Often the signal is converted then to interlaced formats and the like. There are some difficulties in such a setup. Frame Tearing 1) When the page is being composited out of sync with the WebGL drawing 2) When the page is being composited out of sync with the monitors refresh frequency I think (though I'm not entirely sure) that the first source of frame tearing is being addressed with canvas double buffering and improvements in requestAnimationFrame (correct me if I'm wrong). As far as I'm aware the second source of frame tearing isn't being addressed right now (the browsers recompositing isn't synced to the monitors refresh frequency). Is the above an accurate description of the issue, and is there being any effort yet to solve it? Framerate Browsers implement a maximum framerate at which the WebGL canvas can be shown (the frequency at which they recomposit). This is usually capped at 60hz. For realtime video production it is desirable to exactly match the outputs refresh rate. For instance for these usecases: * To render time interspersed stereographic video (usually each frame contains a marker). So for instance for say 60hz stereoscopic video, a framerate of 120hz would be required. * To provide output intended for interlaced composition * To avoid frame tearing Would it be possible to have the browser match the outputs refresh exactly? Antialiasing Currently WebGL does not allow for fine grained control over antialiasing. Mostly one gets 4x4 MSAA (and sometimes no AA like on OSX). There are a number of advanced AA options presented by GPU drivers (such as nvidias TXAA) that deliver fully hardware accelerated movie-like antialiasing at a fraction of the cost of brutal supersampling. Would it be possible to get finer grained control over AA? Video production workstation video input textures Some of the GPUs used in these environments support direct video input -> texture (they usually sport multiple external video in ports). As far as I could ascertain this capability is exposed via proprietary extensions of the drivers of these GPUs. Would there be any possibility to gain access to these extensions? Dedicated multi-head GL output A common usecase for hardware accelerated video production is to dedicate one of the multi-head outputs of these GPUs to outputting the production signal on a dedicated head. This is usually achieved in interaction with the GLX/WGL/etc. Would there be any possibility to get this functionality for WebGL? Streaming video textures For on-line video production it would be useful to be able to present a FULL-HD video in WebGL. I know that there is an extension in the works (dynamic textures) for this for WebGL. Is there any progress on that? Streaming video output For on-line production it would be useful to be able to grab frames of a WebGL framebuffer and encode them to a video stream to put onto a websocket/webrtc etc. For off-line production this would probably just be raw frames, so no encoding would be required. Is there any possibility of introducing a video encoder to HTML that could perform the function of encoding video from a webgl drawing buffer using specified codec/container/quality parameters? Video Timing It is often desirable to match a given rendering to a video. I know that there's some timing information on videos, but I also know it's not terribly accurate. Is there any possiblity to get more precise video timing? ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Apr 2 13:01:39 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 2 Apr 2013 22:01:39 +0200 Subject: [Public WebGL] video/tv production issues In-Reply-To: <1838516869.1699986.1364931022808.JavaMail.root@mozilla.com> References: <1838516869.1699986.1364931022808.JavaMail.root@mozilla.com> Message-ID: On Tue, Apr 2, 2013 at 9:30 PM, Jeff Gilbert wrote: > For getting textures from videos, I don't think you need the dynamic > texture extension, though it could help some. All you should need is for > the browsers to pull the most recently decoded frame from the GPU. This is > an optimization which I believe Chrome is working on, but Firefox is still > getting around to. > That'd help. At the moment we're pretty much restricted to 640x320 at realtime framerates, just barely. -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Tue Apr 2 14:48:09 2013 From: din...@ (Dean Jackson) Date: Wed, 03 Apr 2013 08:48:09 +1100 Subject: [Public WebGL] video/tv production issues In-Reply-To: <1838516869.1699986.1364931022808.JavaMail.root@mozilla.com> References: <1838516869.1699986.1364931022808.JavaMail.root@mozilla.com> Message-ID: <3AD8E264-6C62-4746-BD43-59676DFFFC4F@apple.com> On 03/04/2013, at 6:30 AM, Jeff Gilbert wrote: > > For getting textures from videos, I don't think you need the dynamic texture extension, though it could help some. All you should need is for the browsers to pull the most recently decoded frame from the GPU. Most recently decoded? We decode many frames in advance and give a timestamped queue to our compositor. I assume you meant the current frame? The problem, at least on Apple platforms, is that the video decoding and the compositor might each be in another process, making it difficult for the browser to get access to the frames :( Dean > This is an optimization which I believe Chrome is working on, but Firefox is still getting around to. > > -Jeff > > ----- Original Message ----- > From: "Florian B?sch" > To: "public webgl" > Sent: Tuesday, March 12, 2013 4:06:49 AM > Subject: [Public WebGL] video/tv production issues > > > I'm getting some interest in the video/television industry to the effect of using WebGL. > > > For realtime production a typical setup would grab video frames off a monitors output at the monitors refresh frequency. Often the signal is converted then to interlaced formats and the like. There are some difficulties in such a setup. > > > Frame Tearing > 1) When the page is being composited out of sync with the WebGL drawing > 2) When the page is being composited out of sync with the monitors refresh frequency > > > I think (though I'm not entirely sure) that the first source of frame tearing is being addressed with canvas double buffering and improvements in requestAnimationFrame (correct me if I'm wrong). > > > As far as I'm aware the second source of frame tearing isn't being addressed right now (the browsers recompositing isn't synced to the monitors refresh frequency). > > > Is the above an accurate description of the issue, and is there being any effort yet to solve it? > > > Framerate > Browsers implement a maximum framerate at which the WebGL canvas can be shown (the frequency at which they recomposit). This is usually capped at 60hz. > > > For realtime video production it is desirable to exactly match the outputs refresh rate. For instance for these usecases: > > > * To render time interspersed stereographic video (usually each frame contains a marker). So for instance for say 60hz stereoscopic video, a framerate of 120hz would be required. > * To provide output intended for interlaced composition > * To avoid frame tearing > > > Would it be possible to have the browser match the outputs refresh exactly? > > > Antialiasing > Currently WebGL does not allow for fine grained control over antialiasing. Mostly one gets 4x4 MSAA (and sometimes no AA like on OSX). > > > There are a number of advanced AA options presented by GPU drivers (such as nvidias TXAA) that deliver fully hardware accelerated movie-like antialiasing at a fraction of the cost of brutal supersampling. > > > Would it be possible to get finer grained control over AA? > > > Video production workstation video input textures > Some of the GPUs used in these environments support direct video input -> texture (they usually sport multiple external video in ports). > > > As far as I could ascertain this capability is exposed via proprietary extensions of the drivers of these GPUs. > > > Would there be any possibility to gain access to these extensions? > > > Dedicated multi-head GL output > A common usecase for hardware accelerated video production is to dedicate one of the multi-head outputs of these GPUs to outputting the production signal on a dedicated head. > > > This is usually achieved in interaction with the GLX/WGL/etc. > > > Would there be any possibility to get this functionality for WebGL? > > > Streaming video textures > For on-line video production it would be useful to be able to present a FULL-HD video in WebGL. I know that there is an extension in the works (dynamic textures) for this for WebGL. > > > Is there any progress on that? > > > Streaming video output > For on-line production it would be useful to be able to grab frames of a WebGL framebuffer and encode them to a video stream to put onto a websocket/webrtc etc. For off-line production this would probably just be raw frames, so no encoding would be required. > > > Is there any possibility of introducing a video encoder to HTML that could perform the function of encoding video from a webgl drawing buffer using specified codec/container/quality parameters? > > > Video Timing > It is often desirable to match a given rendering to a video. I know that there's some timing information on videos, but I also know it's not terribly accurate. > > > Is there any possiblity to get more precise video timing? > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Apr 2 15:51:15 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 3 Apr 2013 00:51:15 +0200 Subject: [Public WebGL] video/tv production issues In-Reply-To: <3AD8E264-6C62-4746-BD43-59676DFFFC4F@apple.com> References: <1838516869.1699986.1364931022808.JavaMail.root@mozilla.com> <3AD8E264-6C62-4746-BD43-59676DFFFC4F@apple.com> Message-ID: On Tue, Apr 2, 2013 at 11:48 PM, Dean Jackson wrote: > I assume you meant the current frame? The problem, at least on Apple > platforms, is that the video decoding and the compositor might each be in > another process, making it difficult for the browser to get access to the > frames :( > Wait a second. The compositor is implemented by the browser (the page compositor). So it is known that browsers are capable to playback Full-HD video. It is also known that these days the compositor is hardware accelerated. So this has to mean that, if you are decoding video in a separate process, that there is a fast way to share that with the compositor. And because the compositor is also sharing with the WebGL context, that has to mean that there has to be a fast way to share video with WebGL in principle. -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Tue Apr 2 16:11:23 2013 From: din...@ (Dean Jackson) Date: Wed, 03 Apr 2013 10:11:23 +1100 Subject: [Public WebGL] video/tv production issues In-Reply-To: References: <1838516869.1699986.1364931022808.JavaMail.root@mozilla.com> <3AD8E264-6C62-4746-BD43-59676DFFFC4F@apple.com> Message-ID: <95E9CFFC-B5A0-4020-B752-B46F6EEE51CB@apple.com> On 03/04/2013, at 9:51 AM, Florian B?sch wrote: > On Tue, Apr 2, 2013 at 11:48 PM, Dean Jackson wrote: > I assume you meant the current frame? The problem, at least on Apple platforms, is that the video decoding and the compositor might each be in another process, making it difficult for the browser to get access to the frames :( > Wait a second. The compositor is implemented by the browser (the page compositor). I'm not sure what you mean by page compositor, but our compositor is not implemented by the browser. [It's a bit misleading to say "the" compositor, because there are many different compositing paths - I'm talking about our most common hardware path] > So it is known that browsers are capable to playback Full-HD video. It is also known that these days the compositor is hardware accelerated. So this has to mean that, if you are decoding video in a separate process, that there is a fast way to share that with the compositor. And because the compositor is also sharing with the WebGL context, that has to mean that there has to be a fast way to share video with WebGL in principle. In principle yes, because all the memory is shared. But not in practice. Our video decoder is sharing with our compositor. WebGL is writing to a surface the compositor puts on the screen. The compositor is the one that takes the image queue (of frames) and draws the right thing at the right time, while WebGL just tells the compositor an update is ready. My point was that it isn't necessarily easy to just get "the last decoded" frame into WebGL and do something with it. There is also audio sync to take into account. If you want to get the video frame and do something with it, you'll need to keep up with the audio, or at least tell the compositor and AV engine what's happening. This is the type of thing that isn't exposed in WebGL (or to any page content). Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Tue Apr 2 16:17:14 2013 From: kbr...@ (Kenneth Russell) Date: Tue, 2 Apr 2013 16:17:14 -0700 Subject: [Public WebGL] WebGL 1.0.1 released; linking 1.0 to latest version Message-ID: Last week at the Game Developers' Conference, Khronos announced the publication of the WebGL 1.0.1 specification: https://www.khronos.org/news/press/webgl-momentum-creating-the-industrys-most-secure-and-portable-3d-platform http://www.khronos.org/registry/webgl/specs/1.0.1/ This upgrade was a long time in coming; the spec was ratified in early 2012. The reason for the delay was that due to graphics driver bugs on multiple platforms, it was not possible until recently to pass the conformance suite on desktop operating systems according to the rules set out by the working group. Thanks to AMD, Apple, Intel, the Mesa developers, Mozilla, and NVIDIA, these issues have been resolved. Firefox and Chrome have submitted verified conformance suite results on Linux, Mac OS, and Windows. Future versions of these browsers will support getContext("webgl"). Marvell and NVIDIA have also submitted verified conformance test results on Android! On other threads, it was requested to rename the 1.0 specification to 1.0.0 and make http://www.khronos.org/registry/webgl/specs/1.0/ always point to the latest dot release (currently 1.0.1, and soon 1.0.2). This change is in progress; please post if there are any objections to it. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Tue Apr 2 16:24:37 2013 From: kbr...@ (Kenneth Russell) Date: Tue, 2 Apr 2013 16:24:37 -0700 Subject: [Public WebGL] WEBGL_dynamic_texture redux In-Reply-To: <51526662.9030300@artspark.co.jp> References: <508796C0.8000605@artspark.co.jp> <50AB4B3E.903@artspark.co.jp> <50B585D9.2090507@artspark.co.jp> <51526662.9030300@artspark.co.jp> Message-ID: Any update on a new draft of this extension? Intel recently contributed code to WebKit which accelerates texImage2D taking HTMLVideoElement with a GPU-to-GPU copy when hardware video decoding is used. See https://bugs.webkit.org/show_bug.cgi?id=111126 . This should be available for testing in the current Chrome Canary and should work at least on Windows and Mac OS. It would be great to do some performance comparisons between Chrome Stable and Canary for video texturing applications. -Ken On Tue, Mar 26, 2013 at 8:24 PM, Mark Callow wrote: > Hi Florian, > > Thanks for your suggestions on how to resolve those issues. > > There are other issues. In fact I have a new draft in progress with several > major changes; most of those are reflected in the example code I posted a > while ago. I have been working on something else but I expect to finish that > within the next day. I will then be able to spend some time back on dynamic > textures. I'll finish the draft as quickly as I can. > > Regards > > -Mark > > > > On 2013/03/26 4:38, Florian B?sch wrote: > > http://www.khronos.org/registry/webgl/extensions/proposals/WEBGL_dynamic_texture/ > lists issues 7 9, 10, 12 and 13 as unresolved. > > - Are there any other issues than those 13? > - Have any of the issues been resolved? > > I would suggest the following resolutions: > > 7) Accept the suggestion presented. > 10) No. This extension should provide a solution for video. > > To issues 12 and 13: Is there any solution to these issued raised with the > time flavor to use? > > To issue 11: Does it make this specification appear faster if it is defined > as "core" rather than as extension, in the 2 years that this issue has not > been resolved? If so, then I will suggest yes. If no then I will suggest no. > Anybody? > > > > On Wed, Nov 28, 2012 at 4:32 AM, Mark Callow > wrote: >> >> On 2012/11/22 11:15, David Sheets wrote: >> >> >> >> // // readonly int freq; ? do videos get one per channel? only max >> frequency of all media streams? >> >> What would you use this for? Without knowing the use case, the obvious >> answer is the frequency (framerate) of the producer video stream. However >> several modern video formats do not have a fixed framerate. >> >> I would use this for relating frame counts to >> latencies/timeouts/clocks. Specifically, without knowing the inherent >> maximum frequency of the producer, the consumer must guess its frame >> budget initially and back-off causing A/V glitches. >> >> I agree this would be useful for exactly the reasons you cited. >> Unfortunately web browsers do not make the frame-rate available to scripts >> even though most, if not all, container formats store this information. For >> example WebM supports the same FrameRate item as the Matroska container. >> >> Ideally we would persuade browser vendors/WHATWG to add it as an attribute >> of the HTMLVideoElement. Alternatively, since there may not be any uses >> outside WebGL, we could add it to the WebGLDynamicTextureSource interface, >> if we go that route. >> >> >> Are you planning on exposing the variable framerate of decoders to >> stream consumers in the msc? Is it bad to insert "duplicate" frames >> and increment the msc when the source framerate drops below max? I >> think consistency is valuable here and simplifies the author's work. >> If I test my generic video app with constant framerate videos but not >> variable framerate videos, I might be disappointed with performance on >> sophisticated codecs in future. Can this consistency abstraction leak >> in some way I am missing? >> >> I have come to the opinion that msc is not a useful concept for a >> variable-frame-rate video source. I'm leaning towards exposing the time at >> which the frame is expected to be displayed. >> >> I'll come back to your other questions in a separate message. I want to >> keep this focused on interface for hooking up producers. >> >> I am thinking of the following way of setting up a dynamic texture modeled >> on your WebGLDynamicTextureSource proposal. >> >> // Use object for "global" variables to avoid polluting the global >> space. >> var g = {}; >> >> // Array of files currently loading >> g.loadingFiles = []; >> >> gl.dte = gl.getExtension("WEBGL_dynamic_texture"); >> g.videoTexture = { >> texture: gl.createTexture(), >> video: createVideoElement(), >> stream: null >> }; >> // gl.activeTexture(gl.TEXTURE0); >> gl.bindTexture(gl.TEXTURE_EXTERNAL_OES, g.videoTexture.texture); >> // Create stream with currently bound texture as consumer. >> g.videoTexture.stream = gl.dte.createStream(); >> connectStreamToProducerAndSource(stream, video, >> "http://myserver/myvideo.mp4"); >> >> where createVideoElement() is >> >> // Create a hidden video element and append to the document >> // XXX Is it necessary to append the element? >> function createVideoElement() { >> var video = document.createElement('video'); >> video.autoplay = true; >> video.controls = false; >> video.hidden = true; >> document.body.appendChild(video); >> return video; >> } >> >> Note, creation of the video element was missing from the example >> previously. >> >> connectStreamToProducerAndSource() is >> >> function connectStreamToProducerAndSource(stream, video, url) { >> >> >> video.onload = function() { >> g.loadingFiles.splice(g.loadingFiles.indexOf(video), 1); >> }; >> video.onerror = function() { >> g.loadingFiles.splice(g.loadingFiles.indexOf(video), 1); >> // Notify user? Abort application? >> // video.error gives the reason. >> }; >> g.loadingFiles.push(video); >> video.wssConnectToSourceAsProducer(url, stream); >> } >> >> You first create the stream with its consumer then pass that to >> wssConnectToSourceAsProducer method that is part of the interface added to >> HTMLVideoElement. I'd like to hear from the WebIDL and browser experts >> whether something like >> >> interface WebGLStreamSource { >> void wssConnectToSourceAsProducer(DomString url, WebGLStream stream); >> void wssDisconnectFromStream(); >> unsigned long wssFrameRate; >> }; >> HTMLVideoElement implements WebGLStreamSource; >> >> is acceptable. >> >> Suggestions for better names are welcome. >> >> Behind this are the concepts that >> >> A producer can only be connected to a single stream >> The stream must be connected to the consumer before the stream is passed >> to the producer so the browser or underlying EGLStream implementation knows >> about both ends of the stream before it creates the video decoder. >> >> For this same reason the producer element cannot have done any processing >> of the video file before the connection is made, so the src attribute must >> be empty. >> >> DisconnectFromStream is used for handling context lost events. It will >> abort any in-progress connection attempt as well as disconnecting an >> established connection. >> The "wss" prefix is to identify that these properties are part of the >> WebGLStreamSource interface not the basic element properties. >> >> Having a standard interface for producers is attractive but I'm unsure how >> best to append this to existing elements as I'm lacking both JavaScript and >> WebIDL expertise. >> >> Opinions? >> >> Regards >> >> -Mark >> >> -- >> ???????????????????????????????????????????????????????????????? >> ?????????????????????????????????????????????????? ?????????????? ??. >> >> 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. > > > > > > > Regards > > -Mark > > -- > ???????????????????????????????????????????????????????????????? > ???????????????????????????????????????????????????????????????? ??. > > 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. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Tue Apr 2 16:33:33 2013 From: kbr...@ (Kenneth Russell) Date: Tue, 2 Apr 2013 16:33:33 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension Message-ID: The MapsGL team has requested for some time that the ANGLE_timer_query extension be exposed to WebGL. The primary use case is to allow tools to be written which identify performance problems in WebGL applications. Please review the proposal and send comments to the list: http://www.khronos.org/registry/webgl/extensions/proposals/ANGLE_timer_query/ Note that the planned upgrade of WebGL to the OpenGL ES 3.0 API will pull the query functions into the core. This extension becomes much smaller when applied to that API version. Thanks, -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From Rem...@ Tue Apr 2 16:51:48 2013 From: Rem...@ (Arnaud, Remi) Date: Tue, 2 Apr 2013 23:51:48 +0000 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: Message-ID: I was wondering if beginQueryANGLE and endQueryANGLE are needed, seems like queryCounterANGLE alone can cover all use cases? Regards -- Remi On 4/2/13 4:33 PM, "Kenneth Russell" wrote: > >The MapsGL team has requested for some time that the ANGLE_timer_query >extension be exposed to WebGL. The primary use case is to allow tools >to be written which identify performance problems in WebGL >applications. > >Please review the proposal and send comments to the list: > >http://www.khronos.org/registry/webgl/extensions/proposals/ANGLE_timer_que >ry/ > >Note that the planned upgrade of WebGL to the OpenGL ES 3.0 API will >pull the query functions into the core. This extension becomes much >smaller when applied to that API version. > >Thanks, > >-Ken > >----------------------------------------------------------- >You are currently subscribed to public_webgl...@ >To unsubscribe, send an email to majordomo...@ with >the following command in the body of your email: >unsubscribe public_webgl >----------------------------------------------------------- > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Tue Apr 2 17:03:22 2013 From: kbr...@ (Kenneth Russell) Date: Tue, 2 Apr 2013 17:03:22 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: Good question. As the primary author of the ANGLE_timer_query extension, Ben Vanik should answer it. Note that beginQuery and endQuery will definitely be needed in the OpenGL ES 3.0 upgrade, since they support occlusion and primitive queries. -Ken On Tue, Apr 2, 2013 at 4:51 PM, Arnaud, Remi wrote: > I was wondering if beginQueryANGLE and endQueryANGLE are needed, seems > like queryCounterANGLE alone can cover all use cases? > > Regards > -- Remi > > On 4/2/13 4:33 PM, "Kenneth Russell" wrote: > >> >>The MapsGL team has requested for some time that the ANGLE_timer_query >>extension be exposed to WebGL. The primary use case is to allow tools >>to be written which identify performance problems in WebGL >>applications. >> >>Please review the proposal and send comments to the list: >> >>http://www.khronos.org/registry/webgl/extensions/proposals/ANGLE_timer_que >>ry/ >> >>Note that the planned upgrade of WebGL to the OpenGL ES 3.0 API will >>pull the query functions into the core. This extension becomes much >>smaller when applied to that API version. >> >>Thanks, >> >>-Ken >> >>----------------------------------------------------------- >>You are currently subscribed to public_webgl...@ >>To unsubscribe, send an email to majordomo...@ with >>the following command in the body of your email: >>unsubscribe public_webgl >>----------------------------------------------------------- >> >> > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ben...@ Tue Apr 2 17:19:55 2013 From: ben...@ (Ben Vanik) Date: Tue, 2 Apr 2013 17:19:55 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: The two APIs provide two different values -- glQueryCounter gives you a timestamp where glBeginQuery/glEndQuery give you a time elapsed. There are scenarios where both are interesting: if you're trying to get many elapsed times (such as timing draw calls/etc) then using the begin/end methods halves the number of query objects you need vs. trying to do it yourself via queryCounter. There's also the potential for the values retrieved from either to be different: the spec allows for different internal timing mechanisms to be used for both. I'm not sure if this is the case in reality, but it is allowed. On Tue, Apr 2, 2013 at 5:03 PM, Kenneth Russell wrote: > Good question. As the primary author of the ANGLE_timer_query > extension, Ben Vanik should answer it. > > Note that beginQuery and endQuery will definitely be needed in the > OpenGL ES 3.0 upgrade, since they support occlusion and primitive > queries. > > -Ken > > > On Tue, Apr 2, 2013 at 4:51 PM, Arnaud, Remi wrote: > > I was wondering if beginQueryANGLE and endQueryANGLE are needed, seems > > like queryCounterANGLE alone can cover all use cases? > > > > Regards > > -- Remi > > > > On 4/2/13 4:33 PM, "Kenneth Russell" wrote: > > > >> > >>The MapsGL team has requested for some time that the ANGLE_timer_query > >>extension be exposed to WebGL. The primary use case is to allow tools > >>to be written which identify performance problems in WebGL > >>applications. > >> > >>Please review the proposal and send comments to the list: > >> > >> > http://www.khronos.org/registry/webgl/extensions/proposals/ANGLE_timer_que > >>ry/ > >> > >>Note that the planned upgrade of WebGL to the OpenGL ES 3.0 API will > >>pull the query functions into the core. This extension becomes much > >>smaller when applied to that API version. > >> > >>Thanks, > >> > >>-Ken > >> > >>----------------------------------------------------------- > >>You are currently subscribed to public_webgl...@ > >>To unsubscribe, send an email to majordomo...@ with > >>the following command in the body of your email: > >>unsubscribe public_webgl > >>----------------------------------------------------------- > >> > >> > > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Apr 2 17:54:59 2013 From: gma...@ (Gregg Tavares) Date: Tue, 2 Apr 2013 17:54:59 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: I've been told my by multiple people that APIs that can be used to spinwait are bad for JavaScript and the browser in general. The problem is people will do this beqinQuery(); ... endQuery(); // Spin Wait, blocking the browser and all UI processing while (!getQueryParameter(RESULT_AVAILABLE)); It seems like queries should be based on callbacks. On Tue, Apr 2, 2013 at 5:19 PM, Ben Vanik wrote: > The two APIs provide two different values -- glQueryCounter gives you a > timestamp where glBeginQuery/glEndQuery give you a time elapsed. There are > scenarios where both are interesting: if you're trying to get many elapsed > times (such as timing draw calls/etc) then using the begin/end methods > halves the number of query objects you need vs. trying to do it yourself > via queryCounter. There's also the potential for the values retrieved from > either to be different: the spec allows for different internal timing > mechanisms to be used for both. I'm not sure if this is the case in > reality, but it is allowed. > > > > > On Tue, Apr 2, 2013 at 5:03 PM, Kenneth Russell wrote: > >> Good question. As the primary author of the ANGLE_timer_query >> extension, Ben Vanik should answer it. >> >> Note that beginQuery and endQuery will definitely be needed in the >> OpenGL ES 3.0 upgrade, since they support occlusion and primitive >> queries. >> >> -Ken >> >> >> On Tue, Apr 2, 2013 at 4:51 PM, Arnaud, Remi wrote: >> > I was wondering if beginQueryANGLE and endQueryANGLE are needed, seems >> > like queryCounterANGLE alone can cover all use cases? >> > >> > Regards >> > -- Remi >> > >> > On 4/2/13 4:33 PM, "Kenneth Russell" wrote: >> > >> >> >> >>The MapsGL team has requested for some time that the ANGLE_timer_query >> >>extension be exposed to WebGL. The primary use case is to allow tools >> >>to be written which identify performance problems in WebGL >> >>applications. >> >> >> >>Please review the proposal and send comments to the list: >> >> >> >> >> http://www.khronos.org/registry/webgl/extensions/proposals/ANGLE_timer_que >> >>ry/ >> >> >> >>Note that the planned upgrade of WebGL to the OpenGL ES 3.0 API will >> >>pull the query functions into the core. This extension becomes much >> >>smaller when applied to that API version. >> >> >> >>Thanks, >> >> >> >>-Ken >> >> >> >>----------------------------------------------------------- >> >>You are currently subscribed to public_webgl...@ >> >>To unsubscribe, send an email to majordomo...@ with >> >>the following command in the body of your email: >> >>unsubscribe public_webgl >> >>----------------------------------------------------------- >> >> >> >> >> > >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Tue Apr 2 18:16:12 2013 From: ben...@ (Ben Vanik) Date: Tue, 2 Apr 2013 18:16:12 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: Callbacks aren't really scalable for this kind of use. They create too much overhead when trying to sample times. They also break a lot of the usage patterns that make this API easy to use. I believe we've had this discussion before with respect to resource locks and I still stand by my assertions there: callbacks hurt performance, lead to spaghetti code (especially when it comes to trying to time hundreds+ things across frames/contexts), and make the API less useful vs. the native version. Translating code that uses the API (via emscripten/etc) would also become much more difficult as the behavior is no longer the same. Callbacks also don't handle a potential use case of this (which may never happen in a browser such as Chrome but would in Firefox/etc) where you want to query and check the value in a single frame. ex, start drawing and begin a query, draw, then try to get the query result in the same tick to decide what to do next. Of course, advanced applications will try to pipeline this across frames, but sometimes you can't (due to potential latency issues/etc). I'm not sure I see a problem with that loop - you can shoot yourself in the foot many ways with code like that, and nobody should be writing that. But taking the sledgehammer approach of changing the API and breaking valid scenarios hurts those who have a real use of the API. People writing bad code will continue to find ways to do so. If it was a must that it not be allowed, breaking the contract here and forcing all query results be set in a separate JS tick would prevent spin loops while retaining the polling API. It'd turn loops like that into while(true);, which is probably fine. As I said, I doubt with the latency imposed by the separate GPU process as in Chrome that any results will be coming back in the same tick anyway. On Tue, Apr 2, 2013 at 5:54 PM, Gregg Tavares wrote: > I've been told my by multiple people that APIs that can be used to > spinwait are bad for JavaScript and the browser in general. > > The problem is people will do this > > beqinQuery(); > ... > endQuery(); > > // Spin Wait, blocking the browser and all UI processing > while (!getQueryParameter(RESULT_AVAILABLE)); > > It seems like queries should be based on callbacks. > > > > > On Tue, Apr 2, 2013 at 5:19 PM, Ben Vanik wrote: > >> The two APIs provide two different values -- glQueryCounter gives you a >> timestamp where glBeginQuery/glEndQuery give you a time elapsed. There are >> scenarios where both are interesting: if you're trying to get many elapsed >> times (such as timing draw calls/etc) then using the begin/end methods >> halves the number of query objects you need vs. trying to do it yourself >> via queryCounter. There's also the potential for the values retrieved from >> either to be different: the spec allows for different internal timing >> mechanisms to be used for both. I'm not sure if this is the case in >> reality, but it is allowed. >> >> >> >> >> On Tue, Apr 2, 2013 at 5:03 PM, Kenneth Russell wrote: >> >>> Good question. As the primary author of the ANGLE_timer_query >>> extension, Ben Vanik should answer it. >>> >>> Note that beginQuery and endQuery will definitely be needed in the >>> OpenGL ES 3.0 upgrade, since they support occlusion and primitive >>> queries. >>> >>> -Ken >>> >>> >>> On Tue, Apr 2, 2013 at 4:51 PM, Arnaud, Remi >>> wrote: >>> > I was wondering if beginQueryANGLE and endQueryANGLE are needed, seems >>> > like queryCounterANGLE alone can cover all use cases? >>> > >>> > Regards >>> > -- Remi >>> > >>> > On 4/2/13 4:33 PM, "Kenneth Russell" wrote: >>> > >>> >> >>> >>The MapsGL team has requested for some time that the ANGLE_timer_query >>> >>extension be exposed to WebGL. The primary use case is to allow tools >>> >>to be written which identify performance problems in WebGL >>> >>applications. >>> >> >>> >>Please review the proposal and send comments to the list: >>> >> >>> >> >>> http://www.khronos.org/registry/webgl/extensions/proposals/ANGLE_timer_que >>> >>ry/ >>> >> >>> >>Note that the planned upgrade of WebGL to the OpenGL ES 3.0 API will >>> >>pull the query functions into the core. This extension becomes much >>> >>smaller when applied to that API version. >>> >> >>> >>Thanks, >>> >> >>> >>-Ken >>> >> >>> >>----------------------------------------------------------- >>> >>You are currently subscribed to public_webgl...@ >>> >>To unsubscribe, send an email to majordomo...@ with >>> >>the following command in the body of your email: >>> >>unsubscribe public_webgl >>> >>----------------------------------------------------------- >>> >> >>> >> >>> > >>> > >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Apr 2 18:56:39 2013 From: gma...@ (Gregg Tavares) Date: Tue, 2 Apr 2013 18:56:39 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Tue, Apr 2, 2013 at 6:16 PM, Ben Vanik wrote: > Callbacks aren't really scalable for this kind of use. > Put up some code maybe to show this? It's certainly not obvious. > They create too much overhead when trying to sample times. > Don't agree. > They also break a lot of the usage patterns that make this API easy to > use. I believe we've had this discussion before with respect to resource > locks and I still stand by my assertions there: callbacks hurt performance, > lead to spaghetti code (especially when it comes to trying to time > hundreds+ things across frames/contexts), > Would have to see code to believe this. > and make the API less useful vs. the native version. Translating code that > uses the API (via emscripten/etc) would also become much more difficult as > the behavior is no longer the same. > That's not a valid reason to introduce bad APIs to JavaScript. > > Callbacks also don't handle a potential use case of this (which may never > happen in a browser such as Chrome but would in Firefox/etc) where you want > to query and check the value in a single frame. ex, start drawing and begin > a query, draw, then try to get the query result in the same tick to decide > what to do next. > You shouldn't be doing that as have you no guarantee when the commands will happen. This isn't a use case we encourage. In fact it's one we should actively discourage since it's not remotely portable. > Of course, advanced applications will try to pipeline this across frames, > but sometimes you can't (due to potential latency issues/etc). > > I'm not sure I see a problem with that loop - you can shoot yourself in > the foot many ways with code like that, and nobody should be writing that. > So don't make it possible. > But taking the sledgehammer approach of changing the API and breaking > valid scenarios hurts those who have a real use of the API. People writing > bad code will continue to find ways to do so. > That doesn't mean we should let them if it's trivial to prevent. Or maybe we should go make xhr, images, keys, etc all polling because because good programmers will do the right thing and bad will still write bad. > If it was a must that it not be allowed, breaking the contract here and > forcing all query results be set in a separate JS tick would prevent spin > loops while retaining the polling API. It'd turn loops like that into > while(true);, which is probably fine. As I said, I doubt with the latency > imposed by the separate GPU process as in Chrome that any results will be > coming back in the same tick anyway. > The API you're exposing is the same API used for occlusion queries in ES 3.0 and so whatever solution is chosen here will likely need to be the same for occlusion queries. IMO that should be callbacks. That's the JavaScript way. It's also browser friendly. Polling is not. > > > > On Tue, Apr 2, 2013 at 5:54 PM, Gregg Tavares wrote: > >> I've been told my by multiple people that APIs that can be used to >> spinwait are bad for JavaScript and the browser in general. >> >> The problem is people will do this >> >> beqinQuery(); >> ... >> endQuery(); >> >> // Spin Wait, blocking the browser and all UI processing >> while (!getQueryParameter(RESULT_AVAILABLE)); >> >> It seems like queries should be based on callbacks. >> >> >> >> >> On Tue, Apr 2, 2013 at 5:19 PM, Ben Vanik wrote: >> >>> The two APIs provide two different values -- glQueryCounter gives you a >>> timestamp where glBeginQuery/glEndQuery give you a time elapsed. There are >>> scenarios where both are interesting: if you're trying to get many elapsed >>> times (such as timing draw calls/etc) then using the begin/end methods >>> halves the number of query objects you need vs. trying to do it yourself >>> via queryCounter. There's also the potential for the values retrieved from >>> either to be different: the spec allows for different internal timing >>> mechanisms to be used for both. I'm not sure if this is the case in >>> reality, but it is allowed. >>> >>> >>> >>> >>> On Tue, Apr 2, 2013 at 5:03 PM, Kenneth Russell wrote: >>> >>>> Good question. As the primary author of the ANGLE_timer_query >>>> extension, Ben Vanik should answer it. >>>> >>>> Note that beginQuery and endQuery will definitely be needed in the >>>> OpenGL ES 3.0 upgrade, since they support occlusion and primitive >>>> queries. >>>> >>>> -Ken >>>> >>>> >>>> On Tue, Apr 2, 2013 at 4:51 PM, Arnaud, Remi >>>> wrote: >>>> > I was wondering if beginQueryANGLE and endQueryANGLE are needed, seems >>>> > like queryCounterANGLE alone can cover all use cases? >>>> > >>>> > Regards >>>> > -- Remi >>>> > >>>> > On 4/2/13 4:33 PM, "Kenneth Russell" wrote: >>>> > >>>> >> >>>> >>The MapsGL team has requested for some time that the ANGLE_timer_query >>>> >>extension be exposed to WebGL. The primary use case is to allow tools >>>> >>to be written which identify performance problems in WebGL >>>> >>applications. >>>> >> >>>> >>Please review the proposal and send comments to the list: >>>> >> >>>> >> >>>> http://www.khronos.org/registry/webgl/extensions/proposals/ANGLE_timer_que >>>> >>ry/ >>>> >> >>>> >>Note that the planned upgrade of WebGL to the OpenGL ES 3.0 API will >>>> >>pull the query functions into the core. This extension becomes much >>>> >>smaller when applied to that API version. >>>> >> >>>> >>Thanks, >>>> >> >>>> >>-Ken >>>> >> >>>> >>----------------------------------------------------------- >>>> >>You are currently subscribed to public_webgl...@ >>>> >>To unsubscribe, send an email to majordomo...@ with >>>> >>the following command in the body of your email: >>>> >>unsubscribe public_webgl >>>> >>----------------------------------------------------------- >>>> >> >>>> >> >>>> > >>>> > >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Wed Apr 3 00:25:34 2013 From: jgi...@ (Jeff Gilbert) Date: Wed, 3 Apr 2013 00:25:34 -0700 (PDT) Subject: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test Message-ID: <428651250.1811763.1364973934303.JavaMail.root@mozilla.com> On some mobile devices, we're hitting a couple errors followed by a gl.OUT_OF_MEMORY error in the "check reading with lots of drawing" section. This is AFAIK spec-compliant behavior, so I believe the test should be changed to gl.flush() after each draw call, which seems to have fixed it for me. Thoughts? -Jeff ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Wed Apr 3 02:55:48 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 3 Apr 2013 11:55:48 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: I don't agree that not having callbacks would lead to while(true){} use. But I might not fully understand the API. Here is what you would normally do with measured values: - Compute an average sliding window - Compute statistic measures such as variance and deviation To do that a ring-buffer is usually used to store N previous sample points. It works about like this everytime you have a sample point. buffer[i] = samplePoint; i = (i+1)%buffer.length; And then you compute/draw whatever from that buffer. A sliding average can be efficiently implemented this way by subtracting the old value from the average and adding the new value, like so: sumAvg += samplePoint - buffer[i]; average = sumAvg/buffer.length; buffer[i] = samplePoint; i = (i+1)%buffer.length; To do that with the query object API I'd imagine you'd do this: var queries = []; var samples = new Float32Array(1024); var sampleIdx = 0; var draw = function(){ var query = var query = ext.createQueryANGLE(); queries.push(query); ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); gl.drawElements(...); ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); while(queries.length > 0){ query = queries[0]; if(ext.getQueryParameterANGLE(query, ext.QUERY_RESULT_AVAILABLE_ANGLE)){ queries.shift(); var timeElapsed = ext.getQueryParameterANGLE(query, ext.QUERY_RESULT_ANGLE); var samples[sampleIdx] = timeElapsed; sampleIdx = (sampleIdx+1)%samples.length; } else{ break; } } } I think that would be fairly acceptable code. Do I miss something? -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Wed Apr 3 02:55:51 2013 From: cal...@ (Mark Callow) Date: Wed, 03 Apr 2013 18:55:51 +0900 Subject: [Public WebGL] WEBGL_dynamic_texture redux In-Reply-To: References: <508796C0.8000605@artspark.co.jp> <50AB4B3E.903@artspark.co.jp> Message-ID: <515BFCA7.3080203@artspark.co.jp> Hi David, Finally I'm getting back to the rest of your questions and comments. It's tough to switch contexts after the time that has elapsed. I hope you can still remember the questions I am responding to. All, I will produce a new draft of the extension as soon as I can. I'll give myself a deadline of 2 weeks. It need to include the new interfaces & methods shown in the current version of the sample (in the extensions/proposals section of the GIT repository) after I've modified them to work with frames that provide their presentation time, if I can figure out a way. On 2012/11/22 11:15, David Sheets wrote: > Are you planning on exposing the variable framerate of decoders to > stream consumers in the msc? Is it bad to insert "duplicate" frames > and increment the msc when the source framerate drops below max? I > think consistency is valuable here and simplifies the author's work. > If I test my generic video app with constant framerate videos but not > variable framerate videos, I might be disappointed with performance on > sophisticated codecs in future. Can this consistency abstraction leak > in some way I am missing? msc is intended to tell the application how many samples have come through the decoder so it can tell if it has missed any. So it is bad to artificially increment it. I suspect issues are more likely to arise if initial testing took place with a variable-frame-rate video and then a fixed-frame-rate video is used. It is likely possible to fake a fixed frame rate but I prefer to explore using the presentation time stamp of the video before going that route. > When the source is bound? See below for the discussion of > source-stream correspondence. When would the app need to set an upper > bound in the stream object rather than in some wrapping function? The sample (the one mentioned above) shows this. I think the max latency will have to be set at the time the stream is bound to the producer. I think producers may have trouble increasing the read-ahead on the fly. By setting it when the producer is established, the producer can decode enough frames to cover the maximum possible latency before it starts to deliver any and before it starts to play the audio. It can continue to decode the video that amount of time ahead regardless of which frames it is actually putting into the stream. > Use 1: > > We notice that the video latency has decreased from large k to 0 so > the user is seeing video from t+k but hearing audio from t. Setting > the latency to 0 will repeat (or pause) frames as you have said. Will > pause vs repeat be specified? I want to specify a smooth transition rather than a jump. It's more difficult to specify when variable-frame-rate must be taken into consideration. I'll have to think about language. > Use 2: > > ... > > How can this use case be supported? Will it be supported? Is it > possible/feasible? It seems to require the ability to generate two > streams for the increased latency case. I believe composed streams > could support this use case. > > Performance video art and other dynamic video compositing apps require > this capability. Is there some other way to accomplish it? I hadn't thought about this at all. > >> if (lastFrame.ust) { >> syncValues = gl.dte.getSyncValues(); >> // interface syncValues { >> // // UST of last present >> // readonly attribute long long ust; >> // // Screen refresh count (aka MSC) at last present >> // // Initialized to 0 on browser start >> // readonly attribute long msc; > On page load? Browser start leaks information that may not be > otherwise discoverable. Thoughts? I have been looking at the High Resolution Time spec. It starts a timer at page load. It might be appropriate to start the screen MSC then too. What information would be discoverable, other than how long the browser has been running? Is that information a security concern? >>> // // Canvas presentation count at last present >>> // // Initialized to 0 at canvas creation. >>> // readonly attribute long cpc; >>> // }; >>> // XXX What happens to cpc when switch to another tab? >>> if (syncValues.msc - graphicsMSCBase != syncValues.cpc) { // this >>> assumes the media rates are locked to the rendering rates >> No. Read the comment below. This relates only to whether the 3D rendering is >> keeping up with the screen refresh. >> >>> // We are not keeping up with screen refresh! >>> // Or are we? If cpc increment stops when canvas hidden, >>> // will need some way to know canvas was hidden so app >>> // won't just assume its not keeping up and therefore >>> // adjust its rendering. > My previous comment ("this assumes...") was too imprecise. I believe > we are talking about the same issue. The CPC is not related to time > *at all* (see above) whereas the screen MSC is incremented at a fixed > frequency. This condition compares cycles to counter. Why does screen > refresh matter here if the canvas is being presented slower? It seems > to me like we should be using our graphicsMSCBase to track the CPC > delta instead of the MSC delta. Have I missed something? A +ve cpc (canvas presentation count) delta would tell the application that it missed a browser composition cycle. But it gives no information about whether browser composition is keeping up with screen refresh or video frame rate. It is when the video hits the screen that is important for audio sync. Tracking the screen MSC lets the app. account for delays in itself and the browser. It should probably track the cpc delta as well to improve decisions about what to do to reduce any delays. > >>> graphicsMSCBase = syncValues.msc; // reset base. > When this occurs once, it will occur every subsequent invocation > (increasing at same rate as normal CPC but now CPC always greater, > never equal). Yup. I've changed it to graphicsMSCBase = syncValues.msc - syncValues.cpc; but not submitted it to github yet. >>> } >>> latency.accumValue += syncValues.ust - lastFrame.ust; > How do we know the last present corresponds to the last draw command? > What if the GPU pipeline is several frames deep? We don't. Why does it matter? What is important for audio sync is when the pixels of the frame hit the display. Ah!! When you say draw command do you mean the last requestAnimationFrame->drawFrame() cycle rather than a gl.drawXXX command? That is not a GPU pipeline issue. It's a browser compositor issue. The DT spec will say that getSyncValues() function returns the time at which the page whose composition includes the canvas image from the previous draw cycle hit the screen. It would be a lot easier to specify if we had an explicit present() function. > Rotating 900 degrees != rotating 180 degrees. Not sure what this has to do with what we are discussing. > Each dynamic texture sink somehow needs a > per-stream presentation msc to fix this, Why? If the sinks are all in 1 canvas that canvas's pixels are going to hit the display at the same time. I think the same will be true if the page has multiple canvases. If not, the application should track sync separately for each canvas. cpc should be per canvas. >>> latency.frameCount++; >>> if (latency.frameCount == 30) { // is this 30 the fps of the encoded >>> video? can it be retrieved from the stream source somehow? >> No. It is just the number of frames I picked to over which to average the >> latencies. I'm not sure there is any advantage to picking a number based on >> the fps of the source. > When we are drawing faster (at a potentially uneven rate) than the > frames are produced (acquireImage times out) (at a potentially uneven > rate without the max frequency behavior above), our accumulator > increases a lot erroneously. Should the latency only be updated when > the next frame is successfully acquired? > > I would lock the latency estimation window to a ust duration unless > the source frequency is fixed to gain a consistent real-world > frequency (and reliable observables) and prevent jitters or slow > resync. Is there a reason to not use an exponential moving average? I think you are correct that my approach to latency calculation is too simplistic. Locking it to a ust duration seems reasonable. > We won't really know if this matters until a video decoder gets > plugged into a rendering context inside of a browser compositor in a > non-trivial way. Maybe it won't matter. Is there an issue exposing the > maximum framerate of a texture source? I don't think so. > It could be unknown? Unfortunately it is unknown because HTMLVideoElement does not include a frame rate attribute. I need to complete the exercise of modifying the example to use frame presentation times since that seems to be the web way. >> How many streams may exist for a given media source? >> >> Keep it simple. 1 only I think. > Excellent! I agree but this requires a hybrid of the approaches above. > Specifically, the same stream must be created from the source which > implies the constructor of the stream requires the source object. I > don't think it matters whether the stream lives on the DOM element or > as a separate object so long as it is singleton for a source. Yes we need to do something to ensure that only one stream can be created from a source. > How should applications with multiple consumers with varying latency > be handled? My use case is live preview of Apple Photobooth filters in > separate DOM elements. Does each source get a single stream *per > context*? How do I synchronize across contexts? If I can compose > streams, I can build a sorted dynamic texture source chain with > increasing latency to feed the canvases. I haven't thought about this use case. I need to study the underlying EGL & GL extensions to see if they support an EGLStream being sent to multiple contexts. >> What type of object may be used to generate a stream source? >> >> Do you mean what kind of object can be a stream source? HTMLVideoElement, >> etc. > Yes but seeing as we are avoiding changing the concrete interfaces of > sources, the stream object will exist separate from and in one-to-one > correspondence with the source. Can canvas elements be sources? Can > DOM elements be privileged sources? Is it possible to specify that > objects implementing a given empty IDL interface are valid producers? I'm not sure it is necessary to support these other objects as producers, except Canvas. The purpose of the extension is to allow data to be moved from video decoder to GPU or internally within the GPU without CPU intervention. I'd prefer to limit our ambitions for the first version. > Is there a problem with buffering live sources to t+k delayed > real-time? This is a case where knowing the maximum framerate of the > stream in advance would be helpful to avoid audio glitches due to > running overbudget. I expect that could be done. > I mean have one stream represent stream A followed by stream B. The > use case is using stream as a common abstraction between a consumer > library and a producer web app. I guess rebinding a new dynamic > texture is OK but I am concerned about sourcing from HTMLVideoElement. > Is the stream connected to the current video decoder of the > HTMLVideoElement source? What happens when I change the > HTMLVideoElement source? If it's the same stream, this would be > concatenation of video streams but would seem to break invariants in > the source representation (frame counts, frequencies, CORS-ness). > Should this functionality be part of the stream instead? Should the > stream need to know about all of its sources at creation time? This is another topic I will have to give thought to. It's probably easiest at first to say you can't change the HTMLVideoElement source once bound to a stream. > Sourcing one stream from another I would call 'composition' and I > believe it has applications for multiple consumers at varying > latencies (see Photobooth example above). I would like to ensure we don't put anything in the spec. that would block this but I don't think we should put effort into supporting it in the first version. > > Stream objects provide an interface for synchronized images from > outside a GL context to a dynamic texture inside a GL context. Here > are my use cases, please let me know if there are better ways to > accomplish them: > > 1. I use unprivileged resources and readPixels for picking. If I have > multiple contexts in the main thread, producing streams from FBOs lets > me share rendering between them with low latency while sequestering > unprivileged data in the display context. This lets me render most of > the scene once (assuming MRT), composite unprivileged resources for > display, and still be able to read-back most of the rendering for > screen capture or a single pixel for picking. I think allowing texture sharing between contexts is the way forward for this case. > 2. I have a WebGL context in the main thread and a WebGL context in a > worker (to keep the main loop smooth despite texture loads/shader > compiles). I don't need to share general GL objects, just an > expensive-to-compute-or-update dynamic texture. Again I think texture sharing is the answer for this case. > 3. I want to get a video screen capture (GL context only) of what my > user is seeing (including timing glitches) as part of a bug report. No > video encoder interface has yet been specified/implemented AFAIK but > OpenMAX appears to offer this capability. Will this be a separate API > for "streams-going-to-encoders"? Why? I agree that this use case should use the same stream object as the interface between the canvas and the video encoder. This is another reason why Canvas should be a producer. Thanks for the feedback and interesting use cases. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mri...@ Wed Apr 3 06:28:24 2013 From: mri...@ (Ribble, Maurice) Date: Wed, 3 Apr 2013 13:28:24 +0000 Subject: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test In-Reply-To: <428651250.1811763.1364973934303.JavaMail.root@mozilla.com> References: <428651250.1811763.1364973934303.JavaMail.root@mozilla.com> Message-ID: <6EDD22A170C08F44982E1F9895B3537D166E3ED0@NASANEXD01F.na.qualcomm.com> SSBkb24ndCBzZWUgd2h5IGFkZGluZyBhIGZsdXNoIHdvdWxkIGFjdHVhbGx5IGhlbHAuICBJbiBv dXIgaW1wbGVtZW50YXRpb24gdGhhdCB3aWxsIGFjdHVhbGx5IGNhdXNlIHVzIHRvIGNvbnN1bWUg ZXZlbiBtb3JlIG1lbW9yeSB3aXRoIGNvbW1hbmQgYnVmZmVycyBhbmQgdGhlcmVmb3IgZ28gdG8g bG93IG1lbW9yeSBjb25kaXRpb25zIG1vcmUgcXVpY2tseS4gIElmIHlvdSBuZWVkIHRvIGRvIHNv bWV0aGluZyBsaWtlIHRoaXMgSSdkIHN1Z2dlc3QgYSBnbEZpbmlzaCBpbnN0ZWFkLiAgSXQncyBh bHNvIHdvcnRoIG1lbnRpb25pbmcgdGhhdCBhZGRpbmcgYSBmbHVzaCBvciBmaW5pc2ggYWZ0ZXIg ZXZlcnkgZHJhdyBjYWxsIHdpbGwgbWFrZSBzb21lIGltcGxlbWVudGF0aW9ucyB2ZXJ5IHNsb3cu ICBJJ3ZlIHNlZW4gdGhpcyBraW5kIG9mIGNvZGUgc2xvdyBzb21lIHRpbGluZyBpbXBsZW1lbnRh dGlvbnMgZG93biBieSBvdmVyIDEwMHguDQoNCkkgd2lsbCBhbHNvIG1lbnRpb24gdGhhdCB5b3Ug c2hvdWxkIG5vdCBzZWUgdGhpcyBwcm9ibGVtIG9uIG91ciBwbGF0Zm9ybXMgd2l0aCBhIHNpbmds ZSBjb250ZXh0IGFwcC4gIFdlIHN0YXJ0IGRvaW5nIGltcGxpY2l0IGZsdXNoL2ZpbmlzaCBpZiB3 ZSBkZXRlY3Qgb3V0IG9mIG1lbW9yeSBjb25kaXRpb25zIHNvIHRoYXQgYXBwcyBjYW4gY29udGlu dWUgdG8gZ2V0IHRoZSBjb3JyZWN0IHJlc3VsdHMgYXQgYSBsb3dlciBwZXJmb3JtYW5jZSBsZXZl bC4NCg0KLU1hdXJpY2UNCg0KDQoNCi0tLS0tT3JpZ2luYWwgTWVzc2FnZS0tLS0tDQpGcm9tOiBv d25lci1wdWJsaWNfd2ViZ2xAa2hyb25vcy5vcmcgW21haWx0bzpvd25lci1wdWJsaWNfd2ViZ2xA a2hyb25vcy5vcmddIE9uIEJlaGFsZiBPZiBKZWZmIEdpbGJlcnQNClNlbnQ6IFdlZG5lc2RheSwg QXByaWwgMDMsIDIwMTMgMzoyNiBBTQ0KVG86IHB1YmxpYyB3ZWJnbA0KU3ViamVjdDogW1B1Ymxp YyBXZWJHTF0gT1VUX09GX01FTU9SWSBlcnJvciBpbiAxLjAuMS9jb25mb3JtYW5jZS9yZWFkaW5n L3JlYWQtcGl4ZWxzLXRlc3QNCg0KDQpPbiBzb21lIG1vYmlsZSBkZXZpY2VzLCB3ZSdyZSBoaXR0 aW5nIGEgY291cGxlIGVycm9ycyBmb2xsb3dlZCBieSBhIGdsLk9VVF9PRl9NRU1PUlkgZXJyb3Ig aW4gdGhlICJjaGVjayByZWFkaW5nIHdpdGggbG90cyBvZiBkcmF3aW5nIiBzZWN0aW9uLiBUaGlz IGlzIEFGQUlLIHNwZWMtY29tcGxpYW50IGJlaGF2aW9yLCBzbyBJIGJlbGlldmUgdGhlIHRlc3Qg c2hvdWxkIGJlIGNoYW5nZWQgdG8gZ2wuZmx1c2goKSBhZnRlciBlYWNoIGRyYXcgY2FsbCwgd2hp Y2ggc2VlbXMgdG8gaGF2ZSBmaXhlZCBpdCBmb3IgbWUuDQoNClRob3VnaHRzPw0KDQotSmVmZg0K DQotLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLQ0KWW91IGFyZSBjdXJyZW50bHkgc3Vic2NyaWJlZCB0byBwdWJsaWNfd2ViZ2xAa2hyb25v cy5vcmcuDQpUbyB1bnN1YnNjcmliZSwgc2VuZCBhbiBlbWFpbCB0byBtYWpvcmRvbW9Aa2hyb25v cy5vcmcgd2l0aCB0aGUgZm9sbG93aW5nIGNvbW1hbmQgaW4gdGhlIGJvZHkgb2YgeW91ciBlbWFp bDoNCnVuc3Vic2NyaWJlIHB1YmxpY193ZWJnbA0KLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0t LS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0tLS0NCg0K ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Wed Apr 3 09:13:43 2013 From: gma...@ (Gregg Tavares) Date: Wed, 3 Apr 2013 09:13:43 -0700 Subject: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test In-Reply-To: <428651250.1811763.1364973934303.JavaMail.root@mozilla.com> References: <428651250.1811763.1364973934303.JavaMail.root@mozilla.com> Message-ID: IIRC the tests have been written to use a reasonable (less than 60meg) amount of memory. The spec unfortunately makes it possible for every function to generate GL_OUT_OF_MEMORY period and still be technically spec compliant. In other words, according to the spec an implementation could to this GLenum glGetErrror() { return GL_OUT_OF_MEMORY; } void glBindBuffer(...) { /* no-op */ } void glBindTexture(...) { /* no-op */ } void glTexImage2D(...) { /* no-op */ } void glDrawArrays(...) { /* no-op */ } And be valid according to the spec :-( On Wed, Apr 3, 2013 at 12:25 AM, Jeff Gilbert wrote: > > On some mobile devices, we're hitting a couple errors followed by a > gl.OUT_OF_MEMORY error in the "check reading with lots of drawing" section. > This is AFAIK spec-compliant behavior, so I believe the test should be > changed to gl.flush() after each draw call, which seems to have fixed it > for me. > > Thoughts? > > -Jeff > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Wed Apr 3 09:34:59 2013 From: gma...@ (Gregg Tavares) Date: Wed, 3 Apr 2013 09:34:59 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: Florian, This isn't about whether a good programmer like you can write correct code. It's about whether bad programmers will write code that browser vendors are stuck supporting. The API proposed by ANGLE_timer_query is the same API used for occlusion queries. The only difference is a 3 emums. Bad devs will do this for each object () { drawOccluder(); spinWaitForAnswer(); if (!occluded()) { doHeavyDraw(); } } If that happens to run fast enough on some browser/driver combo they'll ship it. Then users will complain they can't interact with the browser because it's stuck waiting for JavaScript. This is the same reason why the browser vendors are sad there's a synchronous XHR function. It kills UX. They'd get rid of it if they could but MS made that mistake 15 years ago so were stuck with it. Let's not make the same mistake. On Wed, Apr 3, 2013 at 2:55 AM, Florian B?sch wrote: > I don't agree that not having callbacks would lead to while(true){} use. > But I might not fully understand the API. Here is what you would normally > do with measured values: > > - Compute an average sliding window > - Compute statistic measures such as variance and deviation > > To do that a ring-buffer is usually used to store N previous sample > points. It works about like this everytime you have a sample point. > > buffer[i] = samplePoint; > i = (i+1)%buffer.length; > > And then you compute/draw whatever from that buffer. A sliding average can > be efficiently implemented this way by subtracting the old value from the > average and adding the new value, like so: > > sumAvg += samplePoint - buffer[i]; > average = sumAvg/buffer.length; > buffer[i] = samplePoint; > i = (i+1)%buffer.length; > > To do that with the query object API I'd imagine you'd do this: > > var queries = []; > var samples = new Float32Array(1024); > var sampleIdx = 0; > > var draw = function(){ > var query = var query = ext.createQueryANGLE(); > queries.push(query); > ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); > gl.drawElements(...); > ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); > > while(queries.length > 0){ > query = queries[0]; > if(ext.getQueryParameterANGLE(query, > ext.QUERY_RESULT_AVAILABLE_ANGLE)){ > queries.shift(); > var timeElapsed = ext.getQueryParameterANGLE(query, > ext.QUERY_RESULT_ANGLE); > var samples[sampleIdx] = timeElapsed; > sampleIdx = (sampleIdx+1)%samples.length; > } > else{ > break; > } > } > } > > I think that would be fairly acceptable code. Do I miss something? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Apr 3 09:45:58 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 3 Apr 2013 18:45:58 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: Well, does the callback proposal actually improve things? Let's see. var samples = new Float32Array(1024); var sampleIdx = 0; var sampleDone = function(timeElapsed){ samples[sampleIdx] = timeElapsed; sampleIdx = (sampleIdx+1)%samples.length; ext.deleteQueryAngle(this); } var draw = function(){ var query = var query = ext.createQueryANGLE(); query.onavailable = sampleDone; ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); gl.drawElements(...); ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); } I think that's nicer. Less mucking about with with keeping query objects in a container. Assuming of course that queries will become available in order of things actually completing, and not in some random order. So the browser will have to remember the sequency and not call back to it out of order. I'm assuming that wouldn't be a problem right? On Wed, Apr 3, 2013 at 6:34 PM, Gregg Tavares wrote: > Florian, > > This isn't about whether a good programmer like you can write correct > code. It's about whether bad programmers will write code that browser > vendors are stuck supporting. > > The API proposed by ANGLE_timer_query is the same API used for occlusion > queries. The only difference is a 3 emums. Bad devs will do this > > for each object () { > drawOccluder(); > spinWaitForAnswer(); > if (!occluded()) { > doHeavyDraw(); > } > } > > If that happens to run fast enough on some browser/driver combo they'll > ship it. Then users will complain they can't interact with the browser > because it's stuck waiting for JavaScript. This is the same reason why the > browser vendors are sad there's a synchronous XHR function. It kills UX. > They'd get rid of it if they could but MS made that mistake 15 years ago so > were stuck with it. Let's not make the same mistake. > > > > > > > > On Wed, Apr 3, 2013 at 2:55 AM, Florian B?sch wrote: > >> I don't agree that not having callbacks would lead to while(true){} use. >> But I might not fully understand the API. Here is what you would normally >> do with measured values: >> >> - Compute an average sliding window >> - Compute statistic measures such as variance and deviation >> >> To do that a ring-buffer is usually used to store N previous sample >> points. It works about like this everytime you have a sample point. >> >> buffer[i] = samplePoint; >> i = (i+1)%buffer.length; >> >> And then you compute/draw whatever from that buffer. A sliding average >> can be efficiently implemented this way by subtracting the old value from >> the average and adding the new value, like so: >> >> sumAvg += samplePoint - buffer[i]; >> average = sumAvg/buffer.length; >> buffer[i] = samplePoint; >> i = (i+1)%buffer.length; >> >> To do that with the query object API I'd imagine you'd do this: >> >> var queries = []; >> var samples = new Float32Array(1024); >> var sampleIdx = 0; >> >> var draw = function(){ >> var query = var query = ext.createQueryANGLE(); >> queries.push(query); >> ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); >> gl.drawElements(...); >> ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); >> >> while(queries.length > 0){ >> query = queries[0]; >> if(ext.getQueryParameterANGLE(query, >> ext.QUERY_RESULT_AVAILABLE_ANGLE)){ >> queries.shift(); >> var timeElapsed = ext.getQueryParameterANGLE(query, >> ext.QUERY_RESULT_ANGLE); >> var samples[sampleIdx] = timeElapsed; >> sampleIdx = (sampleIdx+1)%samples.length; >> } >> else{ >> break; >> } >> } >> } >> >> I think that would be fairly acceptable code. Do I miss something? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Wed Apr 3 10:18:10 2013 From: gma...@ (Gregg Tavares) Date: Wed, 3 Apr 2013 10:18:10 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: There's another issue with the polling API. It exposes inconsistent behavior. Devs can decide not to check whether a query result is available and just read the result. For example they could assume if they ended a query last frame that reading the result next frame will be valid without checking that it actually is valid. This may work on some % of systems but fail on another % of systems. It might also fail on the same system depending on various random factors. Adding such inconsistent behavior into WebGL doesn't seem like a good idea. On Wed, Apr 3, 2013 at 9:45 AM, Florian B?sch wrote: > Well, does the callback proposal actually improve things? Let's see. > > var samples = new Float32Array(1024); > var sampleIdx = 0; > > var sampleDone = function(timeElapsed){ > samples[sampleIdx] = timeElapsed; > sampleIdx = (sampleIdx+1)%samples.length; > ext.deleteQueryAngle(this); > } > > var draw = function(){ > var query = var query = ext.createQueryANGLE(); > query.onavailable = sampleDone; > > ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); > gl.drawElements(...); > ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); > } > > I think that's nicer. Less mucking about with with keeping query objects > in a container. Assuming of course that queries will become available in > order of things actually completing, and not in some random order. So the > browser will have to remember the sequency and not call back to it out of > order. I'm assuming that wouldn't be a problem right? > > > On Wed, Apr 3, 2013 at 6:34 PM, Gregg Tavares wrote: > >> Florian, >> >> This isn't about whether a good programmer like you can write correct >> code. It's about whether bad programmers will write code that browser >> vendors are stuck supporting. >> >> The API proposed by ANGLE_timer_query is the same API used for occlusion >> queries. The only difference is a 3 emums. Bad devs will do this >> >> for each object () { >> drawOccluder(); >> spinWaitForAnswer(); >> if (!occluded()) { >> doHeavyDraw(); >> } >> } >> >> If that happens to run fast enough on some browser/driver combo they'll >> ship it. Then users will complain they can't interact with the browser >> because it's stuck waiting for JavaScript. This is the same reason why the >> browser vendors are sad there's a synchronous XHR function. It kills UX. >> They'd get rid of it if they could but MS made that mistake 15 years ago so >> were stuck with it. Let's not make the same mistake. >> >> >> >> >> >> >> >> On Wed, Apr 3, 2013 at 2:55 AM, Florian B?sch wrote: >> >>> I don't agree that not having callbacks would lead to while(true){} use. >>> But I might not fully understand the API. Here is what you would normally >>> do with measured values: >>> >>> - Compute an average sliding window >>> - Compute statistic measures such as variance and deviation >>> >>> To do that a ring-buffer is usually used to store N previous sample >>> points. It works about like this everytime you have a sample point. >>> >>> buffer[i] = samplePoint; >>> i = (i+1)%buffer.length; >>> >>> And then you compute/draw whatever from that buffer. A sliding average >>> can be efficiently implemented this way by subtracting the old value from >>> the average and adding the new value, like so: >>> >>> sumAvg += samplePoint - buffer[i]; >>> average = sumAvg/buffer.length; >>> buffer[i] = samplePoint; >>> i = (i+1)%buffer.length; >>> >>> To do that with the query object API I'd imagine you'd do this: >>> >>> var queries = []; >>> var samples = new Float32Array(1024); >>> var sampleIdx = 0; >>> >>> var draw = function(){ >>> var query = var query = ext.createQueryANGLE(); >>> queries.push(query); >>> ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); >>> gl.drawElements(...); >>> ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); >>> >>> while(queries.length > 0){ >>> query = queries[0]; >>> if(ext.getQueryParameterANGLE(query, >>> ext.QUERY_RESULT_AVAILABLE_ANGLE)){ >>> queries.shift(); >>> var timeElapsed = ext.getQueryParameterANGLE(query, >>> ext.QUERY_RESULT_ANGLE); >>> var samples[sampleIdx] = timeElapsed; >>> sampleIdx = (sampleIdx+1)%samples.length; >>> } >>> else{ >>> break; >>> } >>> } >>> } >>> >>> I think that would be fairly acceptable code. Do I miss something? >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Apr 3 10:45:00 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 3 Apr 2013 19:45:00 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: I think it might make sense that if you do callbacks, that the callbacks are tied to requestAnimationFrame. You usually don't care to receive callbacks unless just before you actually would want to work with the captured data right? And usually the next chance you'll get to work with the data is in a requestAnimationFrame callback. On Wed, Apr 3, 2013 at 7:18 PM, Gregg Tavares wrote: > There's another issue with the polling API. It exposes inconsistent > behavior. > > Devs can decide not to check whether a query result is available and just > read the result. For example they could assume if they ended a query last > frame that reading the result next frame will be valid without checking > that it actually is valid. This may work on some % of systems but fail on > another % of systems. It might also fail on the same system depending on > various random factors. > > Adding such inconsistent behavior into WebGL doesn't seem like a good idea. > > > > > > > > On Wed, Apr 3, 2013 at 9:45 AM, Florian B?sch wrote: > >> Well, does the callback proposal actually improve things? Let's see. >> >> var samples = new Float32Array(1024); >> var sampleIdx = 0; >> >> var sampleDone = function(timeElapsed){ >> samples[sampleIdx] = timeElapsed; >> sampleIdx = (sampleIdx+1)%samples.length; >> ext.deleteQueryAngle(this); >> } >> >> var draw = function(){ >> var query = var query = ext.createQueryANGLE(); >> query.onavailable = sampleDone; >> >> ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); >> gl.drawElements(...); >> ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); >> } >> >> I think that's nicer. Less mucking about with with keeping query objects >> in a container. Assuming of course that queries will become available in >> order of things actually completing, and not in some random order. So the >> browser will have to remember the sequency and not call back to it out of >> order. I'm assuming that wouldn't be a problem right? >> >> >> On Wed, Apr 3, 2013 at 6:34 PM, Gregg Tavares wrote: >> >>> Florian, >>> >>> This isn't about whether a good programmer like you can write correct >>> code. It's about whether bad programmers will write code that browser >>> vendors are stuck supporting. >>> >>> The API proposed by ANGLE_timer_query is the same API used for occlusion >>> queries. The only difference is a 3 emums. Bad devs will do this >>> >>> for each object () { >>> drawOccluder(); >>> spinWaitForAnswer(); >>> if (!occluded()) { >>> doHeavyDraw(); >>> } >>> } >>> >>> If that happens to run fast enough on some browser/driver combo they'll >>> ship it. Then users will complain they can't interact with the browser >>> because it's stuck waiting for JavaScript. This is the same reason why the >>> browser vendors are sad there's a synchronous XHR function. It kills UX. >>> They'd get rid of it if they could but MS made that mistake 15 years ago so >>> were stuck with it. Let's not make the same mistake. >>> >>> >>> >>> >>> >>> >>> >>> On Wed, Apr 3, 2013 at 2:55 AM, Florian B?sch wrote: >>> >>>> I don't agree that not having callbacks would lead to while(true){} >>>> use. But I might not fully understand the API. Here is what you would >>>> normally do with measured values: >>>> >>>> - Compute an average sliding window >>>> - Compute statistic measures such as variance and deviation >>>> >>>> To do that a ring-buffer is usually used to store N previous sample >>>> points. It works about like this everytime you have a sample point. >>>> >>>> buffer[i] = samplePoint; >>>> i = (i+1)%buffer.length; >>>> >>>> And then you compute/draw whatever from that buffer. A sliding average >>>> can be efficiently implemented this way by subtracting the old value from >>>> the average and adding the new value, like so: >>>> >>>> sumAvg += samplePoint - buffer[i]; >>>> average = sumAvg/buffer.length; >>>> buffer[i] = samplePoint; >>>> i = (i+1)%buffer.length; >>>> >>>> To do that with the query object API I'd imagine you'd do this: >>>> >>>> var queries = []; >>>> var samples = new Float32Array(1024); >>>> var sampleIdx = 0; >>>> >>>> var draw = function(){ >>>> var query = var query = ext.createQueryANGLE(); >>>> queries.push(query); >>>> ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); >>>> gl.drawElements(...); >>>> ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); >>>> >>>> while(queries.length > 0){ >>>> query = queries[0]; >>>> if(ext.getQueryParameterANGLE(query, >>>> ext.QUERY_RESULT_AVAILABLE_ANGLE)){ >>>> queries.shift(); >>>> var timeElapsed = ext.getQueryParameterANGLE(query, >>>> ext.QUERY_RESULT_ANGLE); >>>> var samples[sampleIdx] = timeElapsed; >>>> sampleIdx = (sampleIdx+1)%samples.length; >>>> } >>>> else{ >>>> break; >>>> } >>>> } >>>> } >>>> >>>> I think that would be fairly acceptable code. Do I miss something? >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bco...@ Wed Apr 3 11:18:20 2013 From: bco...@ (Brian Cornell) Date: Wed, 3 Apr 2013 11:18:20 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: I agree with Ben that this is better without callbacks for a couple of reasons: 1) Callbacks are less flexible because they are necessarily asynchronous. This means that it is impossible to get the results back before your content might be composited. In this case that might not be that useful or even possible on some browsers, but generally callback APIs make it hard to do something that might affect rendering. 2) Callbacks can happen whenever the browser feels like it, even if you don't want them to. This makes it really hard to tightly manage framerate in a performance critical app. You could schedule all of your work very carefully to take up just about all of the free time in a frame, but the browser can then call 1000 callbacks and skip the next frame. There's no way to know how many callbacks are waiting so that you can leave time for them. And if you're really performance critical, your callbacks can't actually do anything, they have to just add something to a queue so that you can do the work somewhere where you are properly tracking the time. As an example, XHRs are actually pretty annoying. They allow you to either block the entire app or process the results whenever the browser feels like it in a callback. A polling API to say "hey, process one XHR right now if you have any waiting" would be awesome, as it would allow the developer to manage timing better. I agree that callbacks are very JavaScript-y, but not everything in JavaScript is well designed for high performance apps. -Brian On Wed, Apr 3, 2013 at 10:45 AM, Florian B?sch wrote: > I think it might make sense that if you do callbacks, that the callbacks > are tied to requestAnimationFrame. You usually don't care to receive > callbacks unless just before you actually would want to work with the > captured data right? And usually the next chance you'll get to work with > the data is in a requestAnimationFrame callback. > > > On Wed, Apr 3, 2013 at 7:18 PM, Gregg Tavares wrote: > >> There's another issue with the polling API. It exposes inconsistent >> behavior. >> >> Devs can decide not to check whether a query result is available and just >> read the result. For example they could assume if they ended a query last >> frame that reading the result next frame will be valid without checking >> that it actually is valid. This may work on some % of systems but fail on >> another % of systems. It might also fail on the same system depending on >> various random factors. >> >> Adding such inconsistent behavior into WebGL doesn't seem like a good >> idea. >> >> >> >> >> >> >> >> On Wed, Apr 3, 2013 at 9:45 AM, Florian B?sch wrote: >> >>> Well, does the callback proposal actually improve things? Let's see. >>> >>> var samples = new Float32Array(1024); >>> var sampleIdx = 0; >>> >>> var sampleDone = function(timeElapsed){ >>> samples[sampleIdx] = timeElapsed; >>> sampleIdx = (sampleIdx+1)%samples.length; >>> ext.deleteQueryAngle(this); >>> } >>> >>> var draw = function(){ >>> var query = var query = ext.createQueryANGLE(); >>> query.onavailable = sampleDone; >>> >>> ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); >>> gl.drawElements(...); >>> ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); >>> } >>> >>> I think that's nicer. Less mucking about with with keeping query objects >>> in a container. Assuming of course that queries will become available in >>> order of things actually completing, and not in some random order. So the >>> browser will have to remember the sequency and not call back to it out of >>> order. I'm assuming that wouldn't be a problem right? >>> >>> >>> On Wed, Apr 3, 2013 at 6:34 PM, Gregg Tavares wrote: >>> >>>> Florian, >>>> >>>> This isn't about whether a good programmer like you can write correct >>>> code. It's about whether bad programmers will write code that browser >>>> vendors are stuck supporting. >>>> >>>> The API proposed by ANGLE_timer_query is the same API used for >>>> occlusion queries. The only difference is a 3 emums. Bad devs will do this >>>> >>>> for each object () { >>>> drawOccluder(); >>>> spinWaitForAnswer(); >>>> if (!occluded()) { >>>> doHeavyDraw(); >>>> } >>>> } >>>> >>>> If that happens to run fast enough on some browser/driver combo they'll >>>> ship it. Then users will complain they can't interact with the browser >>>> because it's stuck waiting for JavaScript. This is the same reason why the >>>> browser vendors are sad there's a synchronous XHR function. It kills UX. >>>> They'd get rid of it if they could but MS made that mistake 15 years ago so >>>> were stuck with it. Let's not make the same mistake. >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> On Wed, Apr 3, 2013 at 2:55 AM, Florian B?sch wrote: >>>> >>>>> I don't agree that not having callbacks would lead to while(true){} >>>>> use. But I might not fully understand the API. Here is what you would >>>>> normally do with measured values: >>>>> >>>>> - Compute an average sliding window >>>>> - Compute statistic measures such as variance and deviation >>>>> >>>>> To do that a ring-buffer is usually used to store N previous sample >>>>> points. It works about like this everytime you have a sample point. >>>>> >>>>> buffer[i] = samplePoint; >>>>> i = (i+1)%buffer.length; >>>>> >>>>> And then you compute/draw whatever from that buffer. A sliding average >>>>> can be efficiently implemented this way by subtracting the old value from >>>>> the average and adding the new value, like so: >>>>> >>>>> sumAvg += samplePoint - buffer[i]; >>>>> average = sumAvg/buffer.length; >>>>> buffer[i] = samplePoint; >>>>> i = (i+1)%buffer.length; >>>>> >>>>> To do that with the query object API I'd imagine you'd do this: >>>>> >>>>> var queries = []; >>>>> var samples = new Float32Array(1024); >>>>> var sampleIdx = 0; >>>>> >>>>> var draw = function(){ >>>>> var query = var query = ext.createQueryANGLE(); >>>>> queries.push(query); >>>>> ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); >>>>> gl.drawElements(...); >>>>> ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); >>>>> >>>>> while(queries.length > 0){ >>>>> query = queries[0]; >>>>> if(ext.getQueryParameterANGLE(query, >>>>> ext.QUERY_RESULT_AVAILABLE_ANGLE)){ >>>>> queries.shift(); >>>>> var timeElapsed = ext.getQueryParameterANGLE(query, >>>>> ext.QUERY_RESULT_ANGLE); >>>>> var samples[sampleIdx] = timeElapsed; >>>>> sampleIdx = (sampleIdx+1)%samples.length; >>>>> } >>>>> else{ >>>>> break; >>>>> } >>>>> } >>>>> } >>>>> >>>>> I think that would be fairly acceptable code. Do I miss something? >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Wed Apr 3 11:24:28 2013 From: jgi...@ (Jeff Gilbert) Date: Wed, 3 Apr 2013 11:24:28 -0700 (PDT) Subject: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test In-Reply-To: Message-ID: <1402998755.1906246.1365013468046.JavaMail.root@mozilla.com> It's true, but this test generates over a thousand different draw calls, which is unusual. I don't think it's a good idea for the test to mandate something like this succeeds, since that'll mean adding flushing heuristics to the implementation. -Jeff ----- Original Message ----- From: "Gregg Tavares" To: "Jeff Gilbert" Cc: "public webgl" Sent: Wednesday, April 3, 2013 9:13:43 AM Subject: Re: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test IIRC the tests have been written to use a reasonable (less than 60meg) amount of memory. The spec unfortunately makes it possible for every function to generate GL_OUT_OF_MEMORY period and still be technically spec compliant. In other words, according to the spec an implementation could to this GLenum glGetErrror() { return GL_OUT_OF_MEMORY; } void glBindBuffer(...) { /* no-op */ } void glBindTexture(...) { /* no-op */ } void glTexImage2D(...) { /* no-op */ } void glDrawArrays(...) { /* no-op */ } And be valid according to the spec :-( On Wed, Apr 3, 2013 at 12:25 AM, Jeff Gilbert < jgilbert...@ > wrote: On some mobile devices, we're hitting a couple errors followed by a gl.OUT_OF_MEMORY error in the "check reading with lots of drawing" section. This is AFAIK spec-compliant behavior, so I believe the test should be changed to gl.flush() after each draw call, which seems to have fixed it for me. Thoughts? -Jeff ----------------------------------------------------------- You are currently subscribed to public_webgl...@ . To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Wed Apr 3 11:40:36 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 3 Apr 2013 20:40:36 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Wed, Apr 3, 2013 at 8:18 PM, Brian Cornell wrote: > 1) Callbacks are less flexible because they are necessarily asynchronous. > This means that it is impossible to get the results back before your > content might be composited. In this case that might not be that useful or > even possible on some browsers, but generally callback APIs make it hard to > do something that might affect rendering. > Since the goal of the query API is to make it possible to get timing results without blocking (i.e. calling gl.finish()), I don't really see the utility in requiring an API semantic enabling blocking. If you want to block until something has finished, just call gl.finish(). If you want to time it, call performance.now(). The whole reason timer queries exist is because something is executed off in some process/driver in a rendering queue which you didn't want to block. > 2) Callbacks can happen whenever the browser feels like it, even if you > don't want them to. This makes it really hard to tightly manage framerate > in a performance critical app. You could schedule all of your work very > carefully to take up just about all of the free time in a frame, but the > browser can then call 1000 callbacks and skip the next frame. There's no > way to know how many callbacks are waiting so that you can leave time for > them. And if you're really performance critical, your callbacks can't > actually do anything, they have to just add something to a queue so that > you can do the work somewhere where you are properly tracking the time. > A realistic usecase can't work with single timing values. You'd just flipflop between states every frame, and that wouldn't work. You will need to apply some averaging and statistics. To do that you will need to capture things in a buffer. Capturing things in a buffer, and then working with that buffer when you get a callback to requestAnimation frame, is exactly the same that you would do anyways. I don't see a difference of one preventing the other. I think either polling or callback properly handled amount to the exact identical same. One just seems a little less to write and less prone to abuse by beginners. It can be said however that there is an assumption that you can do real work in event callbacks (also regarding clicks and so on). This is not really true, you should not do that. That's unfortunately another mistake, shared not just by beginners. > I agree that callbacks are very JavaScript-y, but not everything in > JavaScript is well designed for high performance apps. > requestAnimationFrame is a callback API and seems to work pretty fine. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Apr 3 11:51:12 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 3 Apr 2013 20:51:12 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: Btw. can somebody present a good usecase for a deadspinner? On Wed, Apr 3, 2013 at 8:40 PM, Florian B?sch wrote: > On Wed, Apr 3, 2013 at 8:18 PM, Brian Cornell wrote: > >> 1) Callbacks are less flexible because they are necessarily asynchronous. >> This means that it is impossible to get the results back before your >> content might be composited. In this case that might not be that useful or >> even possible on some browsers, but generally callback APIs make it hard to >> do something that might affect rendering. >> > Since the goal of the query API is to make it possible to get timing > results without blocking (i.e. calling gl.finish()), I don't really see the > utility in requiring an API semantic enabling blocking. If you want to > block until something has finished, just call gl.finish(). If you want to > time it, call performance.now(). The whole reason timer queries exist is > because something is executed off in some process/driver in a rendering > queue which you didn't want to block. > > >> 2) Callbacks can happen whenever the browser feels like it, even if you >> don't want them to. This makes it really hard to tightly manage framerate >> in a performance critical app. You could schedule all of your work very >> carefully to take up just about all of the free time in a frame, but the >> browser can then call 1000 callbacks and skip the next frame. There's no >> way to know how many callbacks are waiting so that you can leave time for >> them. And if you're really performance critical, your callbacks can't >> actually do anything, they have to just add something to a queue so that >> you can do the work somewhere where you are properly tracking the time. >> > A realistic usecase can't work with single timing values. You'd just > flipflop between states every frame, and that wouldn't work. You will need > to apply some averaging and statistics. To do that you will need to capture > things in a buffer. Capturing things in a buffer, and then working with > that buffer when you get a callback to requestAnimation frame, is exactly > the same that you would do anyways. I don't see a difference of one > preventing the other. I think either polling or callback properly handled > amount to the exact identical same. One just seems a little less to write > and less prone to abuse by beginners. > > It can be said however that there is an assumption that you can do real > work in event callbacks (also regarding clicks and so on). This is not > really true, you should not do that. That's unfortunately another mistake, > shared not just by beginners. > > >> I agree that callbacks are very JavaScript-y, but not everything in >> JavaScript is well designed for high performance apps. >> > requestAnimationFrame is a callback API and seems to work pretty fine. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Wed Apr 3 12:49:45 2013 From: ben...@ (Ben Vanik) Date: Wed, 3 Apr 2013 12:49:45 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: The difference between APIs like this and rAF is the frequency of use. There may be 100-1000 timers in a single frame, leading to 100-1000 callbacks. rAF is 1/frame. Apples and oranges different. I can understand how most Javascript developers (and even browser implementers are oblivious to the overhead imposed by the 'javascripty' ways of doing things - most pages don't require (and shouldn't require) anyone to know. But when you're pushing the bounds of the platform you notice very fast and it's something that's often impossible to work around. In the case of Chrome, a single callback from the browser into user javascript can have anywhere from .05ms to .5ms of overhead -- not much if you've got a few a frame for things like network responses/etc - but if you've got 1000 coming back you've just blown your entire frame time. Not to mention the risk of additional allocations required to make the callbacks and the GC time this could impose. We requested this extension to target specific use cases around high-performance applications. If the API is designed in such a way to prevent the use in high-performance applications, it's not going to be worth it. So I'm suggesting that you all step back from the callback cliff and instead look at what the problem is and how it can be solved without making the whole endeavor useless. The way I see it, the query API would work like this in a browser such as Chrome where rendering occurs in another thread (though it can be done similarly for other implementations): - user js runs init: - createQuery() - added to command buffer to send over to the gpu process - stashed in a 'query map' on the renderer side - user js runs frame: - beginQuery() - drawElements() - endQuery() - commands added to buffer, sent to gpu process - queryCounter() - returns the value of the renderer-side query object immediately - no blocking - gpu process: - run command buffer, see active timers, schedule them for processing - for each scheduled counter: query, if available then queue for sending back to renderer in a batch - renderer message from gpu: - for each updated query: - find in query map, set value - user js runs frame: - queryCounter() - returns the new value that was just set There's no way to spin lock here, as the query results are never made available in the same tick that requested them nor will they ever change value inside of a tick. As I said before, any loop trying to test them will be reduced to a while(true); and not work anywhere. The spec can be revised to say that counter values cannot change within a js tick. The difference here vs. user callbacks is that the application can schedule when the counters are queried and - more importantly - if they are queried at all. There's no more overhead spent doing more native-to-js transitions than the application wants, and it happens when the application allows it. This fact *must not be overlooked* - it's already hard enough to build a jank-free application in the browser. For the use cases this API is designed for - which are those that we intend to use it for - this design is acceptable. It allows us to do things that would be impossible with callbacks, such as aggressively timing things but only reading the timers back if we decide post-hoc that the frame was slow. So again, I propose keeping the API as is, with a spec note talking about when query values are allowed to change. For those providing feedback who have never needed an API like this please understand that there are scenarios that exist that are beyond the trivial examples in the spec, and 'webifying' it for the sake of trying to match the convention used by other APIs with completely different usage and semantics is not doing anyone any favors. On Wed, Apr 3, 2013 at 11:51 AM, Florian B?sch wrote: > Btw. can somebody present a good usecase for a deadspinner? > > > On Wed, Apr 3, 2013 at 8:40 PM, Florian B?sch wrote: > >> On Wed, Apr 3, 2013 at 8:18 PM, Brian Cornell wrote: >> >>> 1) Callbacks are less flexible because they are necessarily >>> asynchronous. This means that it is impossible to get the results back >>> before your content might be composited. In this case that might not be >>> that useful or even possible on some browsers, but generally callback APIs >>> make it hard to do something that might affect rendering. >>> >> Since the goal of the query API is to make it possible to get timing >> results without blocking (i.e. calling gl.finish()), I don't really see the >> utility in requiring an API semantic enabling blocking. If you want to >> block until something has finished, just call gl.finish(). If you want to >> time it, call performance.now(). The whole reason timer queries exist is >> because something is executed off in some process/driver in a rendering >> queue which you didn't want to block. >> >> >>> 2) Callbacks can happen whenever the browser feels like it, even if you >>> don't want them to. This makes it really hard to tightly manage framerate >>> in a performance critical app. You could schedule all of your work very >>> carefully to take up just about all of the free time in a frame, but the >>> browser can then call 1000 callbacks and skip the next frame. There's no >>> way to know how many callbacks are waiting so that you can leave time for >>> them. And if you're really performance critical, your callbacks can't >>> actually do anything, they have to just add something to a queue so that >>> you can do the work somewhere where you are properly tracking the time. >>> >> A realistic usecase can't work with single timing values. You'd just >> flipflop between states every frame, and that wouldn't work. You will need >> to apply some averaging and statistics. To do that you will need to capture >> things in a buffer. Capturing things in a buffer, and then working with >> that buffer when you get a callback to requestAnimation frame, is exactly >> the same that you would do anyways. I don't see a difference of one >> preventing the other. I think either polling or callback properly handled >> amount to the exact identical same. One just seems a little less to write >> and less prone to abuse by beginners. >> >> It can be said however that there is an assumption that you can do real >> work in event callbacks (also regarding clicks and so on). This is not >> really true, you should not do that. That's unfortunately another mistake, >> shared not just by beginners. >> >> >>> I agree that callbacks are very JavaScript-y, but not everything in >>> JavaScript is well designed for high performance apps. >>> >> requestAnimationFrame is a callback API and seems to work pretty fine. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Apr 3 13:04:46 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 3 Apr 2013 22:04:46 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: I don't have any personal issue with the API style either way, if you say callbacks are too slow, fine. Let's not do callbacks. I think that either API style has its pitfalls for beginners. On Wed, Apr 3, 2013 at 9:49 PM, Ben Vanik wrote: > The way I see it, the query API would work like this in a browser such as > Chrome where rendering occurs in another thread (though it can be done > similarly for other implementations): > > - user js runs init: > - createQuery() > - added to command buffer to send over to the gpu process > - stashed in a 'query map' on the renderer side > - user js runs frame: > - beginQuery() > - drawElements() > - endQuery() > - commands added to buffer, sent to gpu process > - queryCounter() > - returns the value of the renderer-side query object immediately - no > blocking > - gpu process: > - run command buffer, see active timers, schedule them for processing > - for each scheduled counter: query, if available then queue for > sending back to renderer in a batch > - renderer message from gpu: > - for each updated query: > - find in query map, set value > - user js runs frame: > - queryCounter() > - returns the new value that was just set > I don't understand how you could get accurate timings with just one query object for every frame. By the time you get to poll the value, there might have elapsed multiple frames, but you only have one state. querycounter doesn't capture the actual render time since it returns immediately without blocking. So wouldn't you have to allocate a new query object each frame? Isn't that also gonna be a killjoy for jerky animation? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Wed Apr 3 13:16:10 2013 From: ben...@ (Ben Vanik) Date: Wed, 3 Apr 2013 13:16:10 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: You don't use one per frame - you use many. That's what the simple examples don't show. A typical frame in a complex scene has many nested drawing batches - like for each pass for each depth mode for each shader for each texture for each buffer etc. You put timers around those things - sometimes 100+. Since you'll want to support high latency you'll want a couple sets of these timers. For the application we're building there may be 1000+ timers in flight at any given time. Just as you pipeline readback from framebuffers/etc so that you aren't blocking the GPU, you schedule your timer readback the same way -- on frame N you are checking to see if the timers from frame N-1 or N-2 are available yet. And using clever querying you can quickly check all of them -- for example if the results of the last timer from frame N-1 is available then you know all the timers from frame N-2 are available too -- no need to check them. When it comes to getting the values out it varies what you actually want to get. For performance testing you may query all timers every frame. For runtime testing deployed to real user machines most frames you may only query the outermost timer - if it says the frame took <10ms or draw (or some other threshold) you can just ignore the rest. But if it did take >Nms you can start searching down the timer tree to find what took the time. A simple binary search can then tell you exactly what kind of operation was slow for that user and allow you to report that back to a diagnostics service, change rendering quality, or even switch rendering engines to ensure the user has the best experience. This kind of complex scenario is an example of one that we would like to ship but would be unable to if the overhead imposed impacted performance significantly. When building applications that try to schedule every fractional millisecond of the main javascript loop any additional wasted time that's not providing value is unacceptable. On Wed, Apr 3, 2013 at 1:04 PM, Florian B?sch wrote: > I don't have any personal issue with the API style either way, if you say > callbacks are too slow, fine. Let's not do callbacks. I think that either > API style has its pitfalls for beginners. > > > On Wed, Apr 3, 2013 at 9:49 PM, Ben Vanik wrote: > >> The way I see it, the query API would work like this in a browser such as >> Chrome where rendering occurs in another thread (though it can be done >> similarly for other implementations): >> >> - user js runs init: >> - createQuery() >> - added to command buffer to send over to the gpu process >> - stashed in a 'query map' on the renderer side >> - user js runs frame: >> - beginQuery() >> - drawElements() >> - endQuery() >> - commands added to buffer, sent to gpu process >> - queryCounter() >> - returns the value of the renderer-side query object immediately - >> no blocking >> - gpu process: >> - run command buffer, see active timers, schedule them for processing >> - for each scheduled counter: query, if available then queue for >> sending back to renderer in a batch >> - renderer message from gpu: >> - for each updated query: >> - find in query map, set value >> - user js runs frame: >> - queryCounter() >> - returns the new value that was just set >> > > I don't understand how you could get accurate timings with just one query > object for every frame. By the time you get to poll the value, there might > have elapsed multiple frames, but you only have one state. querycounter > doesn't capture the actual render time since it returns immediately without > blocking. So wouldn't you have to allocate a new query object each frame? > Isn't that also gonna be a killjoy for jerky animation? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Apr 3 13:24:03 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 3 Apr 2013 22:24:03 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: Far as I understand it, one query object corresponds to a start and end time. Two integer values in nanoseconds. That means that you cannot use the same query object at the same place over and over. You might overwrite previous measurement. Until you actually have a measurement by polling that query object, you cannot use it again, correct? So you're going to allocate thousands of query objects each frame? On Wed, Apr 3, 2013 at 10:16 PM, Ben Vanik wrote: > You don't use one per frame - you use many. That's what the simple > examples don't show. > > A typical frame in a complex scene has many nested drawing batches - like > for each pass for each depth mode for each shader for each texture for each > buffer etc. You put timers around those things - sometimes 100+. Since > you'll want to support high latency you'll want a couple sets of these > timers. For the application we're building there may be 1000+ timers in > flight at any given time. > > Just as you pipeline readback from framebuffers/etc so that you aren't > blocking the GPU, you schedule your timer readback the same way -- on frame > N you are checking to see if the timers from frame N-1 or N-2 are available > yet. And using clever querying you can quickly check all of them -- for > example if the results of the last timer from frame N-1 is available then > you know all the timers from frame N-2 are available too -- no need to > check them. > > When it comes to getting the values out it varies what you actually want > to get. For performance testing you may query all timers every frame. For > runtime testing deployed to real user machines most frames you may only > query the outermost timer - if it says the frame took <10ms or draw (or > some other threshold) you can just ignore the rest. But if it did take >Nms > you can start searching down the timer tree to find what took the time. A > simple binary search can then tell you exactly what kind of operation was > slow for that user and allow you to report that back to a diagnostics > service, change rendering quality, or even switch rendering engines to > ensure the user has the best experience. > > This kind of complex scenario is an example of one that we would like to > ship but would be unable to if the overhead imposed impacted performance > significantly. When building applications that try to schedule every > fractional millisecond of the main javascript loop any additional wasted > time that's not providing value is unacceptable. > > > > On Wed, Apr 3, 2013 at 1:04 PM, Florian B?sch wrote: > >> I don't have any personal issue with the API style either way, if you say >> callbacks are too slow, fine. Let's not do callbacks. I think that either >> API style has its pitfalls for beginners. >> >> >> On Wed, Apr 3, 2013 at 9:49 PM, Ben Vanik wrote: >> >>> The way I see it, the query API would work like this in a browser such >>> as Chrome where rendering occurs in another thread (though it can be done >>> similarly for other implementations): >>> >>> - user js runs init: >>> - createQuery() >>> - added to command buffer to send over to the gpu process >>> - stashed in a 'query map' on the renderer side >>> - user js runs frame: >>> - beginQuery() >>> - drawElements() >>> - endQuery() >>> - commands added to buffer, sent to gpu process >>> - queryCounter() >>> - returns the value of the renderer-side query object immediately - >>> no blocking >>> - gpu process: >>> - run command buffer, see active timers, schedule them for processing >>> - for each scheduled counter: query, if available then queue for >>> sending back to renderer in a batch >>> - renderer message from gpu: >>> - for each updated query: >>> - find in query map, set value >>> - user js runs frame: >>> - queryCounter() >>> - returns the new value that was just set >>> >> >> I don't understand how you could get accurate timings with just one query >> object for every frame. By the time you get to poll the value, there might >> have elapsed multiple frames, but you only have one state. querycounter >> doesn't capture the actual render time since it returns immediately without >> blocking. So wouldn't you have to allocate a new query object each frame? >> Isn't that also gonna be a killjoy for jerky animation? >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Wed Apr 3 13:39:17 2013 From: gma...@ (Gregg Tavares) Date: Wed, 3 Apr 2013 13:39:17 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: Another way around this issue is to leave the API as is but (1) require that you must get a true result from checking the result is available before checking the result will return the correct value This would prevent assuming the result is available without actually checking that it is available. (2) require that implementation cache the result and available status outside JavaScript events. This would make it impossible to spin loop because the it would never change. Any spin loop would loop forever On Wed, Apr 3, 2013 at 1:24 PM, Florian B?sch wrote: > Far as I understand it, one query object corresponds to a start and end > time. Two integer values in nanoseconds. > > That means that you cannot use the same query object at the same place > over and over. You might overwrite previous measurement. Until you actually > have a measurement by polling that query object, you cannot use it again, > correct? So you're going to allocate thousands of query objects each frame? > > > On Wed, Apr 3, 2013 at 10:16 PM, Ben Vanik wrote: > >> You don't use one per frame - you use many. That's what the simple >> examples don't show. >> >> A typical frame in a complex scene has many nested drawing batches - like >> for each pass for each depth mode for each shader for each texture for each >> buffer etc. You put timers around those things - sometimes 100+. Since >> you'll want to support high latency you'll want a couple sets of these >> timers. For the application we're building there may be 1000+ timers in >> flight at any given time. >> >> Just as you pipeline readback from framebuffers/etc so that you aren't >> blocking the GPU, you schedule your timer readback the same way -- on frame >> N you are checking to see if the timers from frame N-1 or N-2 are available >> yet. And using clever querying you can quickly check all of them -- for >> example if the results of the last timer from frame N-1 is available then >> you know all the timers from frame N-2 are available too -- no need to >> check them. >> >> When it comes to getting the values out it varies what you actually want >> to get. For performance testing you may query all timers every frame. For >> runtime testing deployed to real user machines most frames you may only >> query the outermost timer - if it says the frame took <10ms or draw (or >> some other threshold) you can just ignore the rest. But if it did take >Nms >> you can start searching down the timer tree to find what took the time. A >> simple binary search can then tell you exactly what kind of operation was >> slow for that user and allow you to report that back to a diagnostics >> service, change rendering quality, or even switch rendering engines to >> ensure the user has the best experience. >> >> This kind of complex scenario is an example of one that we would like to >> ship but would be unable to if the overhead imposed impacted performance >> significantly. When building applications that try to schedule every >> fractional millisecond of the main javascript loop any additional wasted >> time that's not providing value is unacceptable. >> >> >> >> On Wed, Apr 3, 2013 at 1:04 PM, Florian B?sch wrote: >> >>> I don't have any personal issue with the API style either way, if you >>> say callbacks are too slow, fine. Let's not do callbacks. I think that >>> either API style has its pitfalls for beginners. >>> >>> >>> On Wed, Apr 3, 2013 at 9:49 PM, Ben Vanik wrote: >>> >>>> The way I see it, the query API would work like this in a browser such >>>> as Chrome where rendering occurs in another thread (though it can be done >>>> similarly for other implementations): >>>> >>>> - user js runs init: >>>> - createQuery() >>>> - added to command buffer to send over to the gpu process >>>> - stashed in a 'query map' on the renderer side >>>> - user js runs frame: >>>> - beginQuery() >>>> - drawElements() >>>> - endQuery() >>>> - commands added to buffer, sent to gpu process >>>> - queryCounter() >>>> - returns the value of the renderer-side query object immediately - >>>> no blocking >>>> - gpu process: >>>> - run command buffer, see active timers, schedule them for processing >>>> - for each scheduled counter: query, if available then queue for >>>> sending back to renderer in a batch >>>> - renderer message from gpu: >>>> - for each updated query: >>>> - find in query map, set value >>>> - user js runs frame: >>>> - queryCounter() >>>> - returns the new value that was just set >>>> >>> >>> I don't understand how you could get accurate timings with just one >>> query object for every frame. By the time you get to poll the value, there >>> might have elapsed multiple frames, but you only have one state. >>> querycounter doesn't capture the actual render time since it returns >>> immediately without blocking. So wouldn't you have to allocate a new query >>> object each frame? Isn't that also gonna be a killjoy for jerky animation? >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Wed Apr 3 13:41:08 2013 From: ben...@ (Ben Vanik) Date: Wed, 3 Apr 2013 13:41:08 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: Yeah - that's what I was saying above. Both of these are acceptable and still allow the API to be used efficiently. On Wed, Apr 3, 2013 at 1:39 PM, Gregg Tavares wrote: > Another way around this issue is to leave the API as is but > > (1) require that you must get a true result from checking the result is > available before checking the result will return the correct value > > This would prevent assuming the result is available without actually > checking that it is available. > > (2) require that implementation cache the result and available status > outside JavaScript events. > > This would make it impossible to spin loop because the it would never > change. Any spin loop would loop forever > > > > > > > On Wed, Apr 3, 2013 at 1:24 PM, Florian B?sch wrote: > >> Far as I understand it, one query object corresponds to a start and end >> time. Two integer values in nanoseconds. >> >> That means that you cannot use the same query object at the same place >> over and over. You might overwrite previous measurement. Until you actually >> have a measurement by polling that query object, you cannot use it again, >> correct? So you're going to allocate thousands of query objects each frame? >> >> >> On Wed, Apr 3, 2013 at 10:16 PM, Ben Vanik wrote: >> >>> You don't use one per frame - you use many. That's what the simple >>> examples don't show. >>> >>> A typical frame in a complex scene has many nested drawing batches - >>> like for each pass for each depth mode for each shader for each texture for >>> each buffer etc. You put timers around those things - sometimes 100+. Since >>> you'll want to support high latency you'll want a couple sets of these >>> timers. For the application we're building there may be 1000+ timers in >>> flight at any given time. >>> >>> Just as you pipeline readback from framebuffers/etc so that you aren't >>> blocking the GPU, you schedule your timer readback the same way -- on frame >>> N you are checking to see if the timers from frame N-1 or N-2 are available >>> yet. And using clever querying you can quickly check all of them -- for >>> example if the results of the last timer from frame N-1 is available then >>> you know all the timers from frame N-2 are available too -- no need to >>> check them. >>> >>> When it comes to getting the values out it varies what you actually want >>> to get. For performance testing you may query all timers every frame. For >>> runtime testing deployed to real user machines most frames you may only >>> query the outermost timer - if it says the frame took <10ms or draw (or >>> some other threshold) you can just ignore the rest. But if it did take >Nms >>> you can start searching down the timer tree to find what took the time. A >>> simple binary search can then tell you exactly what kind of operation was >>> slow for that user and allow you to report that back to a diagnostics >>> service, change rendering quality, or even switch rendering engines to >>> ensure the user has the best experience. >>> >>> This kind of complex scenario is an example of one that we would like to >>> ship but would be unable to if the overhead imposed impacted performance >>> significantly. When building applications that try to schedule every >>> fractional millisecond of the main javascript loop any additional wasted >>> time that's not providing value is unacceptable. >>> >>> >>> >>> On Wed, Apr 3, 2013 at 1:04 PM, Florian B?sch wrote: >>> >>>> I don't have any personal issue with the API style either way, if you >>>> say callbacks are too slow, fine. Let's not do callbacks. I think that >>>> either API style has its pitfalls for beginners. >>>> >>>> >>>> On Wed, Apr 3, 2013 at 9:49 PM, Ben Vanik wrote: >>>> >>>>> The way I see it, the query API would work like this in a browser such >>>>> as Chrome where rendering occurs in another thread (though it can be done >>>>> similarly for other implementations): >>>>> >>>>> - user js runs init: >>>>> - createQuery() >>>>> - added to command buffer to send over to the gpu process >>>>> - stashed in a 'query map' on the renderer side >>>>> - user js runs frame: >>>>> - beginQuery() >>>>> - drawElements() >>>>> - endQuery() >>>>> - commands added to buffer, sent to gpu process >>>>> - queryCounter() >>>>> - returns the value of the renderer-side query object immediately >>>>> - no blocking >>>>> - gpu process: >>>>> - run command buffer, see active timers, schedule them for >>>>> processing >>>>> - for each scheduled counter: query, if available then queue for >>>>> sending back to renderer in a batch >>>>> - renderer message from gpu: >>>>> - for each updated query: >>>>> - find in query map, set value >>>>> - user js runs frame: >>>>> - queryCounter() >>>>> - returns the new value that was just set >>>>> >>>> >>>> I don't understand how you could get accurate timings with just one >>>> query object for every frame. By the time you get to poll the value, there >>>> might have elapsed multiple frames, but you only have one state. >>>> querycounter doesn't capture the actual render time since it returns >>>> immediately without blocking. So wouldn't you have to allocate a new query >>>> object each frame? Isn't that also gonna be a killjoy for jerky animation? >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rem...@ Wed Apr 3 13:44:13 2013 From: Rem...@ (Arnaud, Remi) Date: Wed, 3 Apr 2013 20:44:13 +0000 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: Message-ID: Still thinking about this. I still think that this extension can be simplified buy using QueryCounter only. QueryCounter does not halves the number of queries, it just adds one (which does not matter as there will be 100s of queries usually) BeginQuery (A) ..A.. EndQuery() BeginQuery(B) ?B.. EndQuery() Vs QueryCounter(A) ..A.. QueryCounter(B) ..B.. QueryCounter(C) On the other end, Begin/End will require twice the amount of API calls 100 time interval measure requires 200 begin/endquery calls 100 time interval measure require 101 queryCounter calls On a use case, at rung time, I would want to first know the total time of the frame before looking into the detail ( that I can use to adjust parameter for the next frame). Total time is LastTimer ? FirstTimer using QueryCounter, but much harder to get with Begin/EndQuery -> need to add ALL values. I do understand the results between Begin/End and QueryCounter may be different, but it is not relevant as the spec says, it is just measurement errors that the application will ignore anyways Regards -- Remi From: Ben Vanik > Date: Tuesday, April 2, 2013 5:19 PM To: Kenneth Russell > Cc: R?mi Arnaud >, "public_webgl...@" > Subject: Re: [Public WebGL] For review: ANGLE_timer_query extension The two APIs provide two different values -- glQueryCounter gives you a timestamp where glBeginQuery/glEndQuery give you a time elapsed. There are scenarios where both are interesting: if you're trying to get many elapsed times (such as timing draw calls/etc) then using the begin/end methods halves the number of query objects you need vs. trying to do it yourself via queryCounter. There's also the potential for the values retrieved from either to be different: the spec allows for different internal timing mechanisms to be used for both. I'm not sure if this is the case in reality, but it is allowed. On Tue, Apr 2, 2013 at 5:03 PM, Kenneth Russell > wrote: Good question. As the primary author of the ANGLE_timer_query extension, Ben Vanik should answer it. Note that beginQuery and endQuery will definitely be needed in the OpenGL ES 3.0 upgrade, since they support occlusion and primitive queries. -Ken On Tue, Apr 2, 2013 at 4:51 PM, Arnaud, Remi > wrote: > I was wondering if beginQueryANGLE and endQueryANGLE are needed, seems > like queryCounterANGLE alone can cover all use cases? > > Regards > -- Remi > > On 4/2/13 4:33 PM, "Kenneth Russell" > wrote: > >> >>The MapsGL team has requested for some time that the ANGLE_timer_query >>extension be exposed to WebGL. The primary use case is to allow tools >>to be written which identify performance problems in WebGL >>applications. >> >>Please review the proposal and send comments to the list: >> >>http://www.khronos.org/registry/webgl/extensions/proposals/ANGLE_timer_que >>ry/ >> >>Note that the planned upgrade of WebGL to the OpenGL ES 3.0 API will >>pull the query functions into the core. This extension becomes much >>smaller when applied to that API version. >> >>Thanks, >> >>-Ken >> >>----------------------------------------------------------- >>You are currently subscribed to public_webgl...@. >>To unsubscribe, send an email to majordomo...@ with >>the following command in the body of your email: >>unsubscribe public_webgl >>----------------------------------------------------------- >> >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Apr 3 13:54:20 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 3 Apr 2013 22:54:20 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: I'm taking another stab at this, is this correct intended use? var queries = []; var samples = new Float32Array(1024); var sampleIdx = 0; var sumAvg=0; var draw = function(){ *var query = ext.createQueryANGLE();* queries.push(query); ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); gl.drawElements(...); ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); while(queries.length > 0){ query = queries[0]; if(ext.getQueryParameterANGLE(query, ext.QUERY_RESULT_AVAILABLE_ANGLE)){ queries.shift(); var timeElapsed = ext.getQueryParameterANGLE(query, ext.QUERY_RESULT_ANGLE); *ext.deleteQueryAngle(query);* sumAvg += timeElapsed - samples[sampleIdx]; samples[sampleIdx] = timeElapsed; sampleIdx = (sampleIdx+1)%samples.length; } else{ break; } } } Or should we avoid creating thousands of queries every frame and start managing query allocation pools and reuse them? var queries = []; var samples = new Float32Array(1024); var sampleIdx = 0; var sumAvg=0; freeQueries = []; for(var i=0; i<123; i++){ freeQueries.push(ext.createQueryANGLE())*;* } var draw = function(){ var query = freeQueries.pop(); queries.push(query); ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); gl.drawElements(...); ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); while(queries.length > 0){ query = queries[0]; if(ext.getQueryParameterANGLE(query, ext.QUERY_RESULT_AVAILABLE_ANGLE)){ freeQueries.push(queries.shift()); var timeElapsed = ext.getQueryParameterANGLE(query, ext.QUERY_RESULT_ANGLE); sumAvg += timeElapsed - samples[sampleIdx]; samples[sampleIdx] = timeElapsed; sampleIdx = (sampleIdx+1)%samples.length; } else{ break; } } } On Wed, Apr 3, 2013 at 10:41 PM, Ben Vanik wrote: > Yeah - that's what I was saying above. Both of these are acceptable and > still allow the API to be used efficiently. > > > On Wed, Apr 3, 2013 at 1:39 PM, Gregg Tavares wrote: > >> Another way around this issue is to leave the API as is but >> >> (1) require that you must get a true result from checking the result is >> available before checking the result will return the correct value >> >> This would prevent assuming the result is available without actually >> checking that it is available. >> >> (2) require that implementation cache the result and available status >> outside JavaScript events. >> >> This would make it impossible to spin loop because the it would never >> change. Any spin loop would loop forever >> >> >> >> >> >> >> On Wed, Apr 3, 2013 at 1:24 PM, Florian B?sch wrote: >> >>> Far as I understand it, one query object corresponds to a start and end >>> time. Two integer values in nanoseconds. >>> >>> That means that you cannot use the same query object at the same place >>> over and over. You might overwrite previous measurement. Until you actually >>> have a measurement by polling that query object, you cannot use it again, >>> correct? So you're going to allocate thousands of query objects each frame? >>> >>> >>> On Wed, Apr 3, 2013 at 10:16 PM, Ben Vanik wrote: >>> >>>> You don't use one per frame - you use many. That's what the simple >>>> examples don't show. >>>> >>>> A typical frame in a complex scene has many nested drawing batches - >>>> like for each pass for each depth mode for each shader for each texture for >>>> each buffer etc. You put timers around those things - sometimes 100+. Since >>>> you'll want to support high latency you'll want a couple sets of these >>>> timers. For the application we're building there may be 1000+ timers in >>>> flight at any given time. >>>> >>>> Just as you pipeline readback from framebuffers/etc so that you aren't >>>> blocking the GPU, you schedule your timer readback the same way -- on frame >>>> N you are checking to see if the timers from frame N-1 or N-2 are available >>>> yet. And using clever querying you can quickly check all of them -- for >>>> example if the results of the last timer from frame N-1 is available then >>>> you know all the timers from frame N-2 are available too -- no need to >>>> check them. >>>> >>>> When it comes to getting the values out it varies what you actually >>>> want to get. For performance testing you may query all timers every frame. >>>> For runtime testing deployed to real user machines most frames you may only >>>> query the outermost timer - if it says the frame took <10ms or draw (or >>>> some other threshold) you can just ignore the rest. But if it did take >Nms >>>> you can start searching down the timer tree to find what took the time. A >>>> simple binary search can then tell you exactly what kind of operation was >>>> slow for that user and allow you to report that back to a diagnostics >>>> service, change rendering quality, or even switch rendering engines to >>>> ensure the user has the best experience. >>>> >>>> This kind of complex scenario is an example of one that we would like >>>> to ship but would be unable to if the overhead imposed impacted performance >>>> significantly. When building applications that try to schedule every >>>> fractional millisecond of the main javascript loop any additional wasted >>>> time that's not providing value is unacceptable. >>>> >>>> >>>> >>>> On Wed, Apr 3, 2013 at 1:04 PM, Florian B?sch wrote: >>>> >>>>> I don't have any personal issue with the API style either way, if you >>>>> say callbacks are too slow, fine. Let's not do callbacks. I think that >>>>> either API style has its pitfalls for beginners. >>>>> >>>>> >>>>> On Wed, Apr 3, 2013 at 9:49 PM, Ben Vanik wrote: >>>>> >>>>>> The way I see it, the query API would work like this in a browser >>>>>> such as Chrome where rendering occurs in another thread (though it can be >>>>>> done similarly for other implementations): >>>>>> >>>>>> - user js runs init: >>>>>> - createQuery() >>>>>> - added to command buffer to send over to the gpu process >>>>>> - stashed in a 'query map' on the renderer side >>>>>> - user js runs frame: >>>>>> - beginQuery() >>>>>> - drawElements() >>>>>> - endQuery() >>>>>> - commands added to buffer, sent to gpu process >>>>>> - queryCounter() >>>>>> - returns the value of the renderer-side query object immediately >>>>>> - no blocking >>>>>> - gpu process: >>>>>> - run command buffer, see active timers, schedule them for >>>>>> processing >>>>>> - for each scheduled counter: query, if available then queue for >>>>>> sending back to renderer in a batch >>>>>> - renderer message from gpu: >>>>>> - for each updated query: >>>>>> - find in query map, set value >>>>>> - user js runs frame: >>>>>> - queryCounter() >>>>>> - returns the new value that was just set >>>>>> >>>>> >>>>> I don't understand how you could get accurate timings with just one >>>>> query object for every frame. By the time you get to poll the value, there >>>>> might have elapsed multiple frames, but you only have one state. >>>>> querycounter doesn't capture the actual render time since it returns >>>>> immediately without blocking. So wouldn't you have to allocate a new query >>>>> object each frame? Isn't that also gonna be a killjoy for jerky animation? >>>>> >>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Wed Apr 3 13:57:58 2013 From: ben...@ (Ben Vanik) Date: Wed, 3 Apr 2013 13:57:58 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: You can reuse queries. And as Remi points out, you can (usually) use marker-style queries if you are tightly timing things. They are a win in all situations, though, such as when you are only timing small regions of calls. On Wed, Apr 3, 2013 at 1:54 PM, Florian B?sch wrote: > I'm taking another stab at this, is this correct intended use? > > var queries = []; > var samples = new Float32Array(1024); > var sampleIdx = 0; > var sumAvg=0; > > var draw = function(){ > *var query = ext.createQueryANGLE();* > queries.push(query); > ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); > gl.drawElements(...); > ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); > > while(queries.length > 0){ > query = queries[0]; > if(ext.getQueryParameterANGLE(query, > ext.QUERY_RESULT_AVAILABLE_ANGLE)){ > queries.shift(); > var timeElapsed = ext.getQueryParameterANGLE(query, > ext.QUERY_RESULT_ANGLE); > *ext.deleteQueryAngle(query);* > > sumAvg += timeElapsed - samples[sampleIdx]; > samples[sampleIdx] = timeElapsed; > sampleIdx = (sampleIdx+1)%samples.length; > } > else{ > break; > } > } > } > > Or should we avoid creating thousands of queries every frame and start > managing query allocation pools and reuse them? > > var queries = []; > var samples = new Float32Array(1024); > var sampleIdx = 0; > var sumAvg=0; > > freeQueries = []; > for(var i=0; i<123; i++){ > freeQueries.push(ext.createQueryANGLE())*;* > } > > var draw = function(){ > var query = freeQueries.pop(); > queries.push(query); > ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); > gl.drawElements(...); > ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); > > while(queries.length > 0){ > query = queries[0]; > if(ext.getQueryParameterANGLE(query, > ext.QUERY_RESULT_AVAILABLE_ANGLE)){ > freeQueries.push(queries.shift()); > var timeElapsed = ext.getQueryParameterANGLE(query, > ext.QUERY_RESULT_ANGLE); > > sumAvg += timeElapsed - samples[sampleIdx]; > samples[sampleIdx] = timeElapsed; > sampleIdx = (sampleIdx+1)%samples.length; > } > else{ > break; > } > } > } > > > On Wed, Apr 3, 2013 at 10:41 PM, Ben Vanik wrote: > >> Yeah - that's what I was saying above. Both of these are acceptable and >> still allow the API to be used efficiently. >> >> >> On Wed, Apr 3, 2013 at 1:39 PM, Gregg Tavares wrote: >> >>> Another way around this issue is to leave the API as is but >>> >>> (1) require that you must get a true result from checking the result is >>> available before checking the result will return the correct value >>> >>> This would prevent assuming the result is available without actually >>> checking that it is available. >>> >>> (2) require that implementation cache the result and available status >>> outside JavaScript events. >>> >>> This would make it impossible to spin loop because the it would never >>> change. Any spin loop would loop forever >>> >>> >>> >>> >>> >>> >>> On Wed, Apr 3, 2013 at 1:24 PM, Florian B?sch wrote: >>> >>>> Far as I understand it, one query object corresponds to a start and end >>>> time. Two integer values in nanoseconds. >>>> >>>> That means that you cannot use the same query object at the same place >>>> over and over. You might overwrite previous measurement. Until you actually >>>> have a measurement by polling that query object, you cannot use it again, >>>> correct? So you're going to allocate thousands of query objects each frame? >>>> >>>> >>>> On Wed, Apr 3, 2013 at 10:16 PM, Ben Vanik wrote: >>>> >>>>> You don't use one per frame - you use many. That's what the simple >>>>> examples don't show. >>>>> >>>>> A typical frame in a complex scene has many nested drawing batches - >>>>> like for each pass for each depth mode for each shader for each texture for >>>>> each buffer etc. You put timers around those things - sometimes 100+. Since >>>>> you'll want to support high latency you'll want a couple sets of these >>>>> timers. For the application we're building there may be 1000+ timers in >>>>> flight at any given time. >>>>> >>>>> Just as you pipeline readback from framebuffers/etc so that you aren't >>>>> blocking the GPU, you schedule your timer readback the same way -- on frame >>>>> N you are checking to see if the timers from frame N-1 or N-2 are available >>>>> yet. And using clever querying you can quickly check all of them -- for >>>>> example if the results of the last timer from frame N-1 is available then >>>>> you know all the timers from frame N-2 are available too -- no need to >>>>> check them. >>>>> >>>>> When it comes to getting the values out it varies what you actually >>>>> want to get. For performance testing you may query all timers every frame. >>>>> For runtime testing deployed to real user machines most frames you may only >>>>> query the outermost timer - if it says the frame took <10ms or draw (or >>>>> some other threshold) you can just ignore the rest. But if it did take >Nms >>>>> you can start searching down the timer tree to find what took the time. A >>>>> simple binary search can then tell you exactly what kind of operation was >>>>> slow for that user and allow you to report that back to a diagnostics >>>>> service, change rendering quality, or even switch rendering engines to >>>>> ensure the user has the best experience. >>>>> >>>>> This kind of complex scenario is an example of one that we would like >>>>> to ship but would be unable to if the overhead imposed impacted performance >>>>> significantly. When building applications that try to schedule every >>>>> fractional millisecond of the main javascript loop any additional wasted >>>>> time that's not providing value is unacceptable. >>>>> >>>>> >>>>> >>>>> On Wed, Apr 3, 2013 at 1:04 PM, Florian B?sch wrote: >>>>> >>>>>> I don't have any personal issue with the API style either way, if you >>>>>> say callbacks are too slow, fine. Let's not do callbacks. I think that >>>>>> either API style has its pitfalls for beginners. >>>>>> >>>>>> >>>>>> On Wed, Apr 3, 2013 at 9:49 PM, Ben Vanik wrote: >>>>>> >>>>>>> The way I see it, the query API would work like this in a browser >>>>>>> such as Chrome where rendering occurs in another thread (though it can be >>>>>>> done similarly for other implementations): >>>>>>> >>>>>>> - user js runs init: >>>>>>> - createQuery() >>>>>>> - added to command buffer to send over to the gpu process >>>>>>> - stashed in a 'query map' on the renderer side >>>>>>> - user js runs frame: >>>>>>> - beginQuery() >>>>>>> - drawElements() >>>>>>> - endQuery() >>>>>>> - commands added to buffer, sent to gpu process >>>>>>> - queryCounter() >>>>>>> - returns the value of the renderer-side query object >>>>>>> immediately - no blocking >>>>>>> - gpu process: >>>>>>> - run command buffer, see active timers, schedule them for >>>>>>> processing >>>>>>> - for each scheduled counter: query, if available then queue for >>>>>>> sending back to renderer in a batch >>>>>>> - renderer message from gpu: >>>>>>> - for each updated query: >>>>>>> - find in query map, set value >>>>>>> - user js runs frame: >>>>>>> - queryCounter() >>>>>>> - returns the new value that was just set >>>>>>> >>>>>> >>>>>> I don't understand how you could get accurate timings with just one >>>>>> query object for every frame. By the time you get to poll the value, there >>>>>> might have elapsed multiple frames, but you only have one state. >>>>>> querycounter doesn't capture the actual render time since it returns >>>>>> immediately without blocking. So wouldn't you have to allocate a new query >>>>>> object each frame? Isn't that also gonna be a killjoy for jerky animation? >>>>>> >>>>> >>>>> >>>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Apr 3 14:06:52 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 3 Apr 2013 23:06:52 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Wed, Apr 3, 2013 at 10:57 PM, Ben Vanik wrote: > You can reuse queries. > Yeah, but should we, or is creating/deleting queries imbdued with some special magic not to kick in GC overhead? -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Wed Apr 3 14:12:07 2013 From: ben...@ (Ben Vanik) Date: Wed, 3 Apr 2013 14:12:07 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: Let me rephrase: you should reuse queries. If you care about performance, you should be pooling just about everything that's expensive to create. Anything that's a non-js object is expensive - like webgl objects. On Wed, Apr 3, 2013 at 2:06 PM, Florian B?sch wrote: > On Wed, Apr 3, 2013 at 10:57 PM, Ben Vanik wrote: > >> You can reuse queries. >> > Yeah, but should we, or is creating/deleting queries imbdued with some > special magic not to kick in GC overhead? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Apr 3 14:15:57 2013 From: kbr...@ (Kenneth Russell) Date: Wed, 3 Apr 2013 14:15:57 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: A few questions: 1) What is the intended use of timer queries? Mainly for profiling applications, or mainly to change run-time behavior of applications? 2) Regardless of whether the API uses polling or callbacks, issuing thousands of timer queries isn't going to work to affect an app's run-time behavior. It will be possible to issue more queries than can be processed in a single frame (again, either by polling or via callbacks). It is inevitable that the app will have to throttle its issuing of timer queries. 3) Apparently, there are difficulties supporting timer queries on tiled rendering architectures. More information should be coming from the OpenGL ES working group soon. The differences in behavior at least require some API changes, and at worst, would prevent timer queries from being exposed to WebGL on these architectures. Does this fact change your opinion about how timer queries are intended to be used? If timer queries were intended only for use in debugging or profiling, that might make it easier to specify them, and to implement consistent behavior across platforms. They could then be specified similarly to WEBGL_debug_renderer_info. The specification could say that the use of timer queries may impose a performance impact on applications, and should not be used in production. A statement like this might make it more feasible to support them in WebGL on mobile platforms. I think the most reliable way to adjust level of detail dynamically would be to make adjustments based on the application's overall frame rate over time, rather than measuring the GPU-side execution time of individual draw calls. What do you think? -Ken On Wed, Apr 3, 2013 at 1:41 PM, Ben Vanik wrote: > Yeah - that's what I was saying above. Both of these are acceptable and > still allow the API to be used efficiently. > > > On Wed, Apr 3, 2013 at 1:39 PM, Gregg Tavares wrote: >> >> Another way around this issue is to leave the API as is but >> >> (1) require that you must get a true result from checking the result is >> available before checking the result will return the correct value >> >> This would prevent assuming the result is available without actually >> checking that it is available. >> >> (2) require that implementation cache the result and available status >> outside JavaScript events. >> >> This would make it impossible to spin loop because the it would never >> change. Any spin loop would loop forever >> >> >> >> >> >> >> On Wed, Apr 3, 2013 at 1:24 PM, Florian B?sch wrote: >>> >>> Far as I understand it, one query object corresponds to a start and end >>> time. Two integer values in nanoseconds. >>> >>> That means that you cannot use the same query object at the same place >>> over and over. You might overwrite previous measurement. Until you actually >>> have a measurement by polling that query object, you cannot use it again, >>> correct? So you're going to allocate thousands of query objects each frame? >>> >>> >>> On Wed, Apr 3, 2013 at 10:16 PM, Ben Vanik wrote: >>>> >>>> You don't use one per frame - you use many. That's what the simple >>>> examples don't show. >>>> >>>> A typical frame in a complex scene has many nested drawing batches - >>>> like for each pass for each depth mode for each shader for each texture for >>>> each buffer etc. You put timers around those things - sometimes 100+. Since >>>> you'll want to support high latency you'll want a couple sets of these >>>> timers. For the application we're building there may be 1000+ timers in >>>> flight at any given time. >>>> >>>> Just as you pipeline readback from framebuffers/etc so that you aren't >>>> blocking the GPU, you schedule your timer readback the same way -- on frame >>>> N you are checking to see if the timers from frame N-1 or N-2 are available >>>> yet. And using clever querying you can quickly check all of them -- for >>>> example if the results of the last timer from frame N-1 is available then >>>> you know all the timers from frame N-2 are available too -- no need to check >>>> them. >>>> >>>> When it comes to getting the values out it varies what you actually want >>>> to get. For performance testing you may query all timers every frame. For >>>> runtime testing deployed to real user machines most frames you may only >>>> query the outermost timer - if it says the frame took <10ms or draw (or some >>>> other threshold) you can just ignore the rest. But if it did take >Nms you >>>> can start searching down the timer tree to find what took the time. A simple >>>> binary search can then tell you exactly what kind of operation was slow for >>>> that user and allow you to report that back to a diagnostics service, change >>>> rendering quality, or even switch rendering engines to ensure the user has >>>> the best experience. >>>> >>>> This kind of complex scenario is an example of one that we would like to >>>> ship but would be unable to if the overhead imposed impacted performance >>>> significantly. When building applications that try to schedule every >>>> fractional millisecond of the main javascript loop any additional wasted >>>> time that's not providing value is unacceptable. >>>> >>>> >>>> >>>> On Wed, Apr 3, 2013 at 1:04 PM, Florian B?sch wrote: >>>>> >>>>> I don't have any personal issue with the API style either way, if you >>>>> say callbacks are too slow, fine. Let's not do callbacks. I think that >>>>> either API style has its pitfalls for beginners. >>>>> >>>>> >>>>> On Wed, Apr 3, 2013 at 9:49 PM, Ben Vanik wrote: >>>>>> >>>>>> The way I see it, the query API would work like this in a browser such >>>>>> as Chrome where rendering occurs in another thread (though it can be done >>>>>> similarly for other implementations): >>>>>> >>>>>> - user js runs init: >>>>>> - createQuery() >>>>>> - added to command buffer to send over to the gpu process >>>>>> - stashed in a 'query map' on the renderer side >>>>>> - user js runs frame: >>>>>> - beginQuery() >>>>>> - drawElements() >>>>>> - endQuery() >>>>>> - commands added to buffer, sent to gpu process >>>>>> - queryCounter() >>>>>> - returns the value of the renderer-side query object immediately >>>>>> - no blocking >>>>>> - gpu process: >>>>>> - run command buffer, see active timers, schedule them for >>>>>> processing >>>>>> - for each scheduled counter: query, if available then queue for >>>>>> sending back to renderer in a batch >>>>>> - renderer message from gpu: >>>>>> - for each updated query: >>>>>> - find in query map, set value >>>>>> - user js runs frame: >>>>>> - queryCounter() >>>>>> - returns the new value that was just set >>>>> >>>>> >>>>> I don't understand how you could get accurate timings with just one >>>>> query object for every frame. By the time you get to poll the value, there >>>>> might have elapsed multiple frames, but you only have one state. >>>>> querycounter doesn't capture the actual render time since it returns >>>>> immediately without blocking. So wouldn't you have to allocate a new query >>>>> object each frame? Isn't that also gonna be a killjoy for jerky animation? >>>> >>>> >>> >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Wed Apr 3 14:17:11 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 3 Apr 2013 23:17:11 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: And its correct to assume that all preceding queries to query N are available if N has been polled and is available? -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Apr 3 14:21:53 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 3 Apr 2013 23:21:53 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Wed, Apr 3, 2013 at 11:15 PM, Kenneth Russell wrote: > I think the most reliable way to adjust level of detail dynamically > would be to make adjustments based on the application's overall frame > rate over time, rather than measuring the GPU-side execution time of > individual draw calls. What do you think? > Measuring at the frame rate level is insufficient for two reasons: 1. Framerate is capped at 60fps, you will want to kick in LOD before you start dropping frames. 2. Not every aspect of a rendering consumes the same time relative on every platform. For instance you might render a bunch of clouds as point sprites (overdraw bound) and terrain (vertex troughput bound). Some platforms might have better fillrate than vertex troughput, others might have better vertex troughput than fillrate for any given application. How do you know if you want to render less clouds or less terrain? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Wed Apr 3 14:28:26 2013 From: gma...@ (Gregg Tavares) Date: Wed, 3 Apr 2013 14:28:26 -0700 Subject: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test In-Reply-To: <1402998755.1906246.1365013468046.JavaMail.root@mozilla.com> References: <1402998755.1906246.1365013468046.JavaMail.root@mozilla.com> Message-ID: On Wed, Apr 3, 2013 at 11:24 AM, Jeff Gilbert wrote: > It's true, but this test generates over a thousand different draw calls, > which is unusual. Unusual for a test? It's not for a standard webgl app. > I don't think it's a good idea for the test to mandate something like this > succeeds, since that'll mean adding flushing heuristics to the > implementation. > Does the device in question run most webgl content otherwise or does it run out of memory on lots of examples where other devices do not? I'd much prefer not supporting WebGL on devices that behave really poorly than pass on those issues to Web devs. My point is, even though the spec allows making every function a no-op and making glGetError return GL_OUT_OF_MEMORY, the OpenGL ES 2.0 conformance tests require more than that even though that's not part of the spec. So, the question is, what should the similar requirements be for the WebGL Conformance Tests? It seems like there should be some minimum requirements. What should they be? > > -Jeff > > ----- Original Message ----- > From: "Gregg Tavares" > To: "Jeff Gilbert" > Cc: "public webgl" > Sent: Wednesday, April 3, 2013 9:13:43 AM > Subject: Re: [Public WebGL] OUT_OF_MEMORY error in > 1.0.1/conformance/reading/read-pixels-test > > > IIRC the tests have been written to use a reasonable (less than 60meg) > amount of memory. > > > The spec unfortunately makes it possible for every function to generate > GL_OUT_OF_MEMORY period and still be technically spec compliant. > > > In other words, according to the spec an implementation could to this > > > GLenum glGetErrror() { return GL_OUT_OF_MEMORY; } > void glBindBuffer(...) { /* no-op */ } > > void glBindTexture(...) { /* no-op */ } > void glTexImage2D(...) { /* no-op */ } > void glDrawArrays(...) { /* no-op */ } > > > And be valid according to the spec :-( > > > > > > > > On Wed, Apr 3, 2013 at 12:25 AM, Jeff Gilbert < jgilbert...@ > > wrote: > > > > On some mobile devices, we're hitting a couple errors followed by a > gl.OUT_OF_MEMORY error in the "check reading with lots of drawing" section. > This is AFAIK spec-compliant behavior, so I believe the test should be > changed to gl.flush() after each draw call, which seems to have fixed it > for me. > > Thoughts? > > -Jeff > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ . > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Apr 3 14:30:09 2013 From: kbr...@ (Kenneth Russell) Date: Wed, 3 Apr 2013 14:30:09 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: http://www.khronos.org/registry/webgl/extensions/proposals/ANGLE_timer_query/ has been updated incorporating these two restrictions. Please review. On Wed, Apr 3, 2013 at 1:41 PM, Ben Vanik wrote: > Yeah - that's what I was saying above. Both of these are acceptable and > still allow the API to be used efficiently. > > > On Wed, Apr 3, 2013 at 1:39 PM, Gregg Tavares wrote: >> >> Another way around this issue is to leave the API as is but >> >> (1) require that you must get a true result from checking the result is >> available before checking the result will return the correct value >> >> This would prevent assuming the result is available without actually >> checking that it is available. >> >> (2) require that implementation cache the result and available status >> outside JavaScript events. >> >> This would make it impossible to spin loop because the it would never >> change. Any spin loop would loop forever >> >> >> >> >> >> >> On Wed, Apr 3, 2013 at 1:24 PM, Florian B?sch wrote: >>> >>> Far as I understand it, one query object corresponds to a start and end >>> time. Two integer values in nanoseconds. >>> >>> That means that you cannot use the same query object at the same place >>> over and over. You might overwrite previous measurement. Until you actually >>> have a measurement by polling that query object, you cannot use it again, >>> correct? So you're going to allocate thousands of query objects each frame? >>> >>> >>> On Wed, Apr 3, 2013 at 10:16 PM, Ben Vanik wrote: >>>> >>>> You don't use one per frame - you use many. That's what the simple >>>> examples don't show. >>>> >>>> A typical frame in a complex scene has many nested drawing batches - >>>> like for each pass for each depth mode for each shader for each texture for >>>> each buffer etc. You put timers around those things - sometimes 100+. Since >>>> you'll want to support high latency you'll want a couple sets of these >>>> timers. For the application we're building there may be 1000+ timers in >>>> flight at any given time. >>>> >>>> Just as you pipeline readback from framebuffers/etc so that you aren't >>>> blocking the GPU, you schedule your timer readback the same way -- on frame >>>> N you are checking to see if the timers from frame N-1 or N-2 are available >>>> yet. And using clever querying you can quickly check all of them -- for >>>> example if the results of the last timer from frame N-1 is available then >>>> you know all the timers from frame N-2 are available too -- no need to check >>>> them. >>>> >>>> When it comes to getting the values out it varies what you actually want >>>> to get. For performance testing you may query all timers every frame. For >>>> runtime testing deployed to real user machines most frames you may only >>>> query the outermost timer - if it says the frame took <10ms or draw (or some >>>> other threshold) you can just ignore the rest. But if it did take >Nms you >>>> can start searching down the timer tree to find what took the time. A simple >>>> binary search can then tell you exactly what kind of operation was slow for >>>> that user and allow you to report that back to a diagnostics service, change >>>> rendering quality, or even switch rendering engines to ensure the user has >>>> the best experience. >>>> >>>> This kind of complex scenario is an example of one that we would like to >>>> ship but would be unable to if the overhead imposed impacted performance >>>> significantly. When building applications that try to schedule every >>>> fractional millisecond of the main javascript loop any additional wasted >>>> time that's not providing value is unacceptable. >>>> >>>> >>>> >>>> On Wed, Apr 3, 2013 at 1:04 PM, Florian B?sch wrote: >>>>> >>>>> I don't have any personal issue with the API style either way, if you >>>>> say callbacks are too slow, fine. Let's not do callbacks. I think that >>>>> either API style has its pitfalls for beginners. >>>>> >>>>> >>>>> On Wed, Apr 3, 2013 at 9:49 PM, Ben Vanik wrote: >>>>>> >>>>>> The way I see it, the query API would work like this in a browser such >>>>>> as Chrome where rendering occurs in another thread (though it can be done >>>>>> similarly for other implementations): >>>>>> >>>>>> - user js runs init: >>>>>> - createQuery() >>>>>> - added to command buffer to send over to the gpu process >>>>>> - stashed in a 'query map' on the renderer side >>>>>> - user js runs frame: >>>>>> - beginQuery() >>>>>> - drawElements() >>>>>> - endQuery() >>>>>> - commands added to buffer, sent to gpu process >>>>>> - queryCounter() >>>>>> - returns the value of the renderer-side query object immediately >>>>>> - no blocking >>>>>> - gpu process: >>>>>> - run command buffer, see active timers, schedule them for >>>>>> processing >>>>>> - for each scheduled counter: query, if available then queue for >>>>>> sending back to renderer in a batch >>>>>> - renderer message from gpu: >>>>>> - for each updated query: >>>>>> - find in query map, set value >>>>>> - user js runs frame: >>>>>> - queryCounter() >>>>>> - returns the new value that was just set >>>>> >>>>> >>>>> I don't understand how you could get accurate timings with just one >>>>> query object for every frame. By the time you get to poll the value, there >>>>> might have elapsed multiple frames, but you only have one state. >>>>> querycounter doesn't capture the actual render time since it returns >>>>> immediately without blocking. So wouldn't you have to allocate a new query >>>>> object each frame? Isn't that also gonna be a killjoy for jerky animation? >>>> >>>> >>> >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Wed Apr 3 14:31:24 2013 From: gma...@ (Gregg Tavares) Date: Wed, 3 Apr 2013 14:31:24 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Wed, Apr 3, 2013 at 2:21 PM, Florian B?sch wrote: > On Wed, Apr 3, 2013 at 11:15 PM, Kenneth Russell wrote: > >> I think the most reliable way to adjust level of detail dynamically >> would be to make adjustments based on the application's overall frame >> rate over time, rather than measuring the GPU-side execution time of >> individual draw calls. What do you think? >> > Measuring at the frame rate level is insufficient for two reasons: > > > 1. Framerate is capped at 60fps, you will want to kick in LOD before > you start dropping frames. > > The current proposal of caching results to prevent both spin waiting and inconsistent behavior would prevent you from figuring this stuff out in the same frame. Even if we didn't add those restrictions there's no guarantee the query will be available in time to use the info in the same frame. > > 1. Not every aspect of a rendering consumes the same time relative on > every platform. For instance you might render a bunch of clouds as point > sprites (overdraw bound) and terrain (vertex troughput bound). Some > platforms might have better fillrate than vertex troughput, others might > have better vertex troughput than fillrate for any given application. How > do you know if you want to render less clouds or less terrain? > > Render them separately for the purpose of timing. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Apr 3 14:36:14 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Wed, 3 Apr 2013 23:36:14 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Wed, Apr 3, 2013 at 11:31 PM, Gregg Tavares wrote: > The current proposal of caching results to prevent both spin waiting and > inconsistent behavior would prevent you from figuring this stuff out in the > same frame. Even if we didn't add those restrictions there's no guarantee > the query will be available in time to use the info in the same frame. > In no way did I suggest that you would do it in the same frame. That would be silly. But if you measure by frames, then you can only find out about an impending issue post-hoc after you already dropped frames. Using timers you can find out about an impending issue before you drop frames by setting a budget target and undershoot. > >> >> Render them separately for the purpose of timing. > You cannot render part of the scene in one frame, and part in the next. You need a full frame to produce a picture. You can also not render one part and then call gl.finish(), that would block and degrades performance. That suggestion is invalid. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Wed Apr 3 14:57:55 2013 From: gma...@ (Gregg Tavares) Date: Wed, 3 Apr 2013 14:57:55 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Wed, Apr 3, 2013 at 2:36 PM, Florian B?sch wrote: > On Wed, Apr 3, 2013 at 11:31 PM, Gregg Tavares wrote: > >> The current proposal of caching results to prevent both spin waiting and >> inconsistent behavior would prevent you from figuring this stuff out in the >> same frame. Even if we didn't add those restrictions there's no guarantee >> the query will be available in time to use the info in the same frame. >> > In no way did I suggest that you would do it in the same frame. That would > be silly. But if you measure by frames, then you can only find out about an > impending issue post-hoc after you already dropped frames. Using timers you > can find out about an impending issue before you drop frames by setting a > budget target and undershoot. > > >> >>> >>> Render them separately for the purpose of timing. >> > You cannot render part of the scene in one frame, and part in the next. > You need a full frame to produce a picture. You can also not render one > part and then call gl.finish(), that would block and degrades performance. > That suggestion is invalid. > In no way did I suggest you would need a full frame to do this testing. If you want to know if a certain type of rendering is slow you can test your various types of rendering, off screen, at initialization time and find out which ones are slow. > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Wed Apr 3 15:07:23 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 4 Apr 2013 00:07:23 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Wed, Apr 3, 2013 at 11:57 PM, Gregg Tavares wrote: > In no way did I suggest you would need a full frame to do this testing. If > you want to know if a certain type of rendering is slow you can test your > various types of rendering, off screen, at initialization time and find out > which ones are slow. > Unless you call gl.finish() which blocks you cannot test the time it took to render something. You do not want to call gl.finish() because it blocks. You may test performance characteristics up front, which tell you jack squat how long things will actually take to render troughout the use of the application. Timing how long something took to render, is the most accurate way to figure out how long it took to render. -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Wed Apr 3 16:45:17 2013 From: jgi...@ (Jeff Gilbert) Date: Wed, 3 Apr 2013 16:45:17 -0700 (PDT) Subject: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test In-Reply-To: Message-ID: <1675106687.1992944.1365032717779.JavaMail.root@mozilla.com> The devices are otherwise quite capable. I had to adjust the testcase I wrote for it a couple times to get it to reproduce. For example, changing the test to use bindTexture to change the texture to draw to the screen makes this problem go away. It's only changing the sampler's texture unit via uniform1i that tickles the driver into giving an OOM. I'll note that this is most likely not actually out of system memory, since one of the devices has 2GB of RAM. Rather, it's probably just running out of room for some subsection in the driver. -Jeff ----- Original Message ----- From: "Gregg Tavares" To: "Jeff Gilbert" Cc: "public webgl" Sent: Wednesday, April 3, 2013 2:28:26 PM Subject: Re: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test On Wed, Apr 3, 2013 at 11:24 AM, Jeff Gilbert < jgilbert...@ > wrote: It's true, but this test generates over a thousand different draw calls, which is unusual. Unusual for a test? It's not for a standard webgl app. I don't think it's a good idea for the test to mandate something like this succeeds, since that'll mean adding flushing heuristics to the implementation. Does the device in question run most webgl content otherwise or does it run out of memory on lots of examples where other devices do not? I'd much prefer not supporting WebGL on devices that behave really poorly than pass on those issues to Web devs. My point is, even though the spec allows making every function a no-op and making glGetError return GL_OUT_OF_MEMORY, the OpenGL ES 2.0 conformance tests require more than that even though that's not part of the spec. So, the question is, what should the similar requirements be for the WebGL Conformance Tests? It seems like there should be some minimum requirements. What should they be? -Jeff ----- Original Message ----- From: "Gregg Tavares" < gman...@ > To: "Jeff Gilbert" < jgilbert...@ > Cc: "public webgl" < public_webgl...@ > Sent: Wednesday, April 3, 2013 9:13:43 AM Subject: Re: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test IIRC the tests have been written to use a reasonable (less than 60meg) amount of memory. The spec unfortunately makes it possible for every function to generate GL_OUT_OF_MEMORY period and still be technically spec compliant. In other words, according to the spec an implementation could to this GLenum glGetErrror() { return GL_OUT_OF_MEMORY; } void glBindBuffer(...) { /* no-op */ } void glBindTexture(...) { /* no-op */ } void glTexImage2D(...) { /* no-op */ } void glDrawArrays(...) { /* no-op */ } And be valid according to the spec :-( On Wed, Apr 3, 2013 at 12:25 AM, Jeff Gilbert < jgilbert...@ > wrote: On some mobile devices, we're hitting a couple errors followed by a gl.OUT_OF_MEMORY error in the "check reading with lots of drawing" section. This is AFAIK spec-compliant behavior, so I believe the test should be changed to gl.flush() after each draw call, which seems to have fixed it for me. Thoughts? -Jeff ----------------------------------------------------------- You are currently subscribed to public_webgl...@ . To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Wed Apr 3 17:03:55 2013 From: gma...@ (Gregg Tavares) Date: Wed, 3 Apr 2013 17:03:55 -0700 Subject: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test In-Reply-To: <1675106687.1992944.1365032717779.JavaMail.root@mozilla.com> References: <1675106687.1992944.1365032717779.JavaMail.root@mozilla.com> Message-ID: > It's only changing the sampler's texture unit via uniform1i that tickles the driver into giving an OOM. A driver that reports OOM on calling uniform1i is not a driver I'd be willing to pass on to web devs. On Wed, Apr 3, 2013 at 4:45 PM, Jeff Gilbert wrote: > The devices are otherwise quite capable. I had to adjust the testcase I > wrote for it a couple times to get it to reproduce. For example, changing > the test to use bindTexture to change the texture to draw to the screen > makes this problem go away. It's only changing the sampler's texture unit > via uniform1i that tickles the driver into giving an OOM. > > I'll note that this is most likely not actually out of system memory, > since one of the devices has 2GB of RAM. Rather, it's probably just running > out of room for some subsection in the driver. > > -Jeff > > ----- Original Message ----- > From: "Gregg Tavares" > To: "Jeff Gilbert" > Cc: "public webgl" > Sent: Wednesday, April 3, 2013 2:28:26 PM > Subject: Re: [Public WebGL] OUT_OF_MEMORY error in > 1.0.1/conformance/reading/read-pixels-test > > > > > > > > On Wed, Apr 3, 2013 at 11:24 AM, Jeff Gilbert < jgilbert...@ > > wrote: > > > It's true, but this test generates over a thousand different draw calls, > which is unusual. > > > Unusual for a test? It's not for a standard webgl app. > > > I don't think it's a good idea for the test to mandate something like this > succeeds, since that'll mean adding flushing heuristics to the > implementation. > > > > Does the device in question run most webgl content otherwise or does it > run out of memory on lots of examples where other devices do not? I'd much > prefer not supporting WebGL on devices that behave really poorly than pass > on those issues to Web devs. > > > My point is, even though the spec allows making every function a no-op and > making glGetError return GL_OUT_OF_MEMORY, the OpenGL ES 2.0 conformance > tests require more than that even though that's not part of the spec. > > > So, the question is, what should the similar requirements be for the WebGL > Conformance Tests? It seems like there should be some minimum requirements. > What should they be? > > > > > > -Jeff > > > > ----- Original Message ----- > From: "Gregg Tavares" < gman...@ > > To: "Jeff Gilbert" < jgilbert...@ > > Cc: "public webgl" < public_webgl...@ > > Sent: Wednesday, April 3, 2013 9:13:43 AM > Subject: Re: [Public WebGL] OUT_OF_MEMORY error in > 1.0.1/conformance/reading/read-pixels-test > > > IIRC the tests have been written to use a reasonable (less than 60meg) > amount of memory. > > > The spec unfortunately makes it possible for every function to generate > GL_OUT_OF_MEMORY period and still be technically spec compliant. > > > In other words, according to the spec an implementation could to this > > > GLenum glGetErrror() { return GL_OUT_OF_MEMORY; } > void glBindBuffer(...) { /* no-op */ } > > void glBindTexture(...) { /* no-op */ } > void glTexImage2D(...) { /* no-op */ } > void glDrawArrays(...) { /* no-op */ } > > > And be valid according to the spec :-( > > > > > > > > On Wed, Apr 3, 2013 at 12:25 AM, Jeff Gilbert < jgilbert...@ > > wrote: > > > > On some mobile devices, we're hitting a couple errors followed by a > gl.OUT_OF_MEMORY error in the "check reading with lots of drawing" section. > This is AFAIK spec-compliant behavior, so I believe the test should be > changed to gl.flush() after each draw call, which seems to have fixed it > for me. > > Thoughts? > > -Jeff > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ . > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Apr 3 17:32:16 2013 From: kbr...@ (Kenneth Russell) Date: Wed, 3 Apr 2013 17:32:16 -0700 Subject: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test In-Reply-To: References: <1675106687.1992944.1365032717779.JavaMail.root@mozilla.com> Message-ID: This sounds like a quality of implementation problem in the driver on this platform. The working group's stance on this has been very clear in the past; the tests will not be modified to work around bugs in WebGL implementations or graphics drivers. (You'll recall that I violated this rule once, was correctly called out on it, and reverted the change to the test.) -Ken On Wed, Apr 3, 2013 at 5:03 PM, Gregg Tavares wrote: >> It's only changing the sampler's texture unit via uniform1i that tickles >> the driver into giving an OOM. > > A driver that reports OOM on calling uniform1i is not a driver I'd be > willing to pass on to web devs. > > > > On Wed, Apr 3, 2013 at 4:45 PM, Jeff Gilbert wrote: >> >> The devices are otherwise quite capable. I had to adjust the testcase I >> wrote for it a couple times to get it to reproduce. For example, changing >> the test to use bindTexture to change the texture to draw to the screen >> makes this problem go away. It's only changing the sampler's texture unit >> via uniform1i that tickles the driver into giving an OOM. >> >> I'll note that this is most likely not actually out of system memory, >> since one of the devices has 2GB of RAM. Rather, it's probably just running >> out of room for some subsection in the driver. >> >> -Jeff >> >> ----- Original Message ----- >> From: "Gregg Tavares" >> To: "Jeff Gilbert" >> Cc: "public webgl" >> Sent: Wednesday, April 3, 2013 2:28:26 PM >> Subject: Re: [Public WebGL] OUT_OF_MEMORY error in >> 1.0.1/conformance/reading/read-pixels-test >> >> >> >> >> >> >> >> On Wed, Apr 3, 2013 at 11:24 AM, Jeff Gilbert < jgilbert...@ > >> wrote: >> >> >> It's true, but this test generates over a thousand different draw calls, >> which is unusual. >> >> >> Unusual for a test? It's not for a standard webgl app. >> >> >> I don't think it's a good idea for the test to mandate something like this >> succeeds, since that'll mean adding flushing heuristics to the >> implementation. >> >> >> >> Does the device in question run most webgl content otherwise or does it >> run out of memory on lots of examples where other devices do not? I'd much >> prefer not supporting WebGL on devices that behave really poorly than pass >> on those issues to Web devs. >> >> >> My point is, even though the spec allows making every function a no-op and >> making glGetError return GL_OUT_OF_MEMORY, the OpenGL ES 2.0 conformance >> tests require more than that even though that's not part of the spec. >> >> >> So, the question is, what should the similar requirements be for the WebGL >> Conformance Tests? It seems like there should be some minimum requirements. >> What should they be? >> >> >> >> >> >> -Jeff >> >> >> >> ----- Original Message ----- >> From: "Gregg Tavares" < gman...@ > >> To: "Jeff Gilbert" < jgilbert...@ > >> Cc: "public webgl" < public_webgl...@ > >> Sent: Wednesday, April 3, 2013 9:13:43 AM >> Subject: Re: [Public WebGL] OUT_OF_MEMORY error in >> 1.0.1/conformance/reading/read-pixels-test >> >> >> IIRC the tests have been written to use a reasonable (less than 60meg) >> amount of memory. >> >> >> The spec unfortunately makes it possible for every function to generate >> GL_OUT_OF_MEMORY period and still be technically spec compliant. >> >> >> In other words, according to the spec an implementation could to this >> >> >> GLenum glGetErrror() { return GL_OUT_OF_MEMORY; } >> void glBindBuffer(...) { /* no-op */ } >> >> void glBindTexture(...) { /* no-op */ } >> void glTexImage2D(...) { /* no-op */ } >> void glDrawArrays(...) { /* no-op */ } >> >> >> And be valid according to the spec :-( >> >> >> >> >> >> >> >> On Wed, Apr 3, 2013 at 12:25 AM, Jeff Gilbert < jgilbert...@ > >> wrote: >> >> >> >> On some mobile devices, we're hitting a couple errors followed by a >> gl.OUT_OF_MEMORY error in the "check reading with lots of drawing" section. >> This is AFAIK spec-compliant behavior, so I believe the test should be >> changed to gl.flush() after each draw call, which seems to have fixed it for >> me. >> >> Thoughts? >> >> -Jeff >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ . >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jgi...@ Wed Apr 3 18:09:24 2013 From: jgi...@ (Jeff Gilbert) Date: Wed, 3 Apr 2013 18:09:24 -0700 (PDT) Subject: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test In-Reply-To: Message-ID: <2102974427.1997120.1365037764063.JavaMail.root@mozilla.com> I suppose I was unclear: Good: gl.activeTexture(gl.TEXTURE0); gl.uniform1i(loc_uTexUnit, 0); for (var j = 0; j < 3; j++) { for (var i = 0; i < 1000; i++) { gl.bindTexture(gl.TEXTURE_2D, (i % 2) ? texA : texB); gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4); } gl.readPixels(gl.drawingBufferWidth / 2, gl.drawingBufferHeight / 2, 1, 1, gl.RGBA, gl.UNSIGNED_BYTE, new Uint8Array(4)); } Bad: gl.activeTexture(gl.TEXTURE0); gl.bindTexture(gl.TEXTURE_2D, texA); gl.activeTexture(gl.TEXTURE1); gl.bindTexture(gl.TEXTURE_2D, texB); for (var j = 0; j < 3; j++) { for (var i = 0; i < 1000; i++) { gl.uniform1i(loc_uTexUnit, i % 2); gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4); } gl.readPixels(gl.drawingBufferWidth / 2, gl.drawingBufferHeight / 2, 1, 1, gl.RGBA, gl.UNSIGNED_BYTE, new Uint8Array(4)); } This is the sort of pipeline filling that would generally warrant a glFlush anyways. -Jeff ----- Original Message ----- From: "Gregg Tavares" To: "Jeff Gilbert" Cc: "public webgl" Sent: Wednesday, April 3, 2013 5:03:55 PM Subject: Re: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test > It's only changing the sampler's texture unit via uniform1i that tickles the driver into giving an OOM. A driver that reports OOM on calling uniform1i is not a driver I'd be willing to pass on to web devs. On Wed, Apr 3, 2013 at 4:45 PM, Jeff Gilbert < jgilbert...@ > wrote: The devices are otherwise quite capable. I had to adjust the testcase I wrote for it a couple times to get it to reproduce. For example, changing the test to use bindTexture to change the texture to draw to the screen makes this problem go away. It's only changing the sampler's texture unit via uniform1i that tickles the driver into giving an OOM. I'll note that this is most likely not actually out of system memory, since one of the devices has 2GB of RAM. Rather, it's probably just running out of room for some subsection in the driver. -Jeff ----- Original Message ----- From: "Gregg Tavares" < gman...@ > To: "Jeff Gilbert" < jgilbert...@ > Cc: "public webgl" < public_webgl...@ > Sent: Wednesday, April 3, 2013 2:28:26 PM Subject: Re: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test On Wed, Apr 3, 2013 at 11:24 AM, Jeff Gilbert < jgilbert...@ > wrote: It's true, but this test generates over a thousand different draw calls, which is unusual. Unusual for a test? It's not for a standard webgl app. I don't think it's a good idea for the test to mandate something like this succeeds, since that'll mean adding flushing heuristics to the implementation. Does the device in question run most webgl content otherwise or does it run out of memory on lots of examples where other devices do not? I'd much prefer not supporting WebGL on devices that behave really poorly than pass on those issues to Web devs. My point is, even though the spec allows making every function a no-op and making glGetError return GL_OUT_OF_MEMORY, the OpenGL ES 2.0 conformance tests require more than that even though that's not part of the spec. So, the question is, what should the similar requirements be for the WebGL Conformance Tests? It seems like there should be some minimum requirements. What should they be? -Jeff ----- Original Message ----- From: "Gregg Tavares" < gman...@ > To: "Jeff Gilbert" < jgilbert...@ > Cc: "public webgl" < public_webgl...@ > Sent: Wednesday, April 3, 2013 9:13:43 AM Subject: Re: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test IIRC the tests have been written to use a reasonable (less than 60meg) amount of memory. The spec unfortunately makes it possible for every function to generate GL_OUT_OF_MEMORY period and still be technically spec compliant. In other words, according to the spec an implementation could to this GLenum glGetErrror() { return GL_OUT_OF_MEMORY; } void glBindBuffer(...) { /* no-op */ } void glBindTexture(...) { /* no-op */ } void glTexImage2D(...) { /* no-op */ } void glDrawArrays(...) { /* no-op */ } And be valid according to the spec :-( On Wed, Apr 3, 2013 at 12:25 AM, Jeff Gilbert < jgilbert...@ > wrote: On some mobile devices, we're hitting a couple errors followed by a gl.OUT_OF_MEMORY error in the "check reading with lots of drawing" section. This is AFAIK spec-compliant behavior, so I believe the test should be changed to gl.flush() after each draw call, which seems to have fixed it for me. Thoughts? -Jeff ----------------------------------------------------------- You are currently subscribed to public_webgl...@ . To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From bco...@ Wed Apr 3 18:27:21 2013 From: bco...@ (Brian Cornell) Date: Wed, 3 Apr 2013 18:27:21 -0700 Subject: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test In-Reply-To: <2102974427.1997120.1365037764063.JavaMail.root@mozilla.com> References: <2102974427.1997120.1365037764063.JavaMail.root@mozilla.com> Message-ID: Is there actually hardware for which the Bad one fails and the Good one passes? My understanding of a lot of GPUs WRT to performance is that Bad will perform a lot better than Good because updating bindings is slow. Maybe there is a special case of badness when what you are setting is a sampler uniform? -Brian On Wed, Apr 3, 2013 at 6:09 PM, Jeff Gilbert wrote: > > I suppose I was unclear: > > Good: > gl.activeTexture(gl.TEXTURE0); > gl.uniform1i(loc_uTexUnit, 0); > for (var j = 0; j < 3; j++) { > for (var i = 0; i < 1000; i++) { > gl.bindTexture(gl.TEXTURE_2D, (i % 2) ? texA : texB); > gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4); > } > gl.readPixels(gl.drawingBufferWidth / 2, gl.drawingBufferHeight / 2, 1, > 1, gl.RGBA, gl.UNSIGNED_BYTE, new Uint8Array(4)); > } > > Bad: > gl.activeTexture(gl.TEXTURE0); > gl.bindTexture(gl.TEXTURE_2D, texA); > gl.activeTexture(gl.TEXTURE1); > gl.bindTexture(gl.TEXTURE_2D, texB); > for (var j = 0; j < 3; j++) { > for (var i = 0; i < 1000; i++) { > gl.uniform1i(loc_uTexUnit, i % 2); > gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4); > } > gl.readPixels(gl.drawingBufferWidth / 2, gl.drawingBufferHeight / 2, 1, > 1, gl.RGBA, gl.UNSIGNED_BYTE, new Uint8Array(4)); > } > > This is the sort of pipeline filling that would generally warrant a > glFlush anyways. > > -Jeff > > ----- Original Message ----- > From: "Gregg Tavares" > To: "Jeff Gilbert" > Cc: "public webgl" > Sent: Wednesday, April 3, 2013 5:03:55 PM > Subject: Re: [Public WebGL] OUT_OF_MEMORY error in > 1.0.1/conformance/reading/read-pixels-test > > > > It's only changing the sampler's texture unit via uniform1i that tickles > the driver into giving an OOM. > > > > A driver that reports OOM on calling uniform1i is not a driver I'd be > willing to pass on to web devs. > > > > > > On Wed, Apr 3, 2013 at 4:45 PM, Jeff Gilbert < jgilbert...@ > > wrote: > > > The devices are otherwise quite capable. I had to adjust the testcase I > wrote for it a couple times to get it to reproduce. For example, changing > the test to use bindTexture to change the texture to draw to the screen > makes this problem go away. It's only changing the sampler's texture unit > via uniform1i that tickles the driver into giving an OOM. > > I'll note that this is most likely not actually out of system memory, > since one of the devices has 2GB of RAM. Rather, it's probably just running > out of room for some subsection in the driver. > > > -Jeff > > ----- Original Message ----- > From: "Gregg Tavares" < gman...@ > > To: "Jeff Gilbert" < jgilbert...@ > > Cc: "public webgl" < public_webgl...@ > > > > Sent: Wednesday, April 3, 2013 2:28:26 PM > Subject: Re: [Public WebGL] OUT_OF_MEMORY error in > 1.0.1/conformance/reading/read-pixels-test > > > > > > > > On Wed, Apr 3, 2013 at 11:24 AM, Jeff Gilbert < jgilbert...@ > > wrote: > > > It's true, but this test generates over a thousand different draw calls, > which is unusual. > > > Unusual for a test? It's not for a standard webgl app. > > > I don't think it's a good idea for the test to mandate something like this > succeeds, since that'll mean adding flushing heuristics to the > implementation. > > > > Does the device in question run most webgl content otherwise or does it > run out of memory on lots of examples where other devices do not? I'd much > prefer not supporting WebGL on devices that behave really poorly than pass > on those issues to Web devs. > > > My point is, even though the spec allows making every function a no-op and > making glGetError return GL_OUT_OF_MEMORY, the OpenGL ES 2.0 conformance > tests require more than that even though that's not part of the spec. > > > So, the question is, what should the similar requirements be for the WebGL > Conformance Tests? It seems like there should be some minimum requirements. > What should they be? > > > > > > -Jeff > > > > ----- Original Message ----- > From: "Gregg Tavares" < gman...@ > > To: "Jeff Gilbert" < jgilbert...@ > > Cc: "public webgl" < public_webgl...@ > > Sent: Wednesday, April 3, 2013 9:13:43 AM > Subject: Re: [Public WebGL] OUT_OF_MEMORY error in > 1.0.1/conformance/reading/read-pixels-test > > > IIRC the tests have been written to use a reasonable (less than 60meg) > amount of memory. > > > The spec unfortunately makes it possible for every function to generate > GL_OUT_OF_MEMORY period and still be technically spec compliant. > > > In other words, according to the spec an implementation could to this > > > GLenum glGetErrror() { return GL_OUT_OF_MEMORY; } > void glBindBuffer(...) { /* no-op */ } > > void glBindTexture(...) { /* no-op */ } > void glTexImage2D(...) { /* no-op */ } > void glDrawArrays(...) { /* no-op */ } > > > And be valid according to the spec :-( > > > > > > > > On Wed, Apr 3, 2013 at 12:25 AM, Jeff Gilbert < jgilbert...@ > > wrote: > > > > On some mobile devices, we're hitting a couple errors followed by a > gl.OUT_OF_MEMORY error in the "check reading with lots of drawing" section. > This is AFAIK spec-compliant behavior, so I believe the test should be > changed to gl.flush() after each draw call, which seems to have fixed it > for me. > > Thoughts? > > -Jeff > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ . > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Wed Apr 3 19:41:48 2013 From: jgi...@ (Jeff Gilbert) Date: Wed, 3 Apr 2013 19:41:48 -0700 (PDT) Subject: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test In-Reply-To: Message-ID: <182579572.2000970.1365043308813.JavaMail.root@mozilla.com> Yes, there is hardware, which is why I'm posting. :P It depends on the arch, I imagine. The binding/unbinding has to happen at some point. If you have an arch which does minor shader recompilation after changing a uniform, it'll be slower. I don't see why bindTexture should significantly slower. -Jeff ----- Original Message ----- From: "Brian Cornell" To: "Jeff Gilbert" Cc: "Gregg Tavares" , "public webgl" Sent: Wednesday, April 3, 2013 6:27:21 PM Subject: Re: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test Is there actually hardware for which the Bad one fails and the Good one passes? My understanding of a lot of GPUs WRT to performance is that Bad will perform a lot better than Good because updating bindings is slow. Maybe there is a special case of badness when what you are setting is a sampler uniform? -Brian On Wed, Apr 3, 2013 at 6:09 PM, Jeff Gilbert < jgilbert...@ > wrote: I suppose I was unclear: Good: gl.activeTexture(gl.TEXTURE0); gl.uniform1i(loc_uTexUnit, 0); for (var j = 0; j < 3; j++) { for (var i = 0; i < 1000; i++) { gl.bindTexture(gl.TEXTURE_2D, (i % 2) ? texA : texB); gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4); } gl.readPixels(gl.drawingBufferWidth / 2, gl.drawingBufferHeight / 2, 1, 1, gl.RGBA, gl.UNSIGNED_BYTE, new Uint8Array(4)); } Bad: gl.activeTexture(gl.TEXTURE0); gl.bindTexture(gl.TEXTURE_2D, texA); gl.activeTexture(gl.TEXTURE1); gl.bindTexture(gl.TEXTURE_2D, texB); for (var j = 0; j < 3; j++) { for (var i = 0; i < 1000; i++) { gl.uniform1i(loc_uTexUnit, i % 2); gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4); } gl.readPixels(gl.drawingBufferWidth / 2, gl.drawingBufferHeight / 2, 1, 1, gl.RGBA, gl.UNSIGNED_BYTE, new Uint8Array(4)); } This is the sort of pipeline filling that would generally warrant a glFlush anyways. -Jeff ----- Original Message ----- From: "Gregg Tavares" < gman...@ > To: "Jeff Gilbert" < jgilbert...@ > Cc: "public webgl" < public_webgl...@ > Sent: Wednesday, April 3, 2013 5:03:55 PM Subject: Re: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test > It's only changing the sampler's texture unit via uniform1i that tickles the driver into giving an OOM. A driver that reports OOM on calling uniform1i is not a driver I'd be willing to pass on to web devs. On Wed, Apr 3, 2013 at 4:45 PM, Jeff Gilbert < jgilbert...@ > wrote: The devices are otherwise quite capable. I had to adjust the testcase I wrote for it a couple times to get it to reproduce. For example, changing the test to use bindTexture to change the texture to draw to the screen makes this problem go away. It's only changing the sampler's texture unit via uniform1i that tickles the driver into giving an OOM. I'll note that this is most likely not actually out of system memory, since one of the devices has 2GB of RAM. Rather, it's probably just running out of room for some subsection in the driver. -Jeff ----- Original Message ----- From: "Gregg Tavares" < gman...@ > To: "Jeff Gilbert" < jgilbert...@ > Cc: "public webgl" < public_webgl...@ > Sent: Wednesday, April 3, 2013 2:28:26 PM Subject: Re: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test On Wed, Apr 3, 2013 at 11:24 AM, Jeff Gilbert < jgilbert...@ > wrote: It's true, but this test generates over a thousand different draw calls, which is unusual. Unusual for a test? It's not for a standard webgl app. I don't think it's a good idea for the test to mandate something like this succeeds, since that'll mean adding flushing heuristics to the implementation. Does the device in question run most webgl content otherwise or does it run out of memory on lots of examples where other devices do not? I'd much prefer not supporting WebGL on devices that behave really poorly than pass on those issues to Web devs. My point is, even though the spec allows making every function a no-op and making glGetError return GL_OUT_OF_MEMORY, the OpenGL ES 2.0 conformance tests require more than that even though that's not part of the spec. So, the question is, what should the similar requirements be for the WebGL Conformance Tests? It seems like there should be some minimum requirements. What should they be? -Jeff ----- Original Message ----- From: "Gregg Tavares" < gman...@ > To: "Jeff Gilbert" < jgilbert...@ > Cc: "public webgl" < public_webgl...@ > Sent: Wednesday, April 3, 2013 9:13:43 AM Subject: Re: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test IIRC the tests have been written to use a reasonable (less than 60meg) amount of memory. The spec unfortunately makes it possible for every function to generate GL_OUT_OF_MEMORY period and still be technically spec compliant. In other words, according to the spec an implementation could to this GLenum glGetErrror() { return GL_OUT_OF_MEMORY; } void glBindBuffer(...) { /* no-op */ } void glBindTexture(...) { /* no-op */ } void glTexImage2D(...) { /* no-op */ } void glDrawArrays(...) { /* no-op */ } And be valid according to the spec :-( On Wed, Apr 3, 2013 at 12:25 AM, Jeff Gilbert < jgilbert...@ > wrote: On some mobile devices, we're hitting a couple errors followed by a gl.OUT_OF_MEMORY error in the "check reading with lots of drawing" section. This is AFAIK spec-compliant behavior, so I believe the test should be changed to gl.flush() after each draw call, which seems to have fixed it for me. Thoughts? -Jeff ----------------------------------------------------------- You are currently subscribed to public_webgl...@ . To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ . To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cal...@ Wed Apr 3 21:03:03 2013 From: cal...@ (Mark Callow) Date: Thu, 04 Apr 2013 13:03:03 +0900 Subject: [Public WebGL] OUT_OF_MEMORY error in 1.0.1/conformance/reading/read-pixels-test In-Reply-To: <2102974427.1997120.1365037764063.JavaMail.root@mozilla.com> References: <2102974427.1997120.1365037764063.JavaMail.root@mozilla.com> Message-ID: <515CFB77.3080708@artspark.co.jp> On 2013/04/04 10:09, Jeff Gilbert wrote: > I suppose I was unclear: > > Good: > gl.activeTexture(gl.TEXTURE0); > gl.uniform1i(loc_uTexUnit, 0); > for (var j = 0; j < 3; j++) { > for (var i = 0; i < 1000; i++) { > gl.bindTexture(gl.TEXTURE_2D, (i % 2) ? texA : texB); > gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4); > } > gl.readPixels(gl.drawingBufferWidth / 2, gl.drawingBufferHeight / 2, 1, 1, gl.RGBA, gl.UNSIGNED_BYTE, new Uint8Array(4)); > } > > Bad: > gl.activeTexture(gl.TEXTURE0); > gl.bindTexture(gl.TEXTURE_2D, texA); > gl.activeTexture(gl.TEXTURE1); > gl.bindTexture(gl.TEXTURE_2D, texB); > for (var j = 0; j < 3; j++) { > for (var i = 0; i < 1000; i++) { > gl.uniform1i(loc_uTexUnit, i % 2); > gl.drawArrays(gl.TRIANGLE_STRIP, 0, 4); > } > gl.readPixels(gl.drawingBufferWidth / 2, gl.drawingBufferHeight / 2, 1, 1, gl.RGBA, gl.UNSIGNED_BYTE, new Uint8Array(4)); > } It still looks like a poor implementation to me so I agree with Gregg's and Ken's comments. > This is the sort of pipeline filling that would generally warrant a glFlush anyways. Why? Implementations should do implicit flushes, as Maurice describes. Leaving it to the application to decide when the GPU command buffers are almost full and a flush is needed is a recipe for problems. Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Thu Apr 4 00:37:04 2013 From: gma...@ (Gregg Tavares) Date: Thu, 4 Apr 2013 00:37:04 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: So there's still another issue with polling. Even if we make it so you can't spin-wait and you can have to get result-available before checking the result you still end up with the issue that people will spam the browser by using setInterval(checkQueries,0) In order to effectively spin wait on the queries. They'll do this because it will be faster on some platforms. I can certainly imagine code like this function onRequestAnimationFrame() { for each model { start occlusion query } id = setInterval(processQueries, 0); } function processQueries() { for each query { if (result-available) { if (not occluded) { draw; } remove query } if no more queries { clearInterval(id) requestAnimationFrame(onRequestAnimationFrame); } } On some implementations that may be faster even though is very bad for the browser. Again, with callbacks that's impossible. The code to process queries as fast as possible becomes function onRequestAnimationFrame() { for each model { start occlusion query with callback for model } } function callback() { if (not occluded) { draw; } if no more queries { requestAnimationFrame(onRequestAnimationFrame); } } On Wed, Apr 3, 2013 at 3:07 PM, Florian B?sch wrote: > On Wed, Apr 3, 2013 at 11:57 PM, Gregg Tavares wrote: > >> In no way did I suggest you would need a full frame to do this testing. >> If you want to know if a certain type of rendering is slow you can test >> your various types of rendering, off screen, at initialization time and >> find out which ones are slow. >> > Unless you call gl.finish() which blocks you cannot test the time it took > to render something. You do not want to call gl.finish() because it blocks. > You may test performance characteristics up front, which tell you jack > squat how long things will actually take to render troughout the use of the > application. Timing how long something took to render, is the most accurate > way to figure out how long it took to render. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Apr 4 00:54:03 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 4 Apr 2013 09:54:03 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: It doesn't really matter to the discussion what kind of abuse you will be able to make with an API-semantic if the precondition of it being usable at all due to performance constraints would be compromised by one or another flavor. You will need to resolve the technical feasability of either API flavor first before you're trying to evaluate their respective potential for abuse. On Thu, Apr 4, 2013 at 9:37 AM, Gregg Tavares wrote: > So there's still another issue with polling. Even if we make it so you > can't spin-wait and you can have to get result-available before checking > the result you still end up with the issue that people will spam the > browser by using > > setInterval(checkQueries,0) > > In order to effectively spin wait on the queries. They'll do this because > it will be faster on some platforms. > > I can certainly imagine code like this > > function onRequestAnimationFrame() { > for each model { > start occlusion query > } > id = setInterval(processQueries, 0); > } > > function processQueries() { > for each query { > if (result-available) { > if (not occluded) { > draw; > } > remove query > } > if no more queries { > clearInterval(id) > requestAnimationFrame(onRequestAnimationFrame); > } > } > > On some implementations that may be faster even though is very bad for the > browser. > > Again, with callbacks that's impossible. The code to process queries as > fast as possible becomes > > function onRequestAnimationFrame() { > for each model { > start occlusion query with callback for model > } > } > > function callback() { > if (not occluded) { > draw; > } > if no more queries { > requestAnimationFrame(onRequestAnimationFrame); > } > } > > > > > > > > > > > > > > > > > > On Wed, Apr 3, 2013 at 3:07 PM, Florian B?sch wrote: > >> On Wed, Apr 3, 2013 at 11:57 PM, Gregg Tavares wrote: >> >>> In no way did I suggest you would need a full frame to do this testing. >>> If you want to know if a certain type of rendering is slow you can test >>> your various types of rendering, off screen, at initialization time and >>> find out which ones are slow. >>> >> Unless you call gl.finish() which blocks you cannot test the time it took >> to render something. You do not want to call gl.finish() because it blocks. >> You may test performance characteristics up front, which tell you jack >> squat how long things will actually take to render troughout the use of the >> application. Timing how long something took to render, is the most accurate >> way to figure out how long it took to render. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Apr 4 01:13:40 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 4 Apr 2013 10:13:40 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: Ben, you've been saying that calling thousands of callbacks per frame would be infeasible. I agree, does anybody not agree on this? But would polling thousands of queries not be equally infeasible? So you've been saying that you wouldn't do that in practise. You would just poll the last query of a frame, and you can assume that all preceding queries are ready. Doesn't the same argument apply to callbacks? Wouldn't you in practise only attach a ready callback to the last query of a frame? So it's not thousands of callbacks for a set of thousands of queries. It would be one callback per frame. Doesn't that make callbacks equally feasible? On Thu, Apr 4, 2013 at 9:54 AM, Florian B?sch wrote: > It doesn't really matter to the discussion what kind of abuse you will be > able to make with an API-semantic if the precondition of it being usable at > all due to performance constraints would be compromised by one or another > flavor. You will need to resolve the technical feasability of either API > flavor first before you're trying to evaluate their respective potential > for abuse. > > > On Thu, Apr 4, 2013 at 9:37 AM, Gregg Tavares wrote: > >> So there's still another issue with polling. Even if we make it so you >> can't spin-wait and you can have to get result-available before checking >> the result you still end up with the issue that people will spam the >> browser by using >> >> setInterval(checkQueries,0) >> >> In order to effectively spin wait on the queries. They'll do this because >> it will be faster on some platforms. >> >> I can certainly imagine code like this >> >> function onRequestAnimationFrame() { >> for each model { >> start occlusion query >> } >> id = setInterval(processQueries, 0); >> } >> >> function processQueries() { >> for each query { >> if (result-available) { >> if (not occluded) { >> draw; >> } >> remove query >> } >> if no more queries { >> clearInterval(id) >> requestAnimationFrame(onRequestAnimationFrame); >> } >> } >> >> On some implementations that may be faster even though is very bad for >> the browser. >> >> Again, with callbacks that's impossible. The code to process queries as >> fast as possible becomes >> >> function onRequestAnimationFrame() { >> for each model { >> start occlusion query with callback for model >> } >> } >> >> function callback() { >> if (not occluded) { >> draw; >> } >> if no more queries { >> requestAnimationFrame(onRequestAnimationFrame); >> } >> } >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> >> On Wed, Apr 3, 2013 at 3:07 PM, Florian B?sch wrote: >> >>> On Wed, Apr 3, 2013 at 11:57 PM, Gregg Tavares wrote: >>> >>>> In no way did I suggest you would need a full frame to do this testing. >>>> If you want to know if a certain type of rendering is slow you can test >>>> your various types of rendering, off screen, at initialization time and >>>> find out which ones are slow. >>>> >>> Unless you call gl.finish() which blocks you cannot test the time it >>> took to render something. You do not want to call gl.finish() because it >>> blocks. You may test performance characteristics up front, which tell you >>> jack squat how long things will actually take to render troughout the use >>> of the application. Timing how long something took to render, is the most >>> accurate way to figure out how long it took to render. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Fri Apr 5 17:28:20 2013 From: kbr...@ (Kenneth Russell) Date: Fri, 5 Apr 2013 17:28:20 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: Yes, that's nasty. It might be possible to work around this by saying that queries don't change their state until the next requestAnimationFrame callback is processed, but I agree that using callbacks instead would be simpler and better guarantee correct usage. Given the problems seen so far, I think we should either: 1) Rewrite the extension to use callbacks. 2) Remove all wording about when query results become available, and leave things up to the user. Thoughts? Other options? Either way, prototyping the spec (in draft form, with vendor prefixes) and seeing how well it works for various use cases is the only way we're going to make an informed decision about the long-term direction of the API. Ben, Brian, in the spirit of avoiding premature optimization I suggest we restructure the API to use callbacks and, if there are performance issues with the prototype, try it again in polling form. What do you think? -Ken On Thu, Apr 4, 2013 at 12:37 AM, Gregg Tavares wrote: > So there's still another issue with polling. Even if we make it so you can't > spin-wait and you can have to get result-available before checking the > result you still end up with the issue that people will spam the browser by > using > > setInterval(checkQueries,0) > > In order to effectively spin wait on the queries. They'll do this because it > will be faster on some platforms. > > I can certainly imagine code like this > > function onRequestAnimationFrame() { > for each model { > start occlusion query > } > id = setInterval(processQueries, 0); > } > > function processQueries() { > for each query { > if (result-available) { > if (not occluded) { > draw; > } > remove query > } > if no more queries { > clearInterval(id) > requestAnimationFrame(onRequestAnimationFrame); > } > } > > On some implementations that may be faster even though is very bad for the > browser. > > Again, with callbacks that's impossible. The code to process queries as fast > as possible becomes > > function onRequestAnimationFrame() { > for each model { > start occlusion query with callback for model > } > } > > function callback() { > if (not occluded) { > draw; > } > if no more queries { > requestAnimationFrame(onRequestAnimationFrame); > } > } > > > > > > > > > > > > > > > > > > On Wed, Apr 3, 2013 at 3:07 PM, Florian B?sch wrote: >> >> On Wed, Apr 3, 2013 at 11:57 PM, Gregg Tavares wrote: >>> >>> In no way did I suggest you would need a full frame to do this testing. >>> If you want to know if a certain type of rendering is slow you can test your >>> various types of rendering, off screen, at initialization time and find out >>> which ones are slow. >> >> Unless you call gl.finish() which blocks you cannot test the time it took >> to render something. You do not want to call gl.finish() because it blocks. >> You may test performance characteristics up front, which tell you jack squat >> how long things will actually take to render troughout the use of the >> application. Timing how long something took to render, is the most accurate >> way to figure out how long it took to render. > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Tue Apr 9 04:02:38 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Tue, 9 Apr 2013 13:02:38 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: So I have made the argument that callbacks would be no worse than polling, I'd like to illustrate that in code. Below is an example of how thousands of queries would be used but only one callback per frame is attached. *// create a 10k query cache* var queryPool = []; *for*(var i=0; i<1024*10; i++){ queryPool.push(ext.createQueryANGLE()); } *// frame object to hold queries* var Frame = *function*(){ this.queries = []; } *// called at the start of a frame, returnes used queries* Frame.prototype.start = *function*(frameCount){ this.frameCount = frameCount; *while*(this.queries.length > 0){ queryPool.push(this.queries.pop()); } } *// called during a frame to obtain queries from the pool* Frame.prototype.createQuery = *function*(){ var query = queryPool.pop(); query.onready = null; this.queries.push(query); return query; } /*/ called at the end of a frame, attaches callback to the last query of the frame* Frame.prototype.finish = *function*(callback){ this.queries[this.queries.length-1].onready = callback; } *// create a 10 frame cache* var framePool = []; for(var i=0; i<10; i++){ framePool.push(new Frame()); } *// passed to frame.finish as callback* var onFrameMeasured = *function*(frame){ *// whatever processing on frame.queries, they're all ready* framePool.push(frame); *// return frame to the frame pool* } var frameCounter = 0; var draw = *function*(){ *// start a frame* var frame = framePool.pop(); frame.start(frameCounter++); *// work with your thousands of query objects* *for*(var i=0; i<1000; i++){ var query = frame.createQuery(); ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); gl.drawElements(...); ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); } *// attach one callback per frame* frame.finish(onFrameMeasured); *// wash rhinse repeat* requestAnimationFrame(draw); } requestAnimationFrame(draw); -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Tue Apr 9 20:13:49 2013 From: tpa...@ (Tony Parisi) Date: Tue, 9 Apr 2013 20:13:49 -0700 Subject: [Public WebGL] Learning WebGL Has a New Honcho Message-ID: Hi all, For better or worse, you're looking at the new editor of Learning WebGL. More info at http://learningwebgl.com/blog/ Giles, you'll be missed! I hope I can do *half* the job you did over the last four years. FIrst up: update the lessons to use the new glMatrix and um, get rid of those "bad practices" Gregg was railing at. Yours visually; Tony -- Tony Parisi tparisi...@ CTO at Large 415.902.8002 Skype auradeluxe Follow me on Twitter! http://twitter.com/auradeluxe Read my blog at http://www.tonyparisi.com/ Read my book! *WebGL, Up and Running* http://shop.oreilly.com/product/0636920024729.do http://www.amazon.com/dp/144932357X -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Tue Apr 9 20:35:57 2013 From: tpa...@ (Tony Parisi) Date: Tue, 9 Apr 2013 20:35:57 -0700 Subject: [Public WebGL] Did Chrome Just Break WebGL? Message-ID: Running Version 26.0.1410.63 - I can't seem to run any WebGL that used to work... Funny timing! lol -- Tony Parisi tparisi...@ CTO at Large 415.902.8002 Skype auradeluxe Follow me on Twitter! http://twitter.com/auradeluxe Read my blog at http://www.tonyparisi.com/ Learn WebGL http://learningwebgl.com/ Read my book! *WebGL, Up and Running* http://shop.oreilly.com/product/0636920024729.do http://www.amazon.com/dp/144932357X -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Tue Apr 9 20:48:58 2013 From: baj...@ (Brandon Jones) Date: Tue, 9 Apr 2013 20:48:58 -0700 Subject: [Public WebGL] Did Chrome Just Break WebGL? In-Reply-To: References: Message-ID: Yes, WebGL is broken in Chrome stable at the moment. I assume full responsibility. Sorry! The good news is that the problem has been identified and a fix is being processed right now. We should be able to get a working version out soon. In the meantime WebGL works fine in the Beta, Dev, and Canary channels, and if you really need it to work in stable you can get around the bug by running with the "--disable-gl-multisampling" command line flag. --Brandon Jones On Tue, Apr 9, 2013 at 8:35 PM, Tony Parisi wrote: > Running Version 26.0.1410.63 - I can't seem to run any WebGL that used to > work... > > Funny timing! lol > > -- > Tony Parisi tparisi...@ > CTO at Large 415.902.8002 > Skype auradeluxe > Follow me on Twitter! http://twitter.com/auradeluxe > Read my blog at http://www.tonyparisi.com/ > Learn WebGL http://learningwebgl.com/ > > Read my book! *WebGL, Up and Running* > http://shop.oreilly.com/product/0636920024729.do > http://www.amazon.com/dp/144932357X > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Tue Apr 9 20:49:52 2013 From: tpa...@ (Tony Parisi) Date: Tue, 9 Apr 2013 20:49:52 -0700 Subject: [Public WebGL] Did Chrome Just Break WebGL? In-Reply-To: References: Message-ID: Ugh does that mean FSAA is dead again? !@#$. Don't worry, not blaming you. But jeez On Tue, Apr 9, 2013 at 8:48 PM, Brandon Jones wrote: > Yes, WebGL is broken in Chrome stable at the moment. I assume full > responsibility. Sorry! > > The good news is that the problem has been identified and a fix is being > processed right now. We should be able to get a working version out soon. > In the meantime WebGL works fine in the Beta, Dev, and Canary channels, and > if you really need it to work in stable you can get around the bug by > running with the "--disable-gl-multisampling" command line flag. > > --Brandon Jones > > > On Tue, Apr 9, 2013 at 8:35 PM, Tony Parisi wrote: > >> Running Version 26.0.1410.63 - I can't seem to run any WebGL that used >> to work... >> >> Funny timing! lol >> >> -- >> Tony Parisi tparisi...@ >> CTO at Large 415.902.8002 >> Skype auradeluxe >> Follow me on Twitter! http://twitter.com/auradeluxe >> Read my blog at http://www.tonyparisi.com/ >> Learn WebGL http://learningwebgl.com/ >> >> Read my book! *WebGL, Up and Running* >> http://shop.oreilly.com/product/0636920024729.do >> http://www.amazon.com/dp/144932357X >> >> > -- Tony Parisi tparisi...@ CTO at Large 415.902.8002 Skype auradeluxe Follow me on Twitter! http://twitter.com/auradeluxe Read my blog at http://www.tonyparisi.com/ Learn WebGL http://learningwebgl.com/ Read my book! *WebGL, Up and Running* http://shop.oreilly.com/product/0636920024729.do http://www.amazon.com/dp/144932357X -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Tue Apr 9 20:52:15 2013 From: baj...@ (Brandon Jones) Date: Tue, 9 Apr 2013 20:52:15 -0700 Subject: [Public WebGL] Did Chrome Just Break WebGL? In-Reply-To: References: Message-ID: Quite the opposite, actually! The next build should fix FSAA on Mac, which has been disabled for a while. It should be noted the the current WebGL bug only affects Macs. --Brandon On Tuesday, April 9, 2013, Tony Parisi wrote: > Ugh does that mean FSAA is dead again? > > !@#$. > > Don't worry, not blaming you. But jeez > > > > On Tue, Apr 9, 2013 at 8:48 PM, Brandon Jones > > wrote: > >> Yes, WebGL is broken in Chrome stable at the moment. I assume full >> responsibility. Sorry! >> >> The good news is that the problem has been identified and a fix is being >> processed right now. We should be able to get a working version out soon. >> In the meantime WebGL works fine in the Beta, Dev, and Canary channels, and >> if you really need it to work in stable you can get around the bug by >> running with the "--disable-gl-multisampling" command line flag. >> >> --Brandon Jones >> >> >> On Tue, Apr 9, 2013 at 8:35 PM, Tony Parisi >> > wrote: >> >>> Running Version 26.0.1410.63 - I can't seem to run any WebGL that used >>> to work... >>> >>> Funny timing! lol >>> >>> -- >>> Tony Parisi tparisi...@ >>> CTO at Large 415.902.8002 >>> Skype auradeluxe >>> Follow me on Twitter! http://twitter.com/auradeluxe >>> Read my blog at http://www.tonyparisi.com/ >>> Learn WebGL http://learningwebgl.com/ >>> >>> Read my book! *WebGL, Up and Running* >>> http://shop.oreilly.com/product/0636920024729.do >>> http://www.amazon.com/dp/144932357X >>> >>> >> > > > -- > Tony Parisi tparisi...@ > CTO at Large 415.902.8002 > Skype auradeluxe > Follow me on Twitter! http://twitter.com/auradeluxe > Read my blog at http://www.tonyparisi.com/ > Learn WebGL http://learningwebgl.com/ > > Read my book! *WebGL, Up and Running* > http://shop.oreilly.com/product/0636920024729.do > http://www.amazon.com/dp/144932357X > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Tue Apr 9 20:54:14 2013 From: tpa...@ (Tony Parisi) Date: Tue, 9 Apr 2013 20:54:14 -0700 Subject: [Public WebGL] Did Chrome Just Break WebGL? In-Reply-To: References: Message-ID: Good news/bad news I guess. Well it will be nice when FSAA actually gets fixed On Tue, Apr 9, 2013 at 8:52 PM, Brandon Jones wrote: > Quite the opposite, actually! The next build should fix FSAA on Mac, which > has been disabled for a while. > > It should be noted the the current WebGL bug only affects Macs. > > --Brandon > > > On Tuesday, April 9, 2013, Tony Parisi wrote: > >> Ugh does that mean FSAA is dead again? >> >> !@#$. >> >> Don't worry, not blaming you. But jeez >> >> >> >> On Tue, Apr 9, 2013 at 8:48 PM, Brandon Jones wrote: >> >>> Yes, WebGL is broken in Chrome stable at the moment. I assume full >>> responsibility. Sorry! >>> >>> The good news is that the problem has been identified and a fix is being >>> processed right now. We should be able to get a working version out soon. >>> In the meantime WebGL works fine in the Beta, Dev, and Canary channels, and >>> if you really need it to work in stable you can get around the bug by >>> running with the "--disable-gl-multisampling" command line flag. >>> >>> --Brandon Jones >>> >>> >>> On Tue, Apr 9, 2013 at 8:35 PM, Tony Parisi wrote: >>> >>>> Running Version 26.0.1410.63 - I can't seem to run any WebGL that used >>>> to work... >>>> >>>> Funny timing! lol >>>> >>>> -- >>>> Tony Parisi tparisi...@ >>>> CTO at Large 415.902.8002 >>>> Skype auradeluxe >>>> Follow me on Twitter! http://twitter.com/auradeluxe >>>> Read my blog at http://www.tonyparisi.com/ >>>> Learn WebGL http://learningwebgl.com/ >>>> >>>> Read my book! *WebGL, Up and Running* >>>> http://shop.oreilly.com/product/0636920024729.do >>>> http://www.amazon.com/dp/144932357X >>>> >>>> >>> >> >> >> -- >> Tony Parisi tparisi...@ >> CTO at Large 415.902.8002 >> Skype auradeluxe >> Follow me on Twitter! http://twitter.com/auradeluxe >> Read my blog at http://www.tonyparisi.com/ >> Learn WebGL http://learningwebgl.com/ >> >> Read my book! *WebGL, Up and Running* >> http://shop.oreilly.com/product/0636920024729.do >> http://www.amazon.com/dp/144932357X >> >> -- Tony Parisi tparisi...@ CTO at Large 415.902.8002 Skype auradeluxe Follow me on Twitter! http://twitter.com/auradeluxe Read my blog at http://www.tonyparisi.com/ Learn WebGL http://learningwebgl.com/ Read my book! *WebGL, Up and Running* http://shop.oreilly.com/product/0636920024729.do http://www.amazon.com/dp/144932357X -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Wed Apr 10 00:17:32 2013 From: gma...@ (Gregg Tavares) Date: Wed, 10 Apr 2013 00:17:32 -0700 Subject: [Public WebGL] WebGL Capture Message-ID: I recently needed to try to create a reduced test case from a larger app so I wrote this library that captures all the WebGL calls and generates a HTML/JavaScript with just those calls to reproduce the scene. It's very alpha but I have managed to capture a few things. I suspect Ben Vanik will eventually add something similar and better to either the WebGL Inspector or the Google Web Tracing Framework but for the time being, if you find this useful it's here https://github.com/greggman/webgl-capture -------------- next part -------------- An HTML attachment was scrubbed... URL: From baj...@ Wed Apr 10 11:34:42 2013 From: baj...@ (Brandon Jones) Date: Wed, 10 Apr 2013 11:34:42 -0700 Subject: [Public WebGL] Did Chrome Just Break WebGL? In-Reply-To: References: Message-ID: The latest OSX Chrome stable (26.0.1410.65), which was released today, fixes the WebGL context creation issue. Apologies again for the inconvenience! --Brandon Jones On Tue, Apr 9, 2013 at 8:35 PM, Tony Parisi wrote: > Running Version 26.0.1410.63 - I can't seem to run any WebGL that used to > work... > > Funny timing! lol > > -- > Tony Parisi tparisi...@ > CTO at Large 415.902.8002 > Skype auradeluxe > Follow me on Twitter! http://twitter.com/auradeluxe > Read my blog at http://www.tonyparisi.com/ > Learn WebGL http://learningwebgl.com/ > > Read my book! *WebGL, Up and Running* > http://shop.oreilly.com/product/0636920024729.do > http://www.amazon.com/dp/144932357X > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Wed Apr 10 11:43:01 2013 From: tpa...@ (Tony Parisi) Date: Wed, 10 Apr 2013 11:43:01 -0700 Subject: [Public WebGL] Did Chrome Just Break WebGL? In-Reply-To: References: Message-ID: Nice! Thanks Brandon. It appears that I still need to switch on the flag Override software rendering list in order to get the FSAA working. Is that just temporary? On Wed, Apr 10, 2013 at 11:34 AM, Brandon Jones wrote: > The latest OSX Chrome stable (26.0.1410.65), which was released today, > fixes the WebGL context creation issue. Apologies again for the > inconvenience! > > --Brandon Jones > > > On Tue, Apr 9, 2013 at 8:35 PM, Tony Parisi wrote: > >> Running Version 26.0.1410.63 - I can't seem to run any WebGL that used >> to work... >> >> Funny timing! lol >> >> -- >> Tony Parisi tparisi...@ >> CTO at Large 415.902.8002 >> Skype auradeluxe >> Follow me on Twitter! http://twitter.com/auradeluxe >> Read my blog at http://www.tonyparisi.com/ >> Learn WebGL http://learningwebgl.com/ >> >> Read my book! *WebGL, Up and Running* >> http://shop.oreilly.com/product/0636920024729.do >> http://www.amazon.com/dp/144932357X >> >> > -- Tony Parisi tparisi...@ CTO at Large 415.902.8002 Skype auradeluxe Follow me on Twitter! http://twitter.com/auradeluxe Read my blog at http://www.tonyparisi.com/ Learn WebGL http://learningwebgl.com/ Read my book! *WebGL, Up and Running* http://shop.oreilly.com/product/0636920024729.do http://www.amazon.com/dp/144932357X -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Wed Apr 10 13:53:43 2013 From: jgi...@ (Jeff Gilbert) Date: Wed, 10 Apr 2013 13:53:43 -0700 (PDT) Subject: [Public WebGL] Did Chrome Just Break WebGL? In-Reply-To: Message-ID: <45708406.968458.1365627223493.JavaMail.root@mozilla.com> Do you mean MSAA? FSAA is always doable by just doubling the drawingbuffer size for the same canvas size. -Jeff ----- Original Message ----- From: "Tony Parisi" To: "Brandon Jones" Cc: "public webgl" Sent: Wednesday, April 10, 2013 11:43:01 AM Subject: Re: [Public WebGL] Did Chrome Just Break WebGL? Nice! Thanks Brandon. It appears that I still need to switch on the flag Override software rendering list in order to get the FSAA working. Is that just temporary? On Wed, Apr 10, 2013 at 11:34 AM, Brandon Jones < bajones...@ > wrote: The latest OSX Chrome stable (26.0.1410.65), which was released today, fixes the WebGL context creation issue. Apologies again for the inconvenience! --Brandon Jones On Tue, Apr 9, 2013 at 8:35 PM, Tony Parisi < tparisi...@ > wrote: Running Version 26.0.1410.63 - I can't seem to run any WebGL that used to work... Funny timing! lol -- Tony Parisi tparisi...@ CTO at Large 415.902.8002 Skype auradeluxe Follow me on Twitter! http://twitter.com/auradeluxe Read my blog at http://www.tonyparisi.com/ Learn WebGL http://learningwebgl.com/ Read my book! WebGL, Up and Running http://shop.oreilly.com/product/0636920024729.do http://www.amazon.com/dp/144932357X -- Tony Parisi tparisi...@ CTO at Large 415.902.8002 Skype auradeluxe Follow me on Twitter! http://twitter.com/auradeluxe Read my blog at http://www.tonyparisi.com/ Learn WebGL http://learningwebgl.com/ Read my book! WebGL, Up and Running http://shop.oreilly.com/product/0636920024729.do http://www.amazon.com/dp/144932357X ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From baj...@ Wed Apr 10 13:55:27 2013 From: baj...@ (Brandon Jones) Date: Wed, 10 Apr 2013 13:55:27 -0700 Subject: [Public WebGL] Did Chrome Just Break WebGL? In-Reply-To: <45708406.968458.1365627223493.JavaMail.root@mozilla.com> References: <45708406.968458.1365627223493.JavaMail.root@mozilla.com> Message-ID: Sorry, yes. MSAA. (Also known as: Whatever the browser turns on when "antialias: true" is set in the context options) On Wed, Apr 10, 2013 at 1:53 PM, Jeff Gilbert wrote: > Do you mean MSAA? FSAA is always doable by just doubling the drawingbuffer > size for the same canvas size. > > -Jeff > > ----- Original Message ----- > From: "Tony Parisi" > To: "Brandon Jones" > Cc: "public webgl" > Sent: Wednesday, April 10, 2013 11:43:01 AM > Subject: Re: [Public WebGL] Did Chrome Just Break WebGL? > > > > Nice! Thanks Brandon. > > It appears that I still need to switch on the flag Override software > rendering list in order to get the FSAA working. Is that just temporary? > > > > > On Wed, Apr 10, 2013 at 11:34 AM, Brandon Jones < bajones...@ > > wrote: > > > > The latest OSX Chrome stable (26.0.1410.65), which was released today, > fixes the WebGL context creation issue. Apologies again for the > inconvenience! > > > --Brandon Jones > > > > > On Tue, Apr 9, 2013 at 8:35 PM, Tony Parisi < tparisi...@ > wrote: > > > > > > > Running Version 26.0.1410.63 - I can't seem to run any WebGL that used to > work... > > Funny timing! lol > > > -- > > > Tony Parisi tparisi...@ > CTO at Large 415.902.8002 > Skype auradeluxe > Follow me on Twitter! http://twitter.com/auradeluxe > Read my blog at http://www.tonyparisi.com/ > Learn WebGL http://learningwebgl.com/ > > > Read my book! WebGL, Up and Running > http://shop.oreilly.com/product/0636920024729.do > http://www.amazon.com/dp/144932357X > > > > > > -- > > > Tony Parisi tparisi...@ > CTO at Large 415.902.8002 > Skype auradeluxe > Follow me on Twitter! http://twitter.com/auradeluxe > Read my blog at http://www.tonyparisi.com/ > Learn WebGL http://learningwebgl.com/ > > > Read my book! WebGL, Up and Running > http://shop.oreilly.com/product/0636920024729.do > http://www.amazon.com/dp/144932357X > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Wed Apr 10 14:04:05 2013 From: tpa...@ (Tony Parisi) Date: Wed, 10 Apr 2013 14:04:05 -0700 Subject: [Public WebGL] Did Chrome Just Break WebGL? In-Reply-To: References: <45708406.968458.1365627223493.JavaMail.root@mozilla.com> Message-ID: Sorry, I started the mistake before Brandon propagated it. Yeah, it's actually MSAA On Wed, Apr 10, 2013 at 1:55 PM, Brandon Jones wrote: > Sorry, yes. MSAA. (Also known as: Whatever the browser turns on when > "antialias: true" is set in the context options) > > > On Wed, Apr 10, 2013 at 1:53 PM, Jeff Gilbert wrote: > >> Do you mean MSAA? FSAA is always doable by just doubling the >> drawingbuffer size for the same canvas size. >> >> -Jeff >> >> ----- Original Message ----- >> From: "Tony Parisi" >> To: "Brandon Jones" >> Cc: "public webgl" >> Sent: Wednesday, April 10, 2013 11:43:01 AM >> Subject: Re: [Public WebGL] Did Chrome Just Break WebGL? >> >> >> >> Nice! Thanks Brandon. >> >> It appears that I still need to switch on the flag Override software >> rendering list in order to get the FSAA working. Is that just temporary? >> >> >> >> >> On Wed, Apr 10, 2013 at 11:34 AM, Brandon Jones < bajones...@ > >> wrote: >> >> >> >> The latest OSX Chrome stable (26.0.1410.65), which was released today, >> fixes the WebGL context creation issue. Apologies again for the >> inconvenience! >> >> >> --Brandon Jones >> >> >> >> >> On Tue, Apr 9, 2013 at 8:35 PM, Tony Parisi < tparisi...@ > wrote: >> >> >> >> >> >> >> Running Version 26.0.1410.63 - I can't seem to run any WebGL that used to >> work... >> >> Funny timing! lol >> >> >> -- >> >> >> Tony Parisi tparisi...@ >> CTO at Large 415.902.8002 >> Skype auradeluxe >> Follow me on Twitter! http://twitter.com/auradeluxe >> Read my blog at http://www.tonyparisi.com/ >> Learn WebGL http://learningwebgl.com/ >> >> >> Read my book! WebGL, Up and Running >> http://shop.oreilly.com/product/0636920024729.do >> http://www.amazon.com/dp/144932357X >> >> >> >> >> >> -- >> >> >> Tony Parisi tparisi...@ >> CTO at Large 415.902.8002 >> Skype auradeluxe >> Follow me on Twitter! http://twitter.com/auradeluxe >> Read my blog at http://www.tonyparisi.com/ >> Learn WebGL http://learningwebgl.com/ >> >> >> Read my book! WebGL, Up and Running >> http://shop.oreilly.com/product/0636920024729.do >> http://www.amazon.com/dp/144932357X >> >> > -- Tony Parisi tparisi...@ CTO at Large 415.902.8002 Skype auradeluxe Follow me on Twitter! http://twitter.com/auradeluxe Read my blog at http://www.tonyparisi.com/ Learn WebGL http://learningwebgl.com/ Read my book! *WebGL, Up and Running* http://shop.oreilly.com/product/0636920024729.do http://www.amazon.com/dp/144932357X -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Apr 10 15:02:00 2013 From: kbr...@ (Kenneth Russell) Date: Wed, 10 Apr 2013 15:02:00 -0700 Subject: [Public WebGL] WebGL Capture In-Reply-To: References: Message-ID: This is awesome! Thanks for writing it and putting it out there. It will be a big help in creating reduced test cases from real-world applications. -Ken On Wed, Apr 10, 2013 at 12:17 AM, Gregg Tavares wrote: > I recently needed to try to create a reduced test case from a larger app so > I wrote this library that captures all the WebGL calls and generates a > HTML/JavaScript with just those calls to reproduce the scene. > > It's very alpha but I have managed to capture a few things. > > I suspect Ben Vanik will eventually add something similar and better to > either the WebGL Inspector or the Google Web Tracing Framework but for the > time being, if you find this useful it's here > > https://github.com/greggman/webgl-capture > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kbr...@ Thu Apr 11 13:57:31 2013 From: kbr...@ (Kenneth Russell) Date: Thu, 11 Apr 2013 13:57:31 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: Thanks for the sample. The problem is that even in this form, the query's result would still be retrieved with a polling API (getQueryParameter). This means that the spec would still have to include all of the caveats like getQueryParameter generating INVALID_OPERATION if the query hadn't been processed. To address this issue, each query would need a callback, which would receive the result as argument. There would be no way of retrieving the query's result separately. Another version of the timer query extension is about to be published by the ES WG which introduces the concept of invalidating previous queries, specifically if the device goes into a low power state after the query is issued. This fits within the callback model; it would be called with a different argument if the query was invalidated. I'm going to try restructuring this extension in terms of callbacks. It may turn out to be too inefficient. It'll probably be necessary to prototype both forms to see. -Ken On Tue, Apr 9, 2013 at 4:02 AM, Florian B?sch wrote: > So I have made the argument that callbacks would be no worse than polling, > I'd like to illustrate that in code. Below is an example of how thousands of > queries would be used but only one callback per frame is attached. > > // create a 10k query cache > var queryPool = []; > for(var i=0; i<1024*10; i++){ > queryPool.push(ext.createQueryANGLE()); > } > > // frame object to hold queries > var Frame = function(){ this.queries = []; } > > // called at the start of a frame, returnes used queries > Frame.prototype.start = function(frameCount){ > this.frameCount = frameCount; > while(this.queries.length > 0){ > queryPool.push(this.queries.pop()); > } > } > > // called during a frame to obtain queries from the pool > Frame.prototype.createQuery = function(){ > var query = queryPool.pop(); > query.onready = null; > this.queries.push(query); > return query; > } > > // called at the end of a frame, attaches callback to the last query of the > frame > Frame.prototype.finish = function(callback){ > this.queries[this.queries.length-1].onready = callback; > } > > // create a 10 frame cache > var framePool = []; > for(var i=0; i<10; i++){ > framePool.push(new Frame()); > } > > // passed to frame.finish as callback > var onFrameMeasured = function(frame){ > // whatever processing on frame.queries, they're all ready > framePool.push(frame); // return frame to the frame pool > } > > var frameCounter = 0; > var draw = function(){ > // start a frame > var frame = framePool.pop(); > frame.start(frameCounter++); > > // work with your thousands of query objects > for(var i=0; i<1000; i++){ > var query = frame.createQuery(); > ext.beginQueryANGLE(ext.TIME_ELAPSED_ANGLE, query); > gl.drawElements(...); > ext.endQueryANGLE(ext.TIME_ELAPSED_ANGLE); > } > > // attach one callback per frame > frame.finish(onFrameMeasured); > > // wash rhinse repeat > requestAnimationFrame(draw); > } > > requestAnimationFrame(draw); ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Thu Apr 11 14:13:55 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Thu, 11 Apr 2013 23:13:55 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Thu, Apr 11, 2013 at 10:57 PM, Kenneth Russell wrote: > The problem is that even in this form, the query's result would still > be retrieved with a polling API (getQueryParameter). This means that > the spec would still have to include all of the caveats like > getQueryParameter generating INVALID_OPERATION if the query hadn't > been processed. > Is that bad? > To address this issue, each query would need a callback, which would > receive the result as argument. There would be no way of retrieving > the query's result separately. > That's not really workable in usecases that Ben outlined. It's thousands of queries per frame. That's one important usecase, where you capture a whole hierarchy of timings and then drill down into what you want to know. Even if it wasn't seriously contest on performance, you can't "drill down" with callbacks, it's not usable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Apr 11 16:06:58 2013 From: kbr...@ (Kenneth Russell) Date: Thu, 11 Apr 2013 16:06:58 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Thu, Apr 11, 2013 at 2:13 PM, Florian B?sch wrote: > On Thu, Apr 11, 2013 at 10:57 PM, Kenneth Russell wrote: >> >> The problem is that even in this form, the query's result would still >> be retrieved with a polling API (getQueryParameter). This means that >> the spec would still have to include all of the caveats like >> getQueryParameter generating INVALID_OPERATION if the query hadn't >> been processed. > > Is that bad? Yes -- it means that badly written applications would still try to spin loop waiting for getQueryParameter to return a valid value. This must be specified to not work, and tested. >> >> To address this issue, each query would need a callback, which would >> receive the result as argument. There would be no way of retrieving >> the query's result separately. > > That's not really workable in usecases that Ben outlined. It's thousands of > queries per frame. That's one important usecase, where you capture a whole > hierarchy of timings and then drill down into what you want to know. Even if > it wasn't seriously contest on performance, you can't "drill down" with > callbacks, it's not usable. The callback model can be converted into the polling model. The callback would just store the result on the query object, or in some sort of map. Then the tool can choose to display a subset of the results. The question of whether it would perform acceptably is the main issue. I am certainly concerned about this, but think we need to prototype it to measure. -Ken ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From pya...@ Thu Apr 11 16:17:33 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 01:17:33 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Fri, Apr 12, 2013 at 1:06 AM, Kenneth Russell wrote: > Yes -- it means that badly written applications would still try to > spin loop waiting for getQueryParameter to return a valid value. This > must be specified to not work, and tested. This simply cannot be a consideration. That's silly. You cannot possibly hope to prevent people from doing stupid things. This isn't the job of an API. You can make an API that doesn't force or invite you to do stupid things. But you cannot make an API that will preclude every stupid thing people might come up with. It's not possible. The sheer audacity of thinking that is so futile it baggers belief we're even talking about that. > The callback model can be converted into the polling model. The > callback would just store the result on the query object, or in some > sort of map. Then the tool can choose to display a subset of the > results. > This isn't going to work, and you know it, and I know it. Querying thousands of timer objects, by default, without escape is already in its own right a massive cost. You can forget that. And though I don't have the insight to comment on how expensive callbacks are, I believe nobody so far contested Bens point that it takes a fair amount of time. So sure, go and test it, and even if you find callbacks to be super-?ber-duper performant, *it's still querying every single one of those timer queries for its value which is not acceptable.* -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben...@ Thu Apr 11 16:23:00 2013 From: ben...@ (Ben Vanik) Date: Thu, 11 Apr 2013 16:23:00 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: With a high level of confidence I can tell you that it won't be acceptable to use callbacks for some of the scenarios this API is useful for and those are the very same scenarios that make me really wish to see it implemented. I still do not understand the desire to radically alter the way the API is designed (from a way that can be used performantly to a way with (arguably) questionable performance characteristics) when there are solutions to the issues that don't require it. Instead of changing this API and implementing it (and realistic demos to benchmark) twice I'd rather see work done on making readPixels async. That's a call that's killing us today and would actually have a massive benefit in being switched to a callback. On Thu, Apr 11, 2013 at 4:06 PM, Kenneth Russell wrote: > On Thu, Apr 11, 2013 at 2:13 PM, Florian B?sch wrote: > > On Thu, Apr 11, 2013 at 10:57 PM, Kenneth Russell > wrote: > >> > >> The problem is that even in this form, the query's result would still > >> be retrieved with a polling API (getQueryParameter). This means that > >> the spec would still have to include all of the caveats like > >> getQueryParameter generating INVALID_OPERATION if the query hadn't > >> been processed. > > > > Is that bad? > > Yes -- it means that badly written applications would still try to > spin loop waiting for getQueryParameter to return a valid value. This > must be specified to not work, and tested. > > >> > >> To address this issue, each query would need a callback, which would > >> receive the result as argument. There would be no way of retrieving > >> the query's result separately. > > > > That's not really workable in usecases that Ben outlined. It's thousands > of > > queries per frame. That's one important usecase, where you capture a > whole > > hierarchy of timings and then drill down into what you want to know. > Even if > > it wasn't seriously contest on performance, you can't "drill down" with > > callbacks, it's not usable. > > The callback model can be converted into the polling model. The > callback would just store the result on the query object, or in some > sort of map. Then the tool can choose to display a subset of the > results. > > The question of whether it would perform acceptably is the main issue. > I am certainly concerned about this, but think we need to prototype it > to measure. > > -Ken > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Thu Apr 11 17:04:49 2013 From: gma...@ (Gregg Tavares) Date: Thu, 11 Apr 2013 17:04:49 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Thu, Apr 11, 2013 at 4:23 PM, Ben Vanik wrote: > With a high level of confidence I can tell you that it won't be acceptable > to use callbacks for some of the scenarios this API is useful for and those > are the very same scenarios that make me really wish to see it implemented. > I still do not understand the desire to radically alter the way the API is > designed (from a way that can be used performantly to a way with (arguably) > questionable performance characteristics) when there are solutions to the > issues that don't require it. > There aren't solutions as pointed out above. Devs will abuse an API anyway they can. If setTimeout(checkQuerys, 0) gets them a faster framerate they'll do it. > > Instead of changing this API and implementing it (and realistic demos to > benchmark) twice I'd rather see work done on making readPixels async. > That's a call that's killing us today and would actually have a massive > benefit in being switched to a callback. > > > > > On Thu, Apr 11, 2013 at 4:06 PM, Kenneth Russell wrote: > >> On Thu, Apr 11, 2013 at 2:13 PM, Florian B?sch wrote: >> > On Thu, Apr 11, 2013 at 10:57 PM, Kenneth Russell >> wrote: >> >> >> >> The problem is that even in this form, the query's result would still >> >> be retrieved with a polling API (getQueryParameter). This means that >> >> the spec would still have to include all of the caveats like >> >> getQueryParameter generating INVALID_OPERATION if the query hadn't >> >> been processed. >> > >> > Is that bad? >> >> Yes -- it means that badly written applications would still try to >> spin loop waiting for getQueryParameter to return a valid value. This >> must be specified to not work, and tested. >> >> >> >> >> To address this issue, each query would need a callback, which would >> >> receive the result as argument. There would be no way of retrieving >> >> the query's result separately. >> > >> > That's not really workable in usecases that Ben outlined. It's >> thousands of >> > queries per frame. That's one important usecase, where you capture a >> whole >> > hierarchy of timings and then drill down into what you want to know. >> Even if >> > it wasn't seriously contest on performance, you can't "drill down" with >> > callbacks, it's not usable. >> >> The callback model can be converted into the polling model. The >> callback would just store the result on the query object, or in some >> sort of map. Then the tool can choose to display a subset of the >> results. >> >> The question of whether it would perform acceptably is the main issue. >> I am certainly concerned about this, but think we need to prototype it >> to measure. >> >> -Ken >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Apr 11 18:45:09 2013 From: kbr...@ (Kenneth Russell) Date: Thu, 11 Apr 2013 18:45:09 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Thu, Apr 11, 2013 at 5:04 PM, Gregg Tavares wrote: > > > > On Thu, Apr 11, 2013 at 4:23 PM, Ben Vanik wrote: >> >> With a high level of confidence I can tell you that it won't be acceptable >> to use callbacks for some of the scenarios this API is useful for and those >> are the very same scenarios that make me really wish to see it implemented. >> I still do not understand the desire to radically alter the way the API is >> designed (from a way that can be used performantly to a way with (arguably) >> questionable performance characteristics) when there are solutions to the >> issues that don't require it. > > > There aren't solutions as pointed out above. > > Devs will abuse an API anyway they can. If setTimeout(checkQuerys, 0) gets > them a faster framerate they'll do it. Here's a restructuring of the API to use callbacks. https://github.com/kenrussell/WebGL/tree/timer-query-callbacks I'm not planning to push this branch into the repository. Thinking about the use case where 1000 queries are issued in a frame, but results from only a couple are fetched later, I agree that requiring 1000 event objects to be created and 1000 callbacks called is too inefficient. >> Instead of changing this API and implementing it (and realistic demos to >> benchmark) twice I'd rather see work done on making readPixels async. That's >> a call that's killing us today and would actually have a massive benefit in >> being switched to a callback. Personally I agree that there are higher priority things to work on than this extension right now. If agreement is reached on a direction for the API, I'll be happy to invest more time in it. -Ken >> On Thu, Apr 11, 2013 at 4:06 PM, Kenneth Russell wrote: >>> >>> On Thu, Apr 11, 2013 at 2:13 PM, Florian B?sch wrote: >>> > On Thu, Apr 11, 2013 at 10:57 PM, Kenneth Russell >>> > wrote: >>> >> >>> >> The problem is that even in this form, the query's result would still >>> >> be retrieved with a polling API (getQueryParameter). This means that >>> >> the spec would still have to include all of the caveats like >>> >> getQueryParameter generating INVALID_OPERATION if the query hadn't >>> >> been processed. >>> > >>> > Is that bad? >>> >>> Yes -- it means that badly written applications would still try to >>> spin loop waiting for getQueryParameter to return a valid value. This >>> must be specified to not work, and tested. >>> >>> >> >>> >> To address this issue, each query would need a callback, which would >>> >> receive the result as argument. There would be no way of retrieving >>> >> the query's result separately. >>> > >>> > That's not really workable in usecases that Ben outlined. It's >>> > thousands of >>> > queries per frame. That's one important usecase, where you capture a >>> > whole >>> > hierarchy of timings and then drill down into what you want to know. >>> > Even if >>> > it wasn't seriously contest on performance, you can't "drill down" with >>> > callbacks, it's not usable. >>> >>> The callback model can be converted into the polling model. The >>> callback would just store the result on the query object, or in some >>> sort of map. Then the tool can choose to display a subset of the >>> results. >>> >>> The question of whether it would perform acceptably is the main issue. >>> I am certainly concerned about this, but think we need to prototype it >>> to measure. >>> >>> -Ken >> >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From jam...@ Thu Apr 11 19:29:26 2013 From: jam...@ (James Robinson) Date: Thu, 11 Apr 2013 19:29:26 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Thu, Apr 11, 2013 at 6:45 PM, Kenneth Russell wrote: > > On Thu, Apr 11, 2013 at 5:04 PM, Gregg Tavares wrote: > > > > > > > > On Thu, Apr 11, 2013 at 4:23 PM, Ben Vanik wrote: > >> > >> With a high level of confidence I can tell you that it won't be > acceptable > >> to use callbacks for some of the scenarios this API is useful for and > those > >> are the very same scenarios that make me really wish to see it > implemented. > >> I still do not understand the desire to radically alter the way the API > is > >> designed (from a way that can be used performantly to a way with > (arguably) > >> questionable performance characteristics) when there are solutions to > the > >> issues that don't require it. > > > > > > There aren't solutions as pointed out above. > > > > Devs will abuse an API anyway they can. If setTimeout(checkQuerys, 0) > gets > > them a faster framerate they'll do it. > > Here's a restructuring of the API to use callbacks. > > https://github.com/kenrussell/WebGL/tree/timer-query-callbacks > > I'm not planning to push this branch into the repository. Thinking > about the use case where 1000 queries are issued in a frame, but > results from only a couple are fetched later, I agree that requiring > 1000 event objects to be created and 1000 callbacks called is too > inefficient. > > The more modern way to achieve this is with http://dom.spec.whatwg.org/#futures. This still requires allocating an object per query but makes a lot of the syntax around it nicer. - James > > >> Instead of changing this API and implementing it (and realistic demos to > >> benchmark) twice I'd rather see work done on making readPixels async. > That's > >> a call that's killing us today and would actually have a massive > benefit in > >> being switched to a callback. > > Personally I agree that there are higher priority things to work on > than this extension right now. If agreement is reached on a direction > for the API, I'll be happy to invest more time in it. > > -Ken > > > >> On Thu, Apr 11, 2013 at 4:06 PM, Kenneth Russell > wrote: > >>> > >>> On Thu, Apr 11, 2013 at 2:13 PM, Florian B?sch > wrote: > >>> > On Thu, Apr 11, 2013 at 10:57 PM, Kenneth Russell > >>> > wrote: > >>> >> > >>> >> The problem is that even in this form, the query's result would > still > >>> >> be retrieved with a polling API (getQueryParameter). This means that > >>> >> the spec would still have to include all of the caveats like > >>> >> getQueryParameter generating INVALID_OPERATION if the query hadn't > >>> >> been processed. > >>> > > >>> > Is that bad? > >>> > >>> Yes -- it means that badly written applications would still try to > >>> spin loop waiting for getQueryParameter to return a valid value. This > >>> must be specified to not work, and tested. > >>> > >>> >> > >>> >> To address this issue, each query would need a callback, which would > >>> >> receive the result as argument. There would be no way of retrieving > >>> >> the query's result separately. > >>> > > >>> > That's not really workable in usecases that Ben outlined. It's > >>> > thousands of > >>> > queries per frame. That's one important usecase, where you capture a > >>> > whole > >>> > hierarchy of timings and then drill down into what you want to know. > >>> > Even if > >>> > it wasn't seriously contest on performance, you can't "drill down" > with > >>> > callbacks, it's not usable. > >>> > >>> The callback model can be converted into the polling model. The > >>> callback would just store the result on the query object, or in some > >>> sort of map. Then the tool can choose to display a subset of the > >>> results. > >>> > >>> The question of whether it would perform acceptably is the main issue. > >>> I am certainly concerned about this, but think we need to prototype it > >>> to measure. > >>> > >>> -Ken > >> > >> > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Apr 11 23:41:39 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 08:41:39 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: <462682229-1365730519-cardhu_decombobulator_blackberry.rim.net-340914248-@b18.c1.bise6.blackberry> References: <462682229-1365730519-cardhu_decombobulator_blackberry.rim.net-340914248-@b18.c1.bise6.blackberry> Message-ID: On Fri, Apr 12, 2013 at 3:35 AM, R?mi Arnaud wrote: > ** > What about an API like; > > var counters = new gl.asyncPerfCountersSet(); > > counters.getTime() > ... > counters.getTime() > ... > counters.close(callback) > // getTime() does not do anything once counters is closed > > //this is called once all results are available > callback=function(results) > { > ... Do something with all those values > > } > Unusable, queries all query timers created which is not desired. Also doesn't allow fine grained access to query just those timers from a frame you're interested in. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Apr 11 23:43:04 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 08:43:04 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Fri, Apr 12, 2013 at 2:04 AM, Gregg Tavares wrote: > Devs will abuse an API anyway they can. If setTimeout(checkQuerys, 0) gets > them a faster framerate they'll do it. > You cannot invent an idiot proof API. That's impossible. But you can cripple one that would work trying to do that. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Thu Apr 11 23:45:02 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 08:45:02 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Fri, Apr 12, 2013 at 4:29 AM, James Robinson wrote: > The more modern way to achieve this is with > http://dom.spec.whatwg.org/#futures. This still requires allocating an > object per query but makes a lot of the syntax around it nicer. > Oh please, can we not make the discussion insanely more complex by tying a simple extension to an entire new and unimplemented standard? -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rem...@ Fri Apr 12 08:32:12 2013 From: Rem...@ (Arnaud, Remi) Date: Fri, 12 Apr 2013 15:32:12 +0000 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: <462682229-1365730519-cardhu_decombobulator_blackberry.rim.net-340914248-@b18.c1.bise6.blackberry>, Message-ID: Unusable, queries all query timers created which is not desired. Also doesn't allow fine grained access to query just those timers from a frame you're interested in. The proposed API does not have those limitations, as the callback 'results' can be just a list of timers which have to be queried to get their values. Query the first and last to get the overall time, then query more timers if you want more results. At that point (in the callback) all the timers are available and ready. Each frame has his own new asyncCounters. In fact one single frame can have more than one set of queries and associated callback Regards -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 09:00:23 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 18:00:23 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: <462682229-1365730519-cardhu_decombobulator_blackberry.rim.net-340914248-@b18.c1.bise6.blackberry> Message-ID: On Fri, Apr 12, 2013 at 5:32 PM, Arnaud, Remi wrote: > The proposed API does not have those limitations, as the callback > 'results' can be just a list of timers which have to be queried to get > their values. > > Query the first and last to get the overall time, then query more timers > if you want more results. > > At that point (in the callback) all the timers are available and ready. > > Each frame has his own new asyncCounters. In fact one single frame can > have more than one set of queries and associated callback > The current API already does that, and the differing semantic presents no improvement. It presents a detriment however because now hierarchies of thousands of timers cannot be managed, hence it is unusable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 09:33:46 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 18:33:46 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: <171619926-1365783865-cardhu_decombobulator_blackberry.rim.net-921435882-@b18.c1.bise6.blackberry> References: <462682229-1365730519-cardhu_decombobulator_blackberry.rim.net-340914248-@b18.c1.bise6.blackberry> <171619926-1365783865-cardhu_decombobulator_blackberry.rim.net-921435882-@b18.c1.bise6.blackberry> Message-ID: On Fri, Apr 12, 2013 at 6:24 PM, R?mi Arnaud wrote: > ** > I guess I am confused to what is the 'current' API. As I recall, the > 'current' API had an issue with pooling queries before they are available - > Pooling queries isn't a problem. the one I proposed does not. > It does pool queries just the same, it's just taking control away from a user to individually address and group them in any meaningful datastructure that matters to users. > The proposed API does not put the burden of allocating each individual > timers to javascript > It's not a burden. > , but the 'current' API does. > It's not a problem. > Yet both API enable the use of 1000s of timers > The current API enables to individually address single queries, that a user holds, in data structures that matter to them, which is not a list. > The proposed API provide the user with the capability to group timers > together in sets, associated with their own callback. > There can be thousands of sets in hundreds of hierarchical levels. Verdict: stop inventing problems that don't exist and make the API even less usable. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 09:46:01 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 18:46:01 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: <462682229-1365730519-cardhu_decombobulator_blackberry.rim.net-340914248-@b18.c1.bise6.blackberry> <171619926-1365783865-cardhu_decombobulator_blackberry.rim.net-921435882-@b18.c1.bise6.blackberry> Message-ID: Just to restate a few things that everybody seems to forget and more funny ideas come out of the woodwork: 1. There is never a need to poll (or receive a callback) for more than one query per frame. 2. All queries of a frame are ready for obtaining their value when the last query of a frame is ready. 3. Obtaining the query value is expensive in its own right. 4. Queries are intentionally individual so that users can organize them in a fashion conductive to their application code. If the next funny idea about callbacks, futures, sets, lists and whatnot pops into your head and you feel compelled to come out of the woodwork with it. Read this list again. If somehow the idea invalidates any of these points, it's a bad idea. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rem...@ Fri Apr 12 10:41:24 2013 From: Rem...@ (Arnaud, Remi) Date: Fri, 12 Apr 2013 17:41:24 +0000 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: Message-ID: On Fri, Apr 12, 2013 at 6:24 PM, R?mi Arnaud > wrote: I guess I am confused to what is the 'current' API. As I recall, the 'current' API had an issue with pooling queries before they are available - Pooling queries isn't a problem. the one I proposed does not. It does pool queries just the same, it's just taking control away from a user to individually address and group them in any meaningful datastructure that matters to users. Not at all. The main difference is that the user cannot ask for a query before they are available. User can only access the 'results' from the parameter passed into the callback. I don't understand how the proposed API takes control away from the user to individually address a query, it actually provide a way to group queries. User can query any number of timers in the callback and save this in whatever data structure it want. The proposed API does not put the burden of allocating each individual timers to javascript It's not a burden. , but the 'current' API does. It's not a problem. Ok, still the proposed API avoid the need to user to do 1000s of allocation, 1000s of garbage collection. I thought this would be of interest in the concept of a real time (1000s times per frame) use. Yet both API enable the use of 1000s of timers The current API enables to individually address single queries, that a user holds, in data structures that matter to them, which is not a list. The proposed API does exactly the same, except that the queries are grouped and available as a (whatever you want to be) array, list?. They are individually addressed in the callback, the user can put the result it whatever data structure it want?. The proposed API provide the user with the capability to group timers together in sets, associated with their own callback. There can be thousands of sets in hundreds of hierarchical levels. Sure, there can be hundreds of sets. The proposed API enable grouping the queries in sets, provides callback (event) when a given set if available, avoid pooling issue as mentioned in this email thread Verdict: stop inventing problems that don't exist and make the API even less usable. Sorry, but I beg to differ. I see the proposed API more usable, faster, solving the reported issues, and working in all the use cases that were described. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 11:01:34 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 20:01:34 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Fri, Apr 12, 2013 at 7:41 PM, Arnaud, Remi wrote: > Not at all. The main difference is that the user cannot ask for a query > before they are available. > Users won't be asking for results before they're available because that's a stupid behavior. The whole spinloop of death debate is strawman. You can abuse any API. Stop inventing problems. Spinloop of death is 1) stupid 2) you won't do it because it'll kill your performance 3) the API doesn't encourage it either way 4) the documentation doesn't encourage. > User can only access the 'results' from the parameter passed into the > callback. > Which is useless because obtaining a query and sticking it somewhere gives it meaning to the application code. A flat list of gunk doesn't have any meaning anymore, therefore useless. > I don't understand how the proposed API takes control away from the user > to individually address a query, it actually provide a way to group > queries. User can query any number of timers in the callback and save this > in whatever data structure it want. > It takes control away because it hides the queries. > Ok, still the proposed API avoid the need to user to do 1000s of > allocation, 1000s of garbage collection. I thought this would be of > interest in the concept of a real time (1000s times per frame) use. > You have not read my examples. You also have not read Bens answer to my question on the reusability of queries. You won't need to allocate them every frame. Some people might want to use pools. Others might want to use their own data structures to put them in. Stop inventing a semantic that makes this impossible. The proposed API does exactly the same, except that the queries are grouped > and available as a (whatever you want to be) array, list?. They > are individually addressed in the callback, the user can put the result it > whatever data structure it want?. > It does not. You're just dumping a flat list on a user without any semantic meaning of where a query was used. That's useless. > Sure, there can be hundreds of sets. The proposed API enable grouping the > queries in sets, provides callback (event) when a given set if available, > avoid pooling issue as mentioned in this email thread > Sets are useless. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rem...@ Fri Apr 12 11:06:02 2013 From: Rem...@ (Arnaud, Remi) Date: Fri, 12 Apr 2013 18:06:02 +0000 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: Message-ID: The programmer knows exactly what queries calls where done in order, the 'results' provide the queries in the same order. There is no need to extra semantic -- Remi From: Florian B?sch > Date: Friday, April 12, 2013 11:01 AM To: R?mi Arnaud > Cc: R?mi Arnaud >, Ben Vanik >, "owner-public_webgl...@" >, Kenneth Russell >, Gregg Tavares >, Public Webgl >, Brian Cornell >, Glenn Maynard > Subject: Re: [Public WebGL] For review: ANGLE_timer_query extension On Fri, Apr 12, 2013 at 7:41 PM, Arnaud, Remi > wrote: Not at all. The main difference is that the user cannot ask for a query before they are available. Users won't be asking for results before they're available because that's a stupid behavior. The whole spinloop of death debate is strawman. You can abuse any API. Stop inventing problems. Spinloop of death is 1) stupid 2) you won't do it because it'll kill your performance 3) the API doesn't encourage it either way 4) the documentation doesn't encourage. User can only access the 'results' from the parameter passed into the callback. Which is useless because obtaining a query and sticking it somewhere gives it meaning to the application code. A flat list of gunk doesn't have any meaning anymore, therefore useless. I don't understand how the proposed API takes control away from the user to individually address a query, it actually provide a way to group queries. User can query any number of timers in the callback and save this in whatever data structure it want. It takes control away because it hides the queries. Ok, still the proposed API avoid the need to user to do 1000s of allocation, 1000s of garbage collection. I thought this would be of interest in the concept of a real time (1000s times per frame) use. You have not read my examples. You also have not read Bens answer to my question on the reusability of queries. You won't need to allocate them every frame. Some people might want to use pools. Others might want to use their own data structures to put them in. Stop inventing a semantic that makes this impossible. The proposed API does exactly the same, except that the queries are grouped and available as a (whatever you want to be) array, list?. They are individually addressed in the callback, the user can put the result it whatever data structure it want?. It does not. You're just dumping a flat list on a user without any semantic meaning of where a query was used. That's useless. Sure, there can be hundreds of sets. The proposed API enable grouping the queries in sets, provides callback (event) when a given set if available, avoid pooling issue as mentioned in this email thread Sets are useless. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 11:12:17 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 20:12:17 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Fri, Apr 12, 2013 at 8:06 PM, Arnaud, Remi wrote: > The programmer knows exactly what queries calls where done in order, the > 'results' provide the queries in the same order. There is no need to extra > semantic > That's utter nonesense. You didn't think this trough. A so inclined programmer might capture a call stack of his drawing. Where's your "known order" now? Nowhere. It's gone. It had structure before you mangled it into a flat list. A flat list is not the only usecase of queries. Stop dictating application structure to people wanting to use timer queries. Think trough what people might want to do with them before assuming "A list is what anybody will ever need". -------------- next part -------------- An HTML attachment was scrubbed... URL: From ndu...@ Fri Apr 12 12:09:19 2013 From: ndu...@ (Nat Duca) Date: Fri, 12 Apr 2013 12:09:19 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: Timer query is a bad match for tiled renderers, e.g. PowerVR. As food for thought: even if this becomes available, there will be a huge proportion of low-end/mobile GPUs that will likely never be able to leverage the data from this sort of API. Render-pass level timing is, as I understand it, more viable on tilers. ~shrug~ On Fri, Apr 12, 2013 at 11:12 AM, Florian B?sch wrote: > On Fri, Apr 12, 2013 at 8:06 PM, Arnaud, Remi wrote: > >> The programmer knows exactly what queries calls where done in order, >> the 'results' provide the queries in the same order. There is no need to >> extra semantic >> > That's utter nonesense. You didn't think this trough. A so inclined > programmer might capture a call stack of his drawing. Where's your "known > order" now? Nowhere. It's gone. It had structure before you mangled it into > a flat list. A flat list is not the only usecase of queries. Stop dictating > application structure to people wanting to use timer queries. Think trough > what people might want to do with them before assuming "A list is what > anybody will ever need". > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 12:15:06 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 21:15:06 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Fri, Apr 12, 2013 at 9:09 PM, Nat Duca wrote: > Render-pass level timing is, as I understand it, more viable on tilers. > Most the time is ultimately being spent in the flush, and in JS we can't time that because there's no API for it. I'd like an API that lets me measure how much time the GPU process actually spent on my frame for the context I have in hand. It'd be an improvement over the current state of affairs of simply measuring FPS which is capped at 60 and doesn't give you any clue before that. But timing queries, well, at least some ability to get a timing information for a piece of the rendering is a valuable piece of info. Are tilers just gonna ignore it, or is there a similar mechanism for tilers? I mean, essence each tile could run the queries and average the results by tile count. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 13:27:21 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 22:27:21 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: <454511728-1365797925-cardhu_decombobulator_blackberry.rim.net-940501625-@b18.c1.bise6.blackberry> References: <462682229-1365730519-cardhu_decombobulator_blackberry.rim.net-340914248-@b18.c1.bise6.blackberry> <171619926-1365783865-cardhu_decombobulator_blackberry.rim.net-921435882-@b18.c1.bise6.blackberry> <454511728-1365797925-cardhu_decombobulator_blackberry.rim.net-940501625-@b18.c1.bise6.blackberry> Message-ID: On Fri, Apr 12, 2013 at 10:18 PM, R?mi Arnaud wrote: > ** > I don't belive this to be true. > A timer is a resource allocated in the driver. There are multiple queues involved until a command hits the driver. Such as JS process -> GPU process -> driver process. The queue we're measuring with query objects is the execution queue in the driver. This queue runs down on flip. The queue is processed one command at a time, such as drawArrays, useShader etc. Some commands force a queue synchronization such as texImage2D, bufferData, readPixels and finish. So while the driver is processing the queue it encounters the query timer commands. When it hits one, it stores the value in the query object it has allocated. Since by definition the queue for a frame is empty by the time flip returns, any timer query that mattered to that frame has now been filled with a timing value and its flag of "readyness" been set. Therefore all preceeding timer queries have the flag set as well, and are equally filled with a value. Hence the last query in a frame is the only query that needs to be polled to know if all preceeding queries of a frame are ready and filled with timing values. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 13:42:23 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 22:42:23 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: <462682229-1365730519-cardhu_decombobulator_blackberry.rim.net-340914248-@b18.c1.bise6.blackberry> <171619926-1365783865-cardhu_decombobulator_blackberry.rim.net-921435882-@b18.c1.bise6.blackberry> <454511728-1365797925-cardhu_decombobulator_blackberry.rim.net-940501625-@b18.c1.bise6.blackberry> Message-ID: http://www.opengl.org/registry/specs/ARB/timer_query.txt When BeginQuery and EndQuery are called with a of > TIME_ELAPSED, the GL prepares to start and stop the timer used for > timer queries. The timer is started or stopped when the effects from all > previous commands on the GL client and server state and the framebuffer > have been fully realized. It follows that all previous timing events have to be realized before the last one gets ready status. On Fri, Apr 12, 2013 at 10:27 PM, Florian B?sch wrote: > On Fri, Apr 12, 2013 at 10:18 PM, R?mi Arnaud wrote: > >> ** >> I don't belive this to be true. >> > > A timer is a resource allocated in the driver. There are multiple queues > involved until a command hits the driver. Such as JS process -> GPU process > -> driver process. The queue we're measuring with query objects is the > execution queue in the driver. This queue runs down on flip. The queue is > processed one command at a time, such as drawArrays, useShader etc. Some > commands force a queue synchronization such as texImage2D, bufferData, > readPixels and finish. > > So while the driver is processing the queue it encounters the query timer > commands. When it hits one, it stores the value in the query object it has > allocated. Since by definition the queue for a frame is empty by the time > flip returns, any timer query that mattered to that frame has now been > filled with a timing value and its flag of "readyness" been set. Therefore > all preceeding timer queries have the flag set as well, and are equally > filled with a value. > > Hence the last query in a frame is the only query that needs to be polled > to know if all preceeding queries of a frame are ready and filled with > timing values. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 13:54:16 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 22:54:16 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: <1310740539-1365799350-cardhu_decombobulator_blackberry.rim.net-758544132-@b18.c1.bise6.blackberry> References: <462682229-1365730519-cardhu_decombobulator_blackberry.rim.net-340914248-@b18.c1.bise6.blackberry> <171619926-1365783865-cardhu_decombobulator_blackberry.rim.net-921435882-@b18.c1.bise6.blackberry> <454511728-1365797925-cardhu_decombobulator_blackberry.rim.net-940501625-@b18.c1.bise6.blackberry> <1310740539-1365799350-cardhu_decombobulator_blackberry.rim.net-758544132-@b18.c1.bise6.blackberry> Message-ID: On Fri, Apr 12, 2013 at 10:42 PM, R?mi Arnaud wrote: > ** > This said I see no reason why someone could not decide to read first a > query result that was in the middle of the frame, and then one at the end > of the frame. For example in a multipass algorithm > It's a bad idea to do it, and I don't know either why Greg and others make such a fuss about it, it's not like people would write deadspinners for that. So obviously you can't get the timing results for the remainder of the frame from the last synchronizing command (such as gl.finish). But I don't see a reason why anybody shouldn't be able to use the queries * before* the last synchronizing command (and without polling). For example: 1. lots of timers 2. gl.finish() 3. now work with all preceding queries Because by the time gl.finish() returns it is guaranteed that all preceding timer queries are ready and filled. Regardless of this fussy non-problem, you shouldn't do that for a couple reasons: 1) You need to call gl.finish() which synchronizes and slows everything down. 2) A single frame measurement as a deciding factor for a following rendering logic is just gonna make the code flap in the wind since execution times contain a fair deal of variance. But if you really really want to do that, I don't think we should dictate that people can't. -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Fri Apr 12 14:04:38 2013 From: gma...@ (Gregg Tavares) Date: Fri, 12 Apr 2013 14:04:38 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: <462682229-1365730519-cardhu_decombobulator_blackberry.rim.net-340914248-@b18.c1.bise6.blackberry> <171619926-1365783865-cardhu_decombobulator_blackberry.rim.net-921435882-@b18.c1.bise6.blackberry> <454511728-1365797925-cardhu_decombobulator_blackberry.rim.net-940501625-@b18.c1.bise6.blackberry> <1310740539-1365799350-cardhu_decombobulator_blackberry.rim.net-758544132-@b18.c1.bise6.blackberry> Message-ID: People won't write spinners for timing. The will write spinners for occlusion queries. Since it's the same API, the only difference is the enums passed in, it's important we don't expose the wrong API now and be stuck with an unsupportable or massively abused API in the future. On Fri, Apr 12, 2013 at 1:54 PM, Florian B?sch wrote: > On Fri, Apr 12, 2013 at 10:42 PM, R?mi Arnaud wrote: > >> ** >> This said I see no reason why someone could not decide to read first a >> query result that was in the middle of the frame, and then one at the end >> of the frame. For example in a multipass algorithm >> > It's a bad idea to do it, and I don't know either why Greg and others make > such a fuss about it, it's not like people would write deadspinners for > that. > > So obviously you can't get the timing results for the remainder of the > frame from the last synchronizing command (such as gl.finish). > > But I don't see a reason why anybody shouldn't be able to use the queries > *before* the last synchronizing command (and without polling). For > example: > > > 1. lots of timers > 2. gl.finish() > 3. now work with all preceding queries > > Because by the time gl.finish() returns it is guaranteed that all > preceding timer queries are ready and filled. > > Regardless of this fussy non-problem, you shouldn't do that for a couple > reasons: > > 1) You need to call gl.finish() which synchronizes and slows everything > down. > 2) A single frame measurement as a deciding factor for a following > rendering logic is just gonna make the code flap in the wind since > execution times contain a fair deal of variance. > > But if you really really want to do that, I don't think we should dictate > that people can't. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 14:08:24 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 23:08:24 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: <462682229-1365730519-cardhu_decombobulator_blackberry.rim.net-340914248-@b18.c1.bise6.blackberry> <171619926-1365783865-cardhu_decombobulator_blackberry.rim.net-921435882-@b18.c1.bise6.blackberry> <454511728-1365797925-cardhu_decombobulator_blackberry.rim.net-940501625-@b18.c1.bise6.blackberry> <1310740539-1365799350-cardhu_decombobulator_blackberry.rim.net-758544132-@b18.c1.bise6.blackberry> Message-ID: Why would you write a spinner when the behavior is well defined by gl.finish() that implies all previous server and client state has cleared the queue and your query is now ready to be read? On Fri, Apr 12, 2013 at 11:04 PM, Gregg Tavares wrote: > People won't write spinners for timing. The will write spinners for > occlusion queries. > > Since it's the same API, the only difference is the enums passed in, it's > important we don't expose the wrong API now and be stuck with an > unsupportable or massively abused API in the future. > > > > > On Fri, Apr 12, 2013 at 1:54 PM, Florian B?sch wrote: > >> On Fri, Apr 12, 2013 at 10:42 PM, R?mi Arnaud wrote: >> >>> ** >>> This said I see no reason why someone could not decide to read first a >>> query result that was in the middle of the frame, and then one at the end >>> of the frame. For example in a multipass algorithm >>> >> It's a bad idea to do it, and I don't know either why Greg and others >> make such a fuss about it, it's not like people would write deadspinners >> for that. >> >> So obviously you can't get the timing results for the remainder of the >> frame from the last synchronizing command (such as gl.finish). >> >> But I don't see a reason why anybody shouldn't be able to use the queries >> *before* the last synchronizing command (and without polling). For >> example: >> >> >> 1. lots of timers >> 2. gl.finish() >> 3. now work with all preceding queries >> >> Because by the time gl.finish() returns it is guaranteed that all >> preceding timer queries are ready and filled. >> >> Regardless of this fussy non-problem, you shouldn't do that for a couple >> reasons: >> >> 1) You need to call gl.finish() which synchronizes and slows everything >> down. >> 2) A single frame measurement as a deciding factor for a following >> rendering logic is just gonna make the code flap in the wind since >> execution times contain a fair deal of variance. >> >> But if you really really want to do that, I don't think we should dictate >> that people can't. >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 14:14:00 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 23:14:00 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: <462682229-1365730519-cardhu_decombobulator_blackberry.rim.net-340914248-@b18.c1.bise6.blackberry> <171619926-1365783865-cardhu_decombobulator_blackberry.rim.net-921435882-@b18.c1.bise6.blackberry> <454511728-1365797925-cardhu_decombobulator_blackberry.rim.net-940501625-@b18.c1.bise6.blackberry> <1310740539-1365799350-cardhu_decombobulator_blackberry.rim.net-758544132-@b18.c1.bise6.blackberry> Message-ID: How about this, when somebody starts polling a query you start a counter. By the Nth poll you throw an exception stating "spinners are usless you twit use gl.finish()" or something? On Fri, Apr 12, 2013 at 11:08 PM, Florian B?sch wrote: > Why would you write a spinner when the behavior is well defined by > gl.finish() that implies all previous server and client state has cleared > the queue and your query is now ready to be read? > > > On Fri, Apr 12, 2013 at 11:04 PM, Gregg Tavares wrote: > >> People won't write spinners for timing. The will write spinners for >> occlusion queries. >> >> Since it's the same API, the only difference is the enums passed in, it's >> important we don't expose the wrong API now and be stuck with an >> unsupportable or massively abused API in the future. >> >> >> >> >> On Fri, Apr 12, 2013 at 1:54 PM, Florian B?sch wrote: >> >>> On Fri, Apr 12, 2013 at 10:42 PM, R?mi Arnaud wrote: >>> >>>> ** >>>> This said I see no reason why someone could not decide to read first a >>>> query result that was in the middle of the frame, and then one at the end >>>> of the frame. For example in a multipass algorithm >>>> >>> It's a bad idea to do it, and I don't know either why Greg and others >>> make such a fuss about it, it's not like people would write deadspinners >>> for that. >>> >>> So obviously you can't get the timing results for the remainder of the >>> frame from the last synchronizing command (such as gl.finish). >>> >>> But I don't see a reason why anybody shouldn't be able to use the >>> queries *before* the last synchronizing command (and without polling). >>> For example: >>> >>> >>> 1. lots of timers >>> 2. gl.finish() >>> 3. now work with all preceding queries >>> >>> Because by the time gl.finish() returns it is guaranteed that all >>> preceding timer queries are ready and filled. >>> >>> Regardless of this fussy non-problem, you shouldn't do that for a couple >>> reasons: >>> >>> 1) You need to call gl.finish() which synchronizes and slows everything >>> down. >>> 2) A single frame measurement as a deciding factor for a following >>> rendering logic is just gonna make the code flap in the wind since >>> execution times contain a fair deal of variance. >>> >>> But if you really really want to do that, I don't think we should >>> dictate that people can't. >>> >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 14:18:54 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 23:18:54 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: <1610102661-1365801227-cardhu_decombobulator_blackberry.rim.net-1273806451-@b18.c1.bise6.blackberry> References: <462682229-1365730519-cardhu_decombobulator_blackberry.rim.net-340914248-@b18.c1.bise6.blackberry> <171619926-1365783865-cardhu_decombobulator_blackberry.rim.net-921435882-@b18.c1.bise6.blackberry> <454511728-1365797925-cardhu_decombobulator_blackberry.rim.net-940501625-@b18.c1.bise6.blackberry> <1310740539-1365799350-cardhu_decombobulator_blackberry.rim.net-758544132-@b18.c1.bise6.blackberry> <1610102661-1365801227-cardhu_decombobulator_blackberry.rim.net-1273806451-@b18.c1.bise6.blackberry> Message-ID: JS can't call back inbetween executing JS or interrupt JS execution. The result would be an undefined interpreter state. A callback can only happen either immediately, or after all JS has finished running. On Fri, Apr 12, 2013 at 11:13 PM, R?mi Arnaud wrote: > ** > I'm lost. > I don't see any connection between the question and the answer. > > All was asked is the ability to get result from a query in the middle of a > frame, without habing to wait for the last query to be available. Therfore, > in the 'current' API, first poling a query and in the same frame later, > poling a another timer. > With the proposed API, creating 2 sets of queries, and having 2 callbacks. > > So just to restate here's some pseudo code > > querytimer() > .. gl calls > querytimer(A) > .. gl calls > + Callback/polling for timer(A) and prev > .. Potentially do something about timerA in this same frame > querytimer(B) > ...gl calls > querytimer(C) > ... > glfinish() > + callback/polling from last timer > > > The example above show that more than one poll per frame can be useful, in > particular if any reaction to the result is expected to happen in the same > frame > > > Regards > - Remi > ------------------------------ > *From: * Florian B?sch > *Date: *Fri, 12 Apr 2013 22:54:16 +0200 > *To: *R??mi Arnaud > *Cc: *R??mi Arnaud; Ben Vanik; > owner-public_webgl...@; Kenneth > Russell; Gregg Tavares; Public Webgl< > public_webgl...@>; Brian Cornell; Glenn > Maynard > *Subject: *Re: [Public WebGL] For review: ANGLE_timer_query extension > > On Fri, Apr 12, 2013 at 10:42 PM, R?mi Arnaud wrote: > >> ** >> This said I see no reason why someone could not decide to read first a >> query result that was in the middle of the frame, and then one at the end >> of the frame. For example in a multipass algorithm >> > It's a bad idea to do it, and I don't know either why Greg and others make > such a fuss about it, it's not like people would write deadspinners for > that. > > So obviously you can't get the timing results for the remainder of the > frame from the last synchronizing command (such as gl.finish). > > But I don't see a reason why anybody shouldn't be able to use the queries > *before* the last synchronizing command (and without polling). For > example: > > > 1. lots of timers > 2. gl.finish() > 3. now work with all preceding queries > > Because by the time gl.finish() returns it is guaranteed that all > preceding timer queries are ready and filled. > > Regardless of this fussy non-problem, you shouldn't do that for a couple > reasons: > > 1) You need to call gl.finish() which synchronizes and slows everything > down. > 2) A single frame measurement as a deciding factor for a following > rendering logic is just gonna make the code flap in the wind since > execution times contain a fair deal of variance. > > But if you really really want to do that, I don't think we should dictate > that people can't. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rem...@ Fri Apr 12 14:33:15 2013 From: Rem...@ (Arnaud, Remi) Date: Fri, 12 Apr 2013 21:33:15 +0000 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: Message-ID: Rater than using a bunch of superlatives such as 'utter nonsense' and 'useless', could you please explain better the use case? What has capturing a call stack has anything to do with performance timers? Why is allowing the programmer to group a set of queries into one array of results through a callback any limitation? But I guess the main issue is that there is no consensus of what are the issues to be solved for this API to be useful. So until this is resolved, there is no point having a discussion about API design. Regards -- Remi From: Florian B?sch > Date: Friday, April 12, 2013 11:12 AM To: R?mi Arnaud > Cc: R?mi Arnaud >, Ben Vanik >, "owner-public_webgl...@" >, Kenneth Russell >, Gregg Tavares >, Public Webgl >, Brian Cornell >, Glenn Maynard > Subject: Re: [Public WebGL] For review: ANGLE_timer_query extension On Fri, Apr 12, 2013 at 8:06 PM, Arnaud, Remi > wrote: The programmer knows exactly what queries calls where done in order, the 'results' provide the queries in the same order. There is no need to extra semantic That's utter nonesense. You didn't think this trough. A so inclined programmer might capture a call stack of his drawing. Where's your "known order" now? Nowhere. It's gone. It had structure before you mangled it into a flat list. A flat list is not the only usecase of queries. Stop dictating application structure to people wanting to use timer queries. Think trough what people might want to do with them before assuming "A list is what anybody will ever need". -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rem...@ Fri Apr 12 14:42:35 2013 From: Rem...@ (Arnaud, Remi) Date: Fri, 12 Apr 2013 21:42:35 +0000 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: Message-ID: I can imagine many ways of solving this issue. For example, the call to counters.close() could check if a previous set of timers is available and call the callbacks. Or the application has to call settimeout (f,0) and split its rendering into several chunks. Which I think could work just fine in the case of multi pass rendering. This said it seems to me we reached the main issue for this API design. As I understand , you want to limit usage to let the user access the query values of a frame ONLY in the next frame. In that case there is probably a simpler API design available given this restriction. Regards -- Remi From: Florian B?sch > Date: Friday, April 12, 2013 2:18 PM To: R?mi Arnaud > Cc: R?mi Arnaud >, Ben Vanik >, "owner-public_webgl...@" >, Kenneth Russell >, Gregg Tavares >, Public Webgl >, Brian Cornell >, Glenn Maynard > Subject: Re: [Public WebGL] For review: ANGLE_timer_query extension JS can't call back inbetween executing JS or interrupt JS execution. The result would be an undefined interpreter state. A callback can only happen either immediately, or after all JS has finished running. On Fri, Apr 12, 2013 at 11:13 PM, R?mi Arnaud > wrote: I'm lost. I don't see any connection between the question and the answer. All was asked is the ability to get result from a query in the middle of a frame, without habing to wait for the last query to be available. Therfore, in the 'current' API, first poling a query and in the same frame later, poling a another timer. With the proposed API, creating 2 sets of queries, and having 2 callbacks. So just to restate here's some pseudo code querytimer() .. gl calls querytimer(A) .. gl calls + Callback/polling for timer(A) and prev .. Potentially do something about timerA in this same frame querytimer(B) ...gl calls querytimer(C) ... glfinish() + callback/polling from last timer The example above show that more than one poll per frame can be useful, in particular if any reaction to the result is expected to happen in the same frame Regards - Remi ________________________________ From: Florian B?sch > Date: Fri, 12 Apr 2013 22:54:16 +0200 To: R??mi Arnaud> Cc: R??mi Arnaud>; Ben Vanik>; owner-public_webgl...@>; Kenneth Russell>; Gregg Tavares>; Public Webgl>; Brian Cornell>; Glenn Maynard> Subject: Re: [Public WebGL] For review: ANGLE_timer_query extension On Fri, Apr 12, 2013 at 10:42 PM, R?mi Arnaud > wrote: This said I see no reason why someone could not decide to read first a query result that was in the middle of the frame, and then one at the end of the frame. For example in a multipass algorithm It's a bad idea to do it, and I don't know either why Greg and others make such a fuss about it, it's not like people would write deadspinners for that. So obviously you can't get the timing results for the remainder of the frame from the last synchronizing command (such as gl.finish). But I don't see a reason why anybody shouldn't be able to use the queries before the last synchronizing command (and without polling). For example: 1. lots of timers 2. gl.finish() 3. now work with all preceding queries Because by the time gl.finish() returns it is guaranteed that all preceding timer queries are ready and filled. Regardless of this fussy non-problem, you shouldn't do that for a couple reasons: 1) You need to call gl.finish() which synchronizes and slows everything down. 2) A single frame measurement as a deciding factor for a following rendering logic is just gonna make the code flap in the wind since execution times contain a fair deal of variance. But if you really really want to do that, I don't think we should dictate that people can't. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 14:45:32 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 23:45:32 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: Timer queries measure the time it takes the GPU to run a set of commands. It does this by setting a server state. Since the list of commands issued stands in relation to what the application did to generate them, the timers stand in relation to the application code. The simplest usecase is simply measuring the entire execution time. This requires one query per frame. You will probably not need more than 2-3 queries in total since it's exceedingly unlikely that a query 2 frames back would not have been filled trough 2 flips. But that might depend on how the browser handles buffering and flips. The next more interesting usecase is a list of checkpoints. That is useful for coarse measurement of the stages of what your application goes trough. Though even so, you would mark each "stage" in some way you can read it out back later easely, for instance stick it into a list as in foo[x].query = thequery; foo[x].name = 'somecheckpoint'. So that you can display the list of checkpoints in a UI or somesuch. The next more interesting usecase would be to capture the call stack of checkpoints. For instance let a stacklevel be defined as a begin/end. Then let the methods be defined as: var someMethod = function(){ stackBegin(query, 'Somename'); stackEnd(); } Quite like the console performance measurement API really. So what you can later do is display a realtime UI of the frame stack which you can expand and collapse and show the timings as the application runs. Which would provide you with a lot of insight over the performance characteristic of your rendering, also it'd be cool. On Fri, Apr 12, 2013 at 11:33 PM, Arnaud, Remi wrote: > Rater than using a bunch of superlatives such as 'utter nonsense' and > 'useless', could you please explain better the use case? > > What has capturing a call stack has anything to do with performance > timers? Why is allowing the programmer to group a set of queries into one > array of results through a callback any limitation? > > But I guess the main issue is that there is no consensus of what are the > issues to be solved for this API to be useful. So until this is resolved, > there is no point having a discussion about API design. > > Regards > -- Remi > > From: Florian B?sch > Date: Friday, April 12, 2013 11:12 AM > To: R?mi Arnaud > Cc: R?mi Arnaud , Ben Vanik , " > owner-public_webgl...@" , Kenneth > Russell , Gregg Tavares , Public Webgl < > public_webgl...@>, Brian Cornell , Glenn > Maynard > > Subject: Re: [Public WebGL] For review: ANGLE_timer_query extension > > On Fri, Apr 12, 2013 at 8:06 PM, Arnaud, Remi wrote: > >> The programmer knows exactly what queries calls where done in order, >> the 'results' provide the queries in the same order. There is no need to >> extra semantic >> > That's utter nonesense. You didn't think this trough. A so inclined > programmer might capture a call stack of his drawing. Where's your "known > order" now? Nowhere. It's gone. It had structure before you mangled it into > a flat list. A flat list is not the only usecase of queries. Stop dictating > application structure to people wanting to use timer queries. Think trough > what people might want to do with them before assuming "A list is what > anybody will ever need". > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 14:49:54 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 12 Apr 2013 23:49:54 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: On Fri, Apr 12, 2013 at 11:42 PM, Arnaud, Remi wrote: > As I understand , you want to limit usage to let the user access the > query values of a frame ONLY in the next frame. > I think that would be a bad idea. But what Greg wants to achieve with this is to prevent people from writing spinners, which are likely to become deadspinners since queue synchronization would only happen at flip, which can't happen unless JS ends, which means JS hangs. Or it just gets sluggish until the driver queue has cought up. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rem...@ Fri Apr 12 14:55:12 2013 From: Rem...@ (Arnaud, Remi) Date: Fri, 12 Apr 2013 21:55:12 +0000 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: Message-ID: Thanks for those use cases. The proposed API is no different than the 'existing' API, except that it groups several queries into a set, wait for the last query of the set to be available before using a callback. Getting the values from a query is not different than before. So once could do the following: ? Querytimer() timerData[nbqueries++].name = "some data" ? // Then in the callback for (var i=0; i> Date: Friday, April 12, 2013 2:45 PM To: R?mi Arnaud > Cc: R?mi Arnaud >, Ben Vanik >, "owner-public_webgl...@" >, Kenneth Russell >, Gregg Tavares >, Public Webgl >, Brian Cornell >, Glenn Maynard > Subject: Re: [Public WebGL] For review: ANGLE_timer_query extension Timer queries measure the time it takes the GPU to run a set of commands. It does this by setting a server state. Since the list of commands issued stands in relation to what the application did to generate them, the timers stand in relation to the application code. The simplest usecase is simply measuring the entire execution time. This requires one query per frame. You will probably not need more than 2-3 queries in total since it's exceedingly unlikely that a query 2 frames back would not have been filled trough 2 flips. But that might depend on how the browser handles buffering and flips. The next more interesting usecase is a list of checkpoints. That is useful for coarse measurement of the stages of what your application goes trough. Though even so, you would mark each "stage" in some way you can read it out back later easely, for instance stick it into a list as in foo[x].query = thequery; foo[x].name = 'somecheckpoint'. So that you can display the list of checkpoints in a UI or somesuch. The next more interesting usecase would be to capture the call stack of checkpoints. For instance let a stacklevel be defined as a begin/end. Then let the methods be defined as: var someMethod = function(){ stackBegin(query, 'Somename'); stackEnd(); } Quite like the console performance measurement API really. So what you can later do is display a realtime UI of the frame stack which you can expand and collapse and show the timings as the application runs. Which would provide you with a lot of insight over the performance characteristic of your rendering, also it'd be cool. On Fri, Apr 12, 2013 at 11:33 PM, Arnaud, Remi > wrote: Rater than using a bunch of superlatives such as 'utter nonsense' and 'useless', could you please explain better the use case? What has capturing a call stack has anything to do with performance timers? Why is allowing the programmer to group a set of queries into one array of results through a callback any limitation? But I guess the main issue is that there is no consensus of what are the issues to be solved for this API to be useful. So until this is resolved, there is no point having a discussion about API design. Regards -- Remi From: Florian B?sch > Date: Friday, April 12, 2013 11:12 AM To: R?mi Arnaud > Cc: R?mi Arnaud >, Ben Vanik >, "owner-public_webgl...@" >, Kenneth Russell >, Gregg Tavares >, Public Webgl >, Brian Cornell >, Glenn Maynard > Subject: Re: [Public WebGL] For review: ANGLE_timer_query extension On Fri, Apr 12, 2013 at 8:06 PM, Arnaud, Remi > wrote: The programmer knows exactly what queries calls where done in order, the 'results' provide the queries in the same order. There is no need to extra semantic That's utter nonesense. You didn't think this trough. A so inclined programmer might capture a call stack of his drawing. Where's your "known order" now? Nowhere. It's gone. It had structure before you mangled it into a flat list. A flat list is not the only usecase of queries. Stop dictating application structure to people wanting to use timer queries. Think trough what people might want to do with them before assuming "A list is what anybody will ever need". -------------- next part -------------- An HTML attachment was scrubbed... URL: From Rem...@ Fri Apr 12 14:56:37 2013 From: Rem...@ (Arnaud, Remi) Date: Fri, 12 Apr 2013 21:56:37 +0000 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: Message-ID: IMHO, the API I proposed prevents 'spinners', allow more than one query to be 'polled' in a single frame (not waiting for glFinish()) This should make both of you happy? -- Remi From: Florian B?sch > Date: Friday, April 12, 2013 2:49 PM To: R?mi Arnaud > Cc: R?mi Arnaud >, Ben Vanik >, "owner-public_webgl...@" >, Kenneth Russell >, Gregg Tavares >, Public Webgl >, Brian Cornell >, Glenn Maynard > Subject: Re: [Public WebGL] For review: ANGLE_timer_query extension On Fri, Apr 12, 2013 at 11:42 PM, Arnaud, Remi > wrote: As I understand , you want to limit usage to let the user access the query values of a frame ONLY in the next frame. I think that would be a bad idea. But what Greg wants to achieve with this is to prevent people from writing spinners, which are likely to become deadspinners since queue synchronization would only happen at flip, which can't happen unless JS ends, which means JS hangs. Or it just gets sluggish until the driver queue has cought up. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 15:04:24 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sat, 13 Apr 2013 00:04:24 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: Message-ID: No. This stupid, and I won't condone it. You're just hiding a handle, that could conveniently be used, behind an obsucre and unnessesary mechanism forcing everybody to write glue code for nothing. Just so you can have a cumbersome and standards incompatible API no OpenGL programmer who's read the ARB spec understands. No, just no. I won't have it. It's stupid. FFS. just drop it. On Fri, Apr 12, 2013 at 11:56 PM, Arnaud, Remi wrote: > IMHO, the API I proposed prevents 'spinners', allow more than one query > to be 'polled' in a single frame (not waiting for glFinish()) > > This should make both of you happy? > > -- Remi > > From: Florian B?sch > Date: Friday, April 12, 2013 2:49 PM > > To: R?mi Arnaud > Cc: R?mi Arnaud , Ben Vanik , " > owner-public_webgl...@" , Kenneth > Russell , Gregg Tavares , Public Webgl < > public_webgl...@>, Brian Cornell , Glenn > Maynard > Subject: Re: [Public WebGL] For review: ANGLE_timer_query extension > > On Fri, Apr 12, 2013 at 11:42 PM, Arnaud, Remi wrote: > >> As I understand , you want to limit usage to let the user access the >> query values of a frame ONLY in the next frame. >> > I think that would be a bad idea. But what Greg wants to achieve with this > is to prevent people from writing spinners, which are likely to become > deadspinners since queue synchronization would only happen at flip, which > can't happen unless JS ends, which means JS hangs. Or it just gets sluggish > until the driver queue has cought up. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 12 16:59:02 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sat, 13 Apr 2013 01:59:02 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: <63782233-1365810374-cardhu_decombobulator_blackberry.rim.net-140549388-@b18.c1.bise6.blackberry> References: <63782233-1365810374-cardhu_decombobulator_blackberry.rim.net-140549388-@b18.c1.bise6.blackberry> Message-ID: On Sat, Apr 13, 2013 at 1:46 AM, R?mi Arnaud wrote: > ** > The handles are not hidden at all. They are not just available > independently, but in a bloc. > Which serves no purpose whatsoever other than introducing an indirection for indirections sake. That's why it's stupid. And you don't need to provide a query pool class because users can and will write that themselves if they want to. You're not solving anything with that. > Anyways, I would recommend you stop using this tone - not many people > would be able to even dialog with someone like you - calling thing stupid > because they introduce a change is how things are done is ... stupid? > I told you to drop it. I've stated and restated why it's a stupid idea. But you won't let it go. I don't have to talk about the stupid idea, and I certainly don't have to condone it. So if that's your favorite idea, by all means, without me. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sat Apr 13 03:57:04 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sat, 13 Apr 2013 12:57:04 +0200 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: <63782233-1365810374-cardhu_decombobulator_blackberry.rim.net-140549388-@b18.c1.bise6.blackberry> Message-ID: My stupid idea was that I mentioned alternative API approaches like callbacks at the beginning of this thread. I did that before really thinking trough Bens usecase. I've meanwhile thought about Bens usecase a lot, and I realized that the API proposed is pretty perfect and that I've proposed as fodder for discussion a lot of stupid things. The elegance of Bens proposal is that the API is fine grained, convenient to wrap and doesn't impose a particular way to handle timer queries onto a users application code. I don't think that spinloops in themselves are an issue. We already have a working spinloop, it's called gl.finish. Spinlooping without a synchronization command is an issue, because that can mutate to a deadspinloop. But this is relatively easy to safeguard against and throw an exception, which I'd consider a reasonable approach to migitate the issue and educate users on how not to use the API, without changing the API flavor. I need this extension. Ben needs this extension. There are other people that need it. Other than safeguarding against erregious spinlooping it's pretty much perfect as is. Yes, it's not a javascript-y API, but making it more javascript-y doesn't improve the API. It just adds more overhead you have to take care of. Like hiding a handle, why's an integer a better handle than a handle? If you want to make it more javascript-y you can wrap your own utility code around it, which is what most users of the API would do anyway, because using it naked is nearly never really useful. Yes it's not a simple API, but it's also not a simple problem. Can we stop bikeshedding on the API flavors and accept the API that ben proposed, with the provision that there is a solution to throw people out of spinlooping with a simple query counter reset since state change? -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Apr 16 10:13:17 2013 From: gma...@ (Gregg Tavares) Date: Tue, 16 Apr 2013 10:13:17 -0700 Subject: [Public WebGL] Manual WebGL Conformance Tests Message-ID: There are currently 4 manual WebGL Conformance Tests not included in the auto run tests https://www.khronos.org/registry/webgl/sdk/tests/conformance/manual/ 3 of them are in the 1.0.2 snapshot They're manually run because they they are verifying compositing behavior and/or fullscreen behavior. Should these be required to pass for conformance? Thoughts? One idea to make this easier would be to add an option to auto-run these tests where the browser vendor could run there browser in a mode that allows these things to be checked. On other words, something like https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html?manual_tests=true We could add some stubs so the browser vendor could provide functions to make this automate-able like takeScreenshot() and goFullscreen() -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Tue Apr 16 10:16:24 2013 From: gma...@ (Gregg Tavares) Date: Tue, 16 Apr 2013 10:16:24 -0700 Subject: [Public WebGL] For review: ANGLE_timer_query extension In-Reply-To: References: <63782233-1365810374-cardhu_decombobulator_blackberry.rim.net-140549388-@b18.c1.bise6.blackberry> Message-ID: On Sat, Apr 13, 2013 at 3:57 AM, Florian B?sch wrote: > My stupid idea was that I mentioned alternative API approaches like > callbacks at the beginning of this thread. I did that before really > thinking trough Bens usecase. I've meanwhile thought about Bens usecase a > lot, and I realized that the API proposed is pretty perfect and that I've > proposed as fodder for discussion a lot of stupid things. The elegance of > Bens proposal is that the API is fine grained, convenient to wrap and > doesn't impose a particular way to handle timer queries onto a users > application code. > > I don't think that spinloops in themselves are an issue. We already have a > working spinloop, it's called gl.finish. > Spinlooping without a synchronization command is an issue, because that can > mutate to a deadspinloop. But this is relatively easy to safeguard against > and throw an exception, which I'd consider a reasonable approach to > migitate the issue and educate users on how not to use the API, without > changing the API flavor. > The issue is designing an API that doesn't encourage using it wrong where wrong = breaks randomly. If left as is I believe it will be common to see code like this function render() { foreach query from last frame { gl.getQueryParameter(gl.QUERY_RESULT_AVAILABLE); // don't check the result since we drew last frame var notOccluded = gl.getQueryParameter(gl.SAMPLES_PASSED); ... } for each model { beingQuery draw endQuery } } This code will appear to work on many systems but will break anytime the GPU takes a little too long. Examples of taking too long switching tabs launching another tab with WebGL launching another app switching apps running on a different GPU That will be a hard bug to find. How will you know you have it? Launch some other tabs and pray it slows down your GPU enough that if you made this mistake you'll find it? One of WebGL's explicit goals has been to adjust the api where necessary to avoid these kinds of issues. Shipping an API that is easy to get wrong in subtle ways that will be hard to know you got wrong seems like a bad idea. > > I need this extension. Ben needs this extension. There are other people > that need it. Other than safeguarding against erregious spinlooping it's > pretty much perfect as is. Yes, it's not a javascript-y API, but making it > more javascript-y doesn't improve the API. It just adds more overhead you > have to take care of. Like hiding a handle, why's an integer a better > handle than a handle? If you want to make it more javascript-y you can wrap > your own utility code around it, which is what most users of the API would > do anyway, because using it naked is nearly never really useful. Yes it's > not a simple API, but it's also not a simple problem. > > Can we stop bikeshedding on the API flavors and accept the API that ben > proposed, with the provision that there is a solution to throw people out > of spinlooping with a simple query counter reset since state change? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Tue Apr 16 10:38:04 2013 From: bja...@ (Benoit Jacob) Date: Tue, 16 Apr 2013 13:38:04 -0400 Subject: [Public WebGL] Manual WebGL Conformance Tests In-Reply-To: References: Message-ID: <516D8C7C.9060804@mozilla.com> The issue of cross-browser compositor testing is really an impotant and useful problem to solve. But I don't believe that manual testing is the right solution. Instead, there should be a cross-browser Web API to access the compositor rendering. It would have to be accessible only to privileged code for obvious reasons. Such tests are called Reftests on the Mozilla side; I thought that there had been talk about making them cross-browser but I can't find that back now. Some googling gives: http://code.google.com/p/browsertests/wiki/RefTests Benoit On 13-04-16 01:13 PM, Gregg Tavares wrote: > There are currently 4 manual WebGL Conformance Tests not included in > the auto run tests > > https://www.khronos.org/registry/webgl/sdk/tests/conformance/manual/ > > 3 of them are in the 1.0.2 snapshot > > They're manually run because they they are verifying compositing > behavior and/or fullscreen behavior. > > Should these be required to pass for conformance? > > Thoughts? > > > > > > One idea to make this easier would be to add an option to auto-run > these tests where the browser vendor could run there browser in a mode > that allows these things to be checked. On other words, something like > > https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html?manual_tests=true > > We could add some stubs so the browser vendor could provide functions > to make this automate-able like takeScreenshot() and goFullscreen() > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Tue Apr 16 12:40:22 2013 From: gma...@ (Gregg Tavares) Date: Tue, 16 Apr 2013 12:40:22 -0700 Subject: [Public WebGL] Manual WebGL Conformance Tests In-Reply-To: <516D8C7C.9060804@mozilla.com> References: <516D8C7C.9060804@mozilla.com> Message-ID: That would be awesome. Unfortunately that project looks abandoned. > 2 yrs since last commit I'm sure we can figure out something, even if we need browser specific glue for a while. On Tue, Apr 16, 2013 at 10:38 AM, Benoit Jacob wrote: > > The issue of cross-browser compositor testing is really an impotant and > useful problem to solve. But I don't believe that manual testing is the > right solution. Instead, there should be a cross-browser Web API to > access the compositor rendering. It would have to be accessible only to > privileged code for obvious reasons. > > Such tests are called Reftests on the Mozilla side; I thought that there > had been talk about making them cross-browser but I can't find that back > now. Some googling gives: > http://code.google.com/p/browsertests/wiki/RefTests > > Benoit > > On 13-04-16 01:13 PM, Gregg Tavares wrote: > > There are currently 4 manual WebGL Conformance Tests not included in > > the auto run tests > > > > https://www.khronos.org/registry/webgl/sdk/tests/conformance/manual/ > > > > 3 of them are in the 1.0.2 snapshot > > > > They're manually run because they they are verifying compositing > > behavior and/or fullscreen behavior. > > > > Should these be required to pass for conformance? > > > > Thoughts? > > > > > > > > > > > > One idea to make this easier would be to add an option to auto-run > > these tests where the browser vendor could run there browser in a mode > > that allows these things to be checked. On other words, something like > > > > > https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html?manual_tests=true > > > > We could add some stubs so the browser vendor could provide functions > > to make this automate-able like takeScreenshot() and goFullscreen() > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Tue Apr 16 12:51:21 2013 From: din...@ (Dean Jackson) Date: Wed, 17 Apr 2013 05:51:21 +1000 Subject: [Public WebGL] Manual WebGL Conformance Tests In-Reply-To: References: <516D8C7C.9060804@mozilla.com> Message-ID: <98FF5A4A-2677-4583-9940-E89D5E6A5370@apple.com> On 17/04/2013, at 5:40 AM, Gregg Tavares wrote: > That would be awesome. > > Unfortunately that project looks abandoned. > 2 yrs since last commit If you're talking about reftests in general, they have been in WebKit/Blink for a long while now, and there is a big effort at W3C around them. Look around in LayoutTests for: testname.html testname-expected.html In order to have them as part of the WebGL test suite will rely on the browser testing system, unfortunately. Dean > > I'm sure we can figure out something, even if we need browser specific glue for a while. > > > On Tue, Apr 16, 2013 at 10:38 AM, Benoit Jacob wrote: > > The issue of cross-browser compositor testing is really an impotant and > useful problem to solve. But I don't believe that manual testing is the > right solution. Instead, there should be a cross-browser Web API to > access the compositor rendering. It would have to be accessible only to > privileged code for obvious reasons. > > Such tests are called Reftests on the Mozilla side; I thought that there > had been talk about making them cross-browser but I can't find that back > now. Some googling gives: > http://code.google.com/p/browsertests/wiki/RefTests > > Benoit > > On 13-04-16 01:13 PM, Gregg Tavares wrote: > > There are currently 4 manual WebGL Conformance Tests not included in > > the auto run tests > > > > https://www.khronos.org/registry/webgl/sdk/tests/conformance/manual/ > > > > 3 of them are in the 1.0.2 snapshot > > > > They're manually run because they they are verifying compositing > > behavior and/or fullscreen behavior. > > > > Should these be required to pass for conformance? > > > > Thoughts? > > > > > > > > > > > > One idea to make this easier would be to add an option to auto-run > > these tests where the browser vendor could run there browser in a mode > > that allows these things to be checked. On other words, something like > > > > https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html?manual_tests=true > > > > We could add some stubs so the browser vendor could provide functions > > to make this automate-able like takeScreenshot() and goFullscreen() > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kir...@ Fri Apr 19 01:26:09 2013 From: kir...@ (Kirill Prazdnikov) Date: Fri, 19 Apr 2013 12:26:09 +0400 Subject: [Public WebGL] Textures and mip-mapping question Message-ID: <5170FFA1.2020103@jetbrains.com> Hi, I have an issue with texture mapping: Any texture which does not have the *generateMipmap *call *rendered as blac**k*. Also any non-power of two texture images rendered as black. I use the latest Firefox build on windows. I have read all the spec about texturing here: http://www.khronos.org/registry/webgl/specs/1.0/ And haven not found any mention about the fact that only power-of-two textures supported and all mip-maps have to be generated. Is there intended or probably a bug in Firefox ? Thanks -Kirill -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Fri Apr 19 02:00:25 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Fri, 19 Apr 2013 11:00:25 +0200 Subject: [Public WebGL] Textures and mip-mapping question In-Reply-To: <5170FFA1.2020103@jetbrains.com> References: <5170FFA1.2020103@jetbrains.com> Message-ID: OpenGL ES 2.0 specification http://www.khronos.org/registry/gles/specs/2.0/es_full_spec_2.0.25.pdf 3.6.7, Page 77, on wrap mode repeat > REPEAT is the default behavior for all texture coordinates. 3.7.1, Page 69, on texImage2D > If level is greater than zero, and either width or height is not a power > of two, the error INVALID_VALUE is generated. 3.7.7, Page 81, on mipmapping > q = log2(max(wb; hb)) All arrays from zero through q must be de?ned 3.8.2, Page 87 > Calling a sampler from a fragment shader will return (R; G; B; A) = > (0;0;0;1) if any of the following conditions are true: 3.8.2, Page 88 > A two-dimensional sampler is called, the corresponding texture image is a > non-power-of-two image (as described in the Mipmapping discussion of > section 3.7.7), and either the texture wrap mode is not CLAMP_TO_EDGE, or > the mini?cation ?lter is neither NEAREST nor LINEAR. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kir...@ Fri Apr 19 02:08:36 2013 From: kir...@ (Kirill Prazdnikov) Date: Fri, 19 Apr 2013 13:08:36 +0400 Subject: [Public WebGL] Textures and mip-mapping question In-Reply-To: References: <5170FFA1.2020103@jetbrains.com> Message-ID: <51710994.6020700@jetbrains.com> Thank you. On 4/19/2013 1:00 PM, Florian B?sch wrote: > OpenGL ES 2.0 specification > http://www.khronos.org/registry/gles/specs/2.0/es_full_spec_2.0.25.pdf > > 3.6.7, Page 77, on wrap mode repeat > > REPEAT is the default behavior for all texture coordinates. > > > 3.7.1, Page 69, on texImage2D > > If level is greater than zero, and either width or height is not a > power of two, the error INVALID_VALUE is generated. > > > 3.7.7, Page 81, on mipmapping > > q = log2(max(wb; hb)) > > All arrays from zero through q must be de?ned > > 3.8.2, Page 87 > > Calling a sampler from a fragment shader will return (R; G; B; A) > = (0;0;0;1) if any of the following conditions are true: > > > 3.8.2, Page 88 > > A two-dimensional sampler is called, the corresponding texture > image is a > non-power-of-two image (as described in the Mipmapping discussion of > section 3.7.7), and either the texture wrap mode is not > CLAMP_TO_EDGE, or > the mini?cation ?lter is neither NEAREST nor LINEAR. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Fri Apr 19 06:17:07 2013 From: bja...@ (Benoit Jacob) Date: Fri, 19 Apr 2013 09:17:07 -0400 Subject: [Public WebGL] Textures and mip-mapping question In-Reply-To: <5170FFA1.2020103@jetbrains.com> References: <5170FFA1.2020103@jetbrains.com> Message-ID: <517143D3.2050403@mozilla.com> On 13-04-19 04:26 AM, Kirill Prazdnikov wrote: > Hi, > > I have an issue with texture mapping: > Any texture which does not have the *generateMipmap *call *rendered > as blac**k*. > > Also any non-power of two texture images rendered as black. > I use the latest Firefox build on windows. > > I have read all the spec about texturing here: > http://www.khronos.org/registry/webgl/specs/1.0/ > And haven not found any mention about the fact that only power-of-two > textures supported and all mip-maps have to be generated. > > Is there intended or probably a bug in Firefox ? What Florian said; plus: if you open the Web Console, make sure JS warnings are enabled, and reload your page, you will get a detailed warning message about why your texture is being rendered as black. Benoit > > Thanks > -Kirill > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Sun Apr 21 11:20:31 2013 From: cal...@ (Mark Callow) Date: Sun, 21 Apr 2013 20:20:31 +0200 Subject: [Public WebGL] Textures and mip-mapping question In-Reply-To: <517143D3.2050403@mozilla.com> References: <5170FFA1.2020103@jetbrains.com> <517143D3.2050403@mozilla.com> Message-ID: <51742DEF.8080602@artspark.co.jp> On 13/04/19 15:17, Benoit Jacob wrote: > On 13-04-19 04:26 AM, Kirill Prazdnikov wrote: >> Hi, >> >> I have an issue with texture mapping: >> Any texture which does not have the *generateMipmap *call *rendered >> as blac**k*. >> >> Also any non-power of two texture images rendered as black. >> I use the latest Firefox build on windows. >> >> I have read all the spec about texturing here: >> http://www.khronos.org/registry/webgl/specs/1.0/ >> And haven not found any mention about the fact that only power-of-two >> textures supported and all mip-maps have to be generated. >> >> Is there intended or probably a bug in Firefox ? > > What Florian said; plus: if you open the Web Console, make sure JS > warnings are enabled, and reload your page, you will get a detailed > warning message about why your texture is being rendered as black. > Florian focused on NPOT issues and missed the more fundamental issue. The fundamental issue, which is one of the pitfalls most new OpenGL programmers fall into, is that the default value of MIN_FILTER, NEAREST_MIPMAP_LINEAR, is one which requires a complete mipmap pyramid. If you change MIN_FILTER to NEAREST or LINEAR you will not need to call generateMipmap. Regards -Mark -- ??:????????????????????????????????????????????????????????????? ???????????????????????????????????????????????????????????????? ??. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Apr 21 11:33:22 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sun, 21 Apr 2013 20:33:22 +0200 Subject: [Public WebGL] Textures and mip-mapping question In-Reply-To: <51742DEF.8080602@artspark.co.jp> References: <5170FFA1.2020103@jetbrains.com> <517143D3.2050403@mozilla.com> <51742DEF.8080602@artspark.co.jp> Message-ID: On Sun, Apr 21, 2013 at 8:20 PM, Mark Callow wrote: > Florian focused on NPOT issues and missed the more fundamental issue. > Did not. Re-read specification quotes, all relevant sections related to filtering, pyramid completeness and POT are quoted. -------------- next part -------------- An HTML attachment was scrubbed... URL: From cal...@ Sun Apr 21 12:44:46 2013 From: cal...@ (Mark Callow) Date: Sun, 21 Apr 2013 21:44:46 +0200 Subject: [Public WebGL] Textures and mip-mapping question In-Reply-To: References: <5170FFA1.2020103@jetbrains.com> <517143D3.2050403@mozilla.com> <51742DEF.8080602@artspark.co.jp> Message-ID: <517441AE.6030809@artspark.co.jp> On 13/04/21 20:33, Florian B?sch wrote: > On Sun, Apr 21, 2013 at 8:20 PM, Mark Callow > > wrote: > > Florian focused on NPOT issues and missed the more fundamental issue. > > Did not. Re-read specification quotes, all relevant sections related > to filtering, pyramid completeness and POT are quoted. I have about had it with your attitude on this mailing list. Where in the following complete quote of your message do you quote the part of the spec saying the initial value of MIN_FILTER is NEAREST_MIPMAP_LINEAR? The quotes from pp 77, 69, 87-88 all have to do with NPOT textures. Yes the quote from p81 is more general but will have done nothing to inform the OP of his fundamental issue. > 3.6.7, Page 77, on wrap mode repeat > > REPEAT is the default behavior for all texture coordinates. > > > 3.7.1, Page 69, on texImage2D > > If level is greater than zero, and either width or height is not a > power of two, the error INVALID_VALUE is generated. > > > 3.7.7, Page 81, on mipmapping > > q = log2(max(wb; hb)) > > All arrays from zero through q must be de?ned > > > 3.8.2, Page 87 > > Calling a sampler from a fragment shader will return (R; G; B; A) > = (0;0;0;1) if any of the following conditions are true: > > > 3.8.2, Page 88 > > A two-dimensional sampler is called, the corresponding texture > image is a > non-power-of-two image (as described in the Mipmapping discussion of > section 3.7.7), and either the texture wrap mode is not > CLAMP_TO_EDGE, or > the mini?cation ?lter is neither NEAREST nor LINEAR. > Regards -Mark -- ???????????????????????????????????? ???????????????????????????? ??????? ???????????????????????????????????? ????????????????????? ??. 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. -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Apr 21 12:53:08 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Sun, 21 Apr 2013 21:53:08 +0200 Subject: [Public WebGL] Textures and mip-mapping question In-Reply-To: <517441AE.6030809@artspark.co.jp> References: <5170FFA1.2020103@jetbrains.com> <517143D3.2050403@mozilla.com> <51742DEF.8080602@artspark.co.jp> <517441AE.6030809@artspark.co.jp> Message-ID: On Sun, Apr 21, 2013 at 9:44 PM, Mark Callow wrote: > I have about had it with your attitude on this mailing list. > Drama queen much? -------------- next part -------------- An HTML attachment was scrubbed... URL: From din...@ Sun Apr 21 16:21:28 2013 From: din...@ (Dean Jackson) Date: Mon, 22 Apr 2013 09:21:28 +1000 Subject: [Public WebGL] Contributing to the WebGL mailing list In-Reply-To: References: <5170FFA1.2020103@jetbrains.com> <517143D3.2050403@mozilla.com> <51742DEF.8080602@artspark.co.jp> <517441AE.6030809@artspark.co.jp> Message-ID: Hi Florian, Note that this reply is addressed to you, but really goes for anyone. And for everyone else on the list, I apologise for an off-topic message. On 22/04/2013, at 5:53 AM, Florian B?sch wrote: > On Sun, Apr 21, 2013 at 9:44 PM, Mark Callow wrote: > > I have about had it with your attitude on this mailing list. > Drama queen much? The people on this list want to hear your input because you're often providing extremely useful information. You've demonstrated that you're extremely knowledgeable. I expect that's why you contribute: to help WebGL. If you didn't like/want/enjoy contributing, you wouldn't. The problem is that you're encouraging people to stop listening to you by being rude. Now, you might think that is their problem. After all, they should just stop being babies, or fight back, or not take offence, or realise that when you call them stupid that you're smarter/better than them. But the thing that should disappoint you is that you're reducing your own influence. People will really stop listening to you. Maybe you think you don't care about that, but as I said above, you do care, otherwise you wouldn't even bother contributing. There is a difference about caring if people here like/dislike you, and how you yourself feel about the way you spend your time. You're smart enough to know when you're crossing a line that will upset people. All we're asking is that you don't cross the line. That's something that really influential people know how to do. BTW, I expect you're going to want to immediately reply to this message, given your pattern of behaviour in other threads. Feel free. You're not going to upset me if you want to be rude or tell me I'm wrong (although I can't speak for others who are clearly already upset at you). Or maybe you'll just think about it and remain silent, or say "I understand and will try to stop being provocative". It's pretty easy. I really want you to keep contributing. I just hope you can do it in a way that benefits both you and us. PS. If I were to reply to myself, it would be a sarcastic "Thanks Dr Phil!!", but I have no idea how international the venerable Dr McGraw and his "You need to get excited about your life / How's that working out for you?" daytime TV show are. Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: From mar...@ Sun Apr 21 21:58:32 2013 From: mar...@ (markus_schuetz) Date: Mon, 22 Apr 2013 06:58:32 +0200 Subject: [Public WebGL] Contributing to the WebGL mailing list Message-ID: As a long time reader of this mailing list, I agree with you. -- Diese Nachricht wurde von meinem Android Mobiltelefon mit GMX Mail gesendet. Dean Jackson schrieb: Hi Florian, Note that this reply is addressed to you, but really goes for anyone. And for everyone else on the list, I apologise for an off-topic message. On 22/04/2013, at 5:53 AM, Florian B?sch wrote: On Sun, Apr 21, 2013 at 9:44 PM, Mark Callow wrote: I have about had it with your attitude on this mailing list. Drama queen much? The people on this list want to hear your input because you're often providing extremely useful information. You've demonstrated that you're extremely knowledgeable. I expect that's why you contribute: to help WebGL. If you didn't like/want/enjoy contributing, you wouldn't. The problem is that you're encouraging people to stop listening to you by being rude. Now, you might think that is their problem. After all, they should just stop being babies, or fight back, or not take offence, or realise that when you call them stupid that you're smarter/better than them. But the thing that should disappoint you is that you're reducing your own influence. People will really stop listening to you. Maybe you think you don't care about that, but as I said above, you do care, otherwise you wouldn't even bother contributing. There is a difference about caring if people here like/dislike you, and how you yourself feel about the way you spend your time. You're smart enough to know when you're crossing a line that will upset people. All we're asking is that you don't cross the line. That's something that really influential people know how to do. BTW, I expect you're going to want to immediately reply to this message, given your pattern of behaviour in other threads. Feel free. You're not going to upset me if you want to be rude or tell me I'm wrong (although I can't speak for others who are clearly already upset at you). Or maybe you'll just think about it and remain silent, or say "I understand and will try to stop being provocative". It's pretty easy. I really want you to keep contributing. I just hope you can do it in a way that benefits both you and us. PS. If I were to reply to myself, it would be a sarcastic "Thanks Dr Phil!!", but I have no idea how international the venerable Dr McGraw and his "You need to get excited about your life / How's that working out for you?" daytime TV show are. Dean -------------- next part -------------- An HTML attachment was scrubbed... URL: From pya...@ Sun Apr 21 23:30:23 2013 From: pya...@ (=?ISO-8859-1?Q?Florian_B=F6sch?=) Date: Mon, 22 Apr 2013 08:30:23 +0200 Subject: [Public WebGL] Re: Contributing to the WebGL mailing list In-Reply-To: References: <5170FFA1.2020103@jetbrains.com> <517143D3.2050403@mozilla.com> <51742DEF.8080602@artspark.co.jp> <517441AE.6030809@artspark.co.jp> Message-ID: Sometimes I'm an insufferable asshole and sometimes I'm not. It depends on where between down or up I am which influences my sensitivity, feeling of self worth, contentness, patience etc. I wish I had some control over this, but I don't. The cycles wash over me like the tides coming and going. This makes my life difficult, and it makes it difficult for everybody around me, and I know that. I try to put a wall between me and the outside world to protect them from my emotional life. It does mostly work, but sometimes it is leaky, and rarely it has a breakdown. There's choices I have to make in how to deal with this issue. I could just dig in for however long it takes to wash over me, but that's not a terribly good idea. I wouldn't get anything done for weeks on end if I did that. So about the only choice I have when I want to be halfways functional is carry on, and life with the unpleasant side effects, warts'n all. -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Apr 22 13:33:56 2013 From: kbr...@ (Kenneth Russell) Date: Mon, 22 Apr 2013 13:33:56 -0700 Subject: [Public WebGL] Re: Contributing to the WebGL mailing list In-Reply-To: References: <5170FFA1.2020103@jetbrains.com> <517143D3.2050403@mozilla.com> <51742DEF.8080602@artspark.co.jp> <517441AE.6030809@artspark.co.jp> Message-ID: Florian, I value your contributions to the WebGL community; you've added several valuable extensions and helped clear up several corner cases in the specification and conformance tests. I echo Dean's sentiment that I want you to continue to contribute. Unfortunately, these rude interactions damage not only your reputation but also damage the WebGL community. Other long-time contributors to OpenGL, OpenGL ES, and WebGL are on the verge of abandoning the WebGL mailing list as a direct consequence of the abrasive interactions that have happened here over the past few months. I personally do not want that to happen, and will take administrative actions to prevent it. Understanding your personal issues, I can suggest a couple of techniques which might help, such as not sending replies immediately, but letting them sit for an hour and then re-reading them. Feel free to contact me offline if you want to discuss more ideas. All, let's please let our emotions cool down and move forward with a civil, professional and technically focused tone. There's a lot of work to be done to move forward the WebGL spec and make implementations robust. Let's focus on that. -Ken On Sun, Apr 21, 2013 at 11:30 PM, Florian B?sch wrote: > Sometimes I'm an insufferable asshole and sometimes I'm not. It depends on > where between down or up I am which influences my sensitivity, feeling of > self worth, contentness, patience etc. > > I wish I had some control over this, but I don't. The cycles wash over me > like the tides coming and going. This makes my life difficult, and it makes > it difficult for everybody around me, and I know that. I try to put a wall > between me and the outside world to protect them from my emotional life. It > does mostly work, but sometimes it is leaky, and rarely it has a breakdown. > > There's choices I have to make in how to deal with this issue. I could just > dig in for however long it takes to wash over me, but that's not a terribly > good idea. I wouldn't get anything done for weeks on end if I did that. So > about the only choice I have when I want to be halfways functional is carry > on, and life with the unpleasant side effects, warts'n all. ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Mon Apr 22 14:00:20 2013 From: gma...@ (Gregg Tavares) Date: Mon, 22 Apr 2013 14:00:20 -0700 Subject: [Public WebGL] Re: Contributing to the WebGL mailing list In-Reply-To: References: <5170FFA1.2020103@jetbrains.com> <517143D3.2050403@mozilla.com> <51742DEF.8080602@artspark.co.jp> <517441AE.6030809@artspark.co.jp> Message-ID: Just to add my own 2?. I personally have the issue that I often say things in way that causes offence or directly or indirectly puts the other person down. If I'm lucky you haven't seen examples on this list but trust me I have this problem. What I've noticed that helps me is (when I'm sane enough to follow my own advice) 1) I don't reply immediately 2) If I do write a reply and manage to notice it's confrontational I don't send it. Then re-write it tomorrow or at least several hours later. 3) Ask questions instead of asserting my opinion eg: asserting: gl.texImage2D with an image will be USELESS unless I can choose to load PNG files without the browser applying color correction and pre-multiplying the alpha! questioning: How would I load an normal map with height in the alpha channel if there is no way to load a PNG file without the browser applying color correction and pre-multiplying the alpha? I'm sure I still sometimes phrase the question in an insulting way but hopefully the act of putting issues into questions helps me catch myself. I've learned this technique from fellow developers who review my code and noticing my own reactions. When they assert that my code sucks I get defensive. When they ask if I thought about an issue I don't get defensive and instead get more thoughtful and listen to what they are saying. On Mon, Apr 22, 2013 at 1:33 PM, Kenneth Russell wrote: > > Florian, I value your contributions to the WebGL community; you've > added several valuable extensions and helped clear up several corner > cases in the specification and conformance tests. I echo Dean's > sentiment that I want you to continue to contribute. > > Unfortunately, these rude interactions damage not only your reputation > but also damage the WebGL community. Other long-time contributors to > OpenGL, OpenGL ES, and WebGL are on the verge of abandoning the WebGL > mailing list as a direct consequence of the abrasive interactions that > have happened here over the past few months. I personally do not want > that to happen, and will take administrative actions to prevent it. > > Understanding your personal issues, I can suggest a couple of > techniques which might help, such as not sending replies immediately, > but letting them sit for an hour and then re-reading them. Feel free > to contact me offline if you want to discuss more ideas. > > All, let's please let our emotions cool down and move forward with a > civil, professional and technically focused tone. There's a lot of > work to be done to move forward the WebGL spec and make > implementations robust. Let's focus on that. > > -Ken > > > > On Sun, Apr 21, 2013 at 11:30 PM, Florian B?sch wrote: > > Sometimes I'm an insufferable asshole and sometimes I'm not. It depends > on > > where between down or up I am which influences my sensitivity, feeling of > > self worth, contentness, patience etc. > > > > I wish I had some control over this, but I don't. The cycles wash over me > > like the tides coming and going. This makes my life difficult, and it > makes > > it difficult for everybody around me, and I know that. I try to put a > wall > > between me and the outside world to protect them from my emotional life. > It > > does mostly work, but sometimes it is leaky, and rarely it has a > breakdown. > > > > There's choices I have to make in how to deal with this issue. I could > just > > dig in for however long it takes to wash over me, but that's not a > terribly > > good idea. I wouldn't get anything done for weeks on end if I did that. > So > > about the only choice I have when I want to be halfways functional is > carry > > on, and life with the unpleasant side effects, warts'n all. > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Apr 22 16:30:33 2013 From: kbr...@ (Kenneth Russell) Date: Mon, 22 Apr 2013 16:30:33 -0700 Subject: [Public WebGL] Manual WebGL Conformance Tests In-Reply-To: <98FF5A4A-2677-4583-9940-E89D5E6A5370@apple.com> References: <516D8C7C.9060804@mozilla.com> <98FF5A4A-2677-4583-9940-E89D5E6A5370@apple.com> Message-ID: Reftests are a good idea in general, but do they solve the problem Gregg mentioned with full-screen tests? If not, then another project which might help is Telemetry: http://dev.chromium.org/developers/telemetry . Telemetry is a framework that allows tests to be run against a browser on another machine. It was specifically designed for executing tests on operating systems like Android which don't have a command line. Privileged operations like going full-screen without a user gesture would be exposed only when running the Telemetry harness. It only requires the browser to speak the DevTools Remote Debugging Protocol, and doesn't make other assumptions about the underlying browser. -Ken On Tue, Apr 16, 2013 at 12:51 PM, Dean Jackson wrote: > > On 17/04/2013, at 5:40 AM, Gregg Tavares wrote: > > That would be awesome. > > Unfortunately that project looks abandoned. > 2 yrs since last commit > > > If you're talking about reftests in general, they have been in WebKit/Blink > for a long while now, and there is a big effort at W3C around them. > > Look around in LayoutTests for: > > testname.html > testname-expected.html > > In order to have them as part of the WebGL test suite will rely on the > browser testing system, unfortunately. > > Dean > > > I'm sure we can figure out something, even if we need browser specific glue > for a while. > > > On Tue, Apr 16, 2013 at 10:38 AM, Benoit Jacob wrote: >> >> >> The issue of cross-browser compositor testing is really an impotant and >> useful problem to solve. But I don't believe that manual testing is the >> right solution. Instead, there should be a cross-browser Web API to >> access the compositor rendering. It would have to be accessible only to >> privileged code for obvious reasons. >> >> Such tests are called Reftests on the Mozilla side; I thought that there >> had been talk about making them cross-browser but I can't find that back >> now. Some googling gives: >> http://code.google.com/p/browsertests/wiki/RefTests >> >> Benoit >> >> On 13-04-16 01:13 PM, Gregg Tavares wrote: >> > There are currently 4 manual WebGL Conformance Tests not included in >> > the auto run tests >> > >> > https://www.khronos.org/registry/webgl/sdk/tests/conformance/manual/ >> > >> > 3 of them are in the 1.0.2 snapshot >> > >> > They're manually run because they they are verifying compositing >> > behavior and/or fullscreen behavior. >> > >> > Should these be required to pass for conformance? >> > >> > Thoughts? >> > >> > >> > >> > >> > >> > One idea to make this easier would be to add an option to auto-run >> > these tests where the browser vendor could run there browser in a mode >> > that allows these things to be checked. On other words, something like >> > >> > >> > https://www.khronos.org/registry/webgl/sdk/tests/webgl-conformance-tests.html?manual_tests=true >> > >> > We could add some stubs so the browser vendor could provide functions >> > to make this automate-able like takeScreenshot() and goFullscreen() >> > >> >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kir...@ Wed Apr 24 11:15:49 2013 From: kir...@ (Kirill Prazdnikov) Date: Wed, 24 Apr 2013 22:15:49 +0400 Subject: [Public WebGL] A problem with 3D and 2D canvases Message-ID: <51782155.20200@jetbrains.com> Hi, probably wrong forum, please let me know. I have a Canvas and one WebGL context and have no issues with it. Also I have a 2D Canvas + context which is off-screen and is used to render some images on it and later it used as the source to texImage2d. I have no issues so far, but for some reason I`m getting the following WebGL error in Firefox: *Error: WebGL: Exceeded 16 live WebGL contexts for this principal, losing the least recently used one. * What am I doing wrong ? Thanks, -Kirill -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Wed Apr 24 11:23:06 2013 From: gma...@ (Gregg Tavares) Date: Wed, 24 Apr 2013 11:23:06 -0700 Subject: [Public WebGL] A problem with 3D and 2D canvases In-Reply-To: <51782155.20200@jetbrains.com> References: <51782155.20200@jetbrains.com> Message-ID: Yea, the correct forum for this is stackoverflow or the webgl dev list ( https://groups.google.com/forum/?fromgroups#!forum/webgl-dev-list) But in answer to your question. It sounds like you are some how creating multiple WebGL contexts. On Wed, Apr 24, 2013 at 11:15 AM, Kirill Prazdnikov < kirill.prazdnikov...@> wrote: > Hi, probably wrong forum, please let me know. > > I have a Canvas and one WebGL context and have no issues with it. Also I > have a 2D Canvas + context which is off-screen and is used to render some > images on it and later it used as the source to texImage2d. > > I have no issues so far, but for some reason I`m getting the following > WebGL error in Firefox: > > *Error: WebGL: Exceeded 16 live WebGL contexts for this principal, losing > the least recently used one. * > > What am I doing wrong ? > > Thanks, > > -Kirill > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Wed Apr 24 12:25:46 2013 From: bja...@ (Benoit Jacob) Date: Wed, 24 Apr 2013 15:25:46 -0400 Subject: [Public WebGL] A problem with 3D and 2D canvases In-Reply-To: References: <51782155.20200@jetbrains.com> Message-ID: <517831BA.9080200@mozilla.com> On 13-04-24 02:23 PM, Gregg Tavares wrote: > Yea, the correct forum for this is stackoverflow or the webgl dev list > (https://groups.google.com/forum/?fromgroups#!forum/webgl-dev-list > ) > > But in answer to your question. It sounds like you are some how > creating multiple WebGL contexts. Yep. "Error" is a misnomer here. It's just an informative message. Likely you have many background tabs with WebGL contexts, and some of your oldest background tabs just lots its WebGL context. That's nothing unusual, WebGL contexts are discardable resources. If you need your background WebGL-using tabs to survive such events, let them handle the webglcontextlost/restored events. Benoit > > > On Wed, Apr 24, 2013 at 11:15 AM, Kirill Prazdnikov > > wrote: > > Hi, probably wrong forum, please let me know. > > I have a Canvas and one WebGL context and have no issues with it. > Also I have a 2D Canvas + context which is off-screen and is used > to render some images on it and later it used as the source to > texImage2d. > > I have no issues so far, but for some reason I`m getting the > following WebGL error in Firefox: > > *Error: WebGL: Exceeded 16 live WebGL contexts for this principal, > losing the least recently used one. * > > What am I doing wrong ? > > Thanks, > > -Kirill > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cab...@ Wed Apr 24 13:23:17 2013 From: cab...@ (Rik Cabanier) Date: Wed, 24 Apr 2013 13:23:17 -0700 Subject: [Public WebGL] 2d canvas context to WebGL Message-ID: All, Sorry if this is already documented but is there a way to efficiently use a 2d canvas context in WebGL? We've seen cases where people want to apply effects on 2d contexts and they're doing this by copying the 2d canvas to a buffer, running a shader on it and getting the result back. This is an expensive workflow both in time and memory. Since the 2d canvas is already on the GPU (on most browsers), is there a way to directly access it from WebGL? Thanks! -------------- next part -------------- An HTML attachment was scrubbed... URL: From bja...@ Wed Apr 24 13:47:26 2013 From: bja...@ (Benoit Jacob) Date: Wed, 24 Apr 2013 16:47:26 -0400 Subject: [Public WebGL] 2d canvas context to WebGL In-Reply-To: References: Message-ID: <517844DE.9070601@mozilla.com> A 2D canvas can be passed directly to WebGL texImage2D. This happens to be slow in Firefox at the moment (the canvas is currently read back and re-uploaded), but that could probably be fixed if there is real-world pressure in that direction. Benoit On 13-04-24 04:23 PM, Rik Cabanier wrote: > All, > > Sorry if this is already documented but is there a way to efficiently > use a 2d canvas context in WebGL? > We've seen cases where people want to apply effects on 2d contexts and > they're doing this by copying the 2d canvas to a buffer, running a > shader on it and getting the result back. > This is an expensive workflow both in time and memory. > > Since the 2d canvas is already on the GPU (on most browsers), is there > a way to directly access it from WebGL? > > Thanks! ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cab...@ Wed Apr 24 13:59:10 2013 From: cab...@ (Rik Cabanier) Date: Wed, 24 Apr 2013 13:59:10 -0700 Subject: [Public WebGL] 2d canvas context to WebGL In-Reply-To: <517844DE.9070601@mozilla.com> References: <517844DE.9070601@mozilla.com> Message-ID: Great! So Safari and Chrome implement this efficiently? Also is this documented somewhere? On Wed, Apr 24, 2013 at 1:47 PM, Benoit Jacob wrote: > > A 2D canvas can be passed directly to WebGL texImage2D. > > This happens to be slow in Firefox at the moment (the canvas is > currently read back and re-uploaded), but that could probably be fixed > if there is real-world pressure in that direction. > > Benoit > > On 13-04-24 04:23 PM, Rik Cabanier wrote: > > All, > > > > Sorry if this is already documented but is there a way to efficiently > > use a 2d canvas context in WebGL? > > We've seen cases where people want to apply effects on 2d contexts and > > they're doing this by copying the 2d canvas to a buffer, running a > > shader on it and getting the result back. > > This is an expensive workflow both in time and memory. > > > > Since the 2d canvas is already on the GPU (on most browsers), is there > > a way to directly access it from WebGL? > > > > Thanks! > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Wed Apr 24 14:07:52 2013 From: kbr...@ (Kenneth Russell) Date: Wed, 24 Apr 2013 14:07:52 -0700 Subject: [Public WebGL] 2d canvas context to WebGL In-Reply-To: References: <517844DE.9070601@mozilla.com> Message-ID: There is definitely code in Chrome to make Canvas -> WebGL uploads efficient (as well as the reverse direction), but I believe there are still some slow paths. See https://code.google.com/p/chromium/issues/detail?id=233205 for example. I don't know how much of this made it in to Safari. On Wed, Apr 24, 2013 at 1:59 PM, Rik Cabanier wrote: > Great! > So Safari and Chrome implement this efficiently? Also is this documented > somewhere? > > > On Wed, Apr 24, 2013 at 1:47 PM, Benoit Jacob wrote: >> >> >> A 2D canvas can be passed directly to WebGL texImage2D. >> >> This happens to be slow in Firefox at the moment (the canvas is >> currently read back and re-uploaded), but that could probably be fixed >> if there is real-world pressure in that direction. >> >> Benoit >> >> On 13-04-24 04:23 PM, Rik Cabanier wrote: >> > All, >> > >> > Sorry if this is already documented but is there a way to efficiently >> > use a 2d canvas context in WebGL? >> > We've seen cases where people want to apply effects on 2d contexts and >> > they're doing this by copying the 2d canvas to a buffer, running a >> > shader on it and getting the result back. >> > This is an expensive workflow both in time and memory. >> > >> > Since the 2d canvas is already on the GPU (on most browsers), is there >> > a way to directly access it from WebGL? >> > >> > Thanks! >> >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From thu...@ Wed Apr 24 14:13:43 2013 From: thu...@ (Ben Adams) Date: Wed, 24 Apr 2013 22:13:43 +0100 Subject: [Public WebGL] 2d canvas context to WebGL In-Reply-To: References: <517844DE.9070601@mozilla.com> Message-ID: Hi Rik texImage2D takes a parameter of ImageData, HTMLImageElement, HTMLCanvasElement, or HTMLVideoElement So you just switch the img element for the canvas element Kind regards Ben On 24 April 2013 21:59, Rik Cabanier wrote: > Great! > So Safari and Chrome implement this efficiently? Also is this documented > somewhere? > > > On Wed, Apr 24, 2013 at 1:47 PM, Benoit Jacob wrote: > >> >> A 2D canvas can be passed directly to WebGL texImage2D. >> >> This happens to be slow in Firefox at the moment (the canvas is >> currently read back and re-uploaded), but that could probably be fixed >> if there is real-world pressure in that direction. >> >> Benoit >> >> On 13-04-24 04:23 PM, Rik Cabanier wrote: >> > All, >> > >> > Sorry if this is already documented but is there a way to efficiently >> > use a 2d canvas context in WebGL? >> > We've seen cases where people want to apply effects on 2d contexts and >> > they're doing this by copying the 2d canvas to a buffer, running a >> > shader on it and getting the result back. >> > This is an expensive workflow both in time and memory. >> > >> > Since the 2d canvas is already on the GPU (on most browsers), is there >> > a way to directly access it from WebGL? >> > >> > Thanks! >> >> >> ----------------------------------------------------------- >> You are currently subscribed to public_webgl...@ >> To unsubscribe, send an email to majordomo...@ with >> the following command in the body of your email: >> unsubscribe public_webgl >> ----------------------------------------------------------- >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ash...@ Wed Apr 24 17:41:20 2013 From: ash...@ (Ashley Gullen) Date: Thu, 25 Apr 2013 01:41:20 +0100 Subject: [Public WebGL] 2d canvas context to WebGL In-Reply-To: <517844DE.9070601@mozilla.com> References: <517844DE.9070601@mozilla.com> Message-ID: FWIW, Construct 2 uses texImage2D with a 2D canvas to render text. Since WebGL doesn't have built-in text rendering, rendering text to a 2D canvas then copying it to a WebGL texture can be useful (note DOM text doesn't allow you to draw over text or process text effects in the WebGL context). If the text content changes every frame, it has to call texImage2D with a 2D canvas every frame. I don't think many games are realistically bottlenecked on that and it's fairly easy to work around, but it's a major use case for that particular overload. Ashley Gullen Scirra.com On 24 April 2013 21:47, Benoit Jacob wrote: > > A 2D canvas can be passed directly to WebGL texImage2D. > > This happens to be slow in Firefox at the moment (the canvas is > currently read back and re-uploaded), but that could probably be fixed > if there is real-world pressure in that direction. > > Benoit > > On 13-04-24 04:23 PM, Rik Cabanier wrote: > > All, > > > > Sorry if this is already documented but is there a way to efficiently > > use a 2d canvas context in WebGL? > > We've seen cases where people want to apply effects on 2d contexts and > > they're doing this by copying the 2d canvas to a buffer, running a > > shader on it and getting the result back. > > This is an expensive workflow both in time and memory. > > > > Since the 2d canvas is already on the GPU (on most browsers), is there > > a way to directly access it from WebGL? > > > > Thanks! > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom...@ Thu Apr 25 03:44:38 2013 From: tom...@ (Tom Payne) Date: Thu, 25 Apr 2013 12:44:38 +0200 Subject: [Public WebGL] WebGL API request: asynchronous texture uploads Message-ID: Texture uploads are slow on mobile devices [1], and have unpredictable performance, and it's hard to avoid jank. Applications that stream textures on demand, like map and virtual globe applications, are particularly sensitive to this. Can the WebGL API be extended to allow asynchronous texture uploads? Something like: var texture = gl.createTexture(); gl.bindTexture(gl.TEXTURE_2D, texture); gl.texImage2DAsync( gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, image, function() { // texture now uploaded, do something }); // gl.texImage2DAsync also implicitly unbinds the texture This might lead to the second advantage of eventually allowing the browser to JPEG/PNG decode the image in a separate, low-priority, thread. Does this make sense? Many thanks, Tom [1] http://www.chromium.org/developers/design-documents/impl-side-paintingsection "Texture Upload" -- Camptocamp SA Tom PAYNE PSE A CH-1015 Lausanne +41 21 619 10 13 (direct) +41 21 619 10 10 (centrale) +41 21 619 10 00 (fax) -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Thu Apr 25 09:33:17 2013 From: gma...@ (Gregg Tavares) Date: Thu, 25 Apr 2013 09:33:17 -0700 Subject: [Public WebGL] WebGL API request: asynchronous texture uploads In-Reply-To: References: Message-ID: Rather than making 50 async APIs the solution to asynchronous features in WebGL is allowing WebGL in web workers. http://www.khronos.org/webgl/wiki/SharedResouces http://wiki.whatwg.org/wiki/CanvasInWorkers Which are being actively worked on. On Thu, Apr 25, 2013 at 3:44 AM, Tom Payne wrote: > Texture uploads are slow on mobile devices [1], and have unpredictable > performance, and it's hard to avoid jank. Applications that stream textures > on demand, like map and virtual globe applications, are particularly > sensitive to this. > > Can the WebGL API be extended to allow asynchronous texture uploads? > > Something like: > > var texture = gl.createTexture(); > gl.bindTexture(gl.TEXTURE_2D, texture); > gl.texImage2DAsync( > gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, image, > function() { > // texture now uploaded, do something > }); > // gl.texImage2DAsync also implicitly unbinds the texture > > This might lead to the second advantage of eventually allowing the browser > to JPEG/PNG decode the image in a separate, low-priority, thread. > > Does this make sense? > > Many thanks, > Tom > > > [1] http://www.chromium.org/developers/design-documents/impl-side-paintingsection "Texture Upload" > > > > -- > Camptocamp SA > Tom PAYNE > PSE A > CH-1015 Lausanne > > +41 21 619 10 13 (direct) > +41 21 619 10 10 (centrale) > +41 21 619 10 00 (fax) > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kir...@ Thu Apr 25 09:49:48 2013 From: kir...@ (Kirill Prazdnikov) Date: Thu, 25 Apr 2013 20:49:48 +0400 Subject: [Public WebGL] WebGL API request: asynchronous texture uploads In-Reply-To: References: Message-ID: <51795EAC.6050401@jetbrains.com> I will repeat my question in public: What does "slow: mean ? Have you measured in numbers ? Which mobile devices do you imply ? Is there a difference in speed for updating - form Canvas - from HTMLImageElement - form ImageData Thanks -Kirill On 4/25/2013 2:44 PM, Tom Payne wrote: > Texture uploads are slow on mobile devices [1], and have unpredictable > performance, and it's hard to avoid jank. Applications that stream > textures on demand, like map and virtual globe applications, are > particularly sensitive to this. > > Can the WebGL API be extended to allow asynchronous texture uploads? > > Something like: > > var texture = gl.createTexture(); > gl.bindTexture(gl.TEXTURE_2D, texture); > gl.texImage2DAsync( > gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, image, > function() { > // texture now uploaded, do something > }); > // gl.texImage2DAsync also implicitly unbinds the texture > > This might lead to the second advantage of eventually allowing the > browser to JPEG/PNG decode the image in a separate, low-priority, thread. > > Does this make sense? > > Many thanks, > Tom > > > [1] > http://www.chromium.org/developers/design-documents/impl-side-painting > section "Texture Upload" > > > > -- > Camptocamp SA > Tom PAYNE > PSE A > CH-1015 Lausanne > > +41 21 619 10 13 (direct) > +41 21 619 10 10 (centrale) > +41 21 619 10 00 (fax) -------------- next part -------------- An HTML attachment was scrubbed... URL: From bzb...@ Thu Apr 25 09:56:46 2013 From: bzb...@ (Boris Zbarsky) Date: Thu, 25 Apr 2013 12:56:46 -0400 Subject: [Public WebGL] WebGL API request: asynchronous texture uploads In-Reply-To: <51795EAC.6050401@jetbrains.com> References: <51795EAC.6050401@jetbrains.com> Message-ID: <5179604E.7020101@mit.edu> On 4/25/13 12:49 PM, Kirill Prazdnikov wrote: > What does "slow: mean ? > Have you measured in numbers ? The post you're replying to had a footnote on the phrase "slow on mobile devices" that linked to that data, for what it's worth... -Boris ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From baj...@ Thu Apr 25 10:05:17 2013 From: baj...@ (Brandon Jones) Date: Thu, 25 Apr 2013 10:05:17 -0700 Subject: [Public WebGL] WebGL API request: asynchronous texture uploads In-Reply-To: <51795EAC.6050401@jetbrains.com> References: <51795EAC.6050401@jetbrains.com> Message-ID: On a 15" Retina Macbook Pro I commonly see upload times ranging from ~8-15ms for a single 1024x1024 uncompressed RGB texture with Chrome Canary. This, by the way, is a massive improvement over past measurements which sometimes reached 50ms for the same texture! And that's on a beefy laptop, it's likely to be much worse on a mobile device. As you are probably aware, if a single upload is taking anywhere near 16ms you are probably going to drop a frame when trying to maintain 60Hz rendering. This would probably meet most people's definition of "slow". Compressed textures upload much faster, naturally, but come with their own set of compatibility challenges. --Brandon On Thu, Apr 25, 2013 at 9:49 AM, Kirill Prazdnikov < kirill.prazdnikov...@> wrote: > I will repeat my question in public: > > What does "slow: mean ? > Have you measured in numbers ? > Which mobile devices do you imply ? > Is there a difference in speed for updating > - form Canvas > - from HTMLImageElement > - form ImageData > > Thanks > -Kirill > > > > On 4/25/2013 2:44 PM, Tom Payne wrote: > > Texture uploads are slow on mobile devices [1], and have unpredictable > performance, and it's hard to avoid jank. Applications that stream textures > on demand, like map and virtual globe applications, are particularly > sensitive to this. > > Can the WebGL API be extended to allow asynchronous texture uploads? > > Something like: > > var texture = gl.createTexture(); > gl.bindTexture(gl.TEXTURE_2D, texture); > gl.texImage2DAsync( > gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, image, > function() { > // texture now uploaded, do something > }); > // gl.texImage2DAsync also implicitly unbinds the texture > > This might lead to the second advantage of eventually allowing the > browser to JPEG/PNG decode the image in a separate, low-priority, thread. > > Does this make sense? > > Many thanks, > Tom > > > [1] > http://www.chromium.org/developers/design-documents/impl-side-paintingsection "Texture Upload" > > > > -- > Camptocamp SA > Tom PAYNE > PSE A > CH-1015 Lausanne > > +41 21 619 10 13 (direct) > +41 21 619 10 10 (centrale) > +41 21 619 10 00 (fax) > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Apr 25 11:29:04 2013 From: kbr...@ (Kenneth Russell) Date: Thu, 25 Apr 2013 11:29:04 -0700 Subject: [Public WebGL] WebGL API request: asynchronous texture uploads In-Reply-To: References: Message-ID: Agreed -- the best solution is to support real multithreading in WebGL. We should push forward integrating sharing and Canvas in workers, and not get distracted adding async APIs for every expensive WebGL operation. -Ken On Thu, Apr 25, 2013 at 9:33 AM, Gregg Tavares wrote: > Rather than making 50 async APIs the solution to asynchronous features in > WebGL is allowing WebGL in web workers. > > http://www.khronos.org/webgl/wiki/SharedResouces > > http://wiki.whatwg.org/wiki/CanvasInWorkers > > Which are being actively worked on. > > > > On Thu, Apr 25, 2013 at 3:44 AM, Tom Payne wrote: >> >> Texture uploads are slow on mobile devices [1], and have unpredictable >> performance, and it's hard to avoid jank. Applications that stream textures >> on demand, like map and virtual globe applications, are particularly >> sensitive to this. >> >> Can the WebGL API be extended to allow asynchronous texture uploads? >> >> Something like: >> >> var texture = gl.createTexture(); >> gl.bindTexture(gl.TEXTURE_2D, texture); >> gl.texImage2DAsync( >> gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, image, >> function() { >> // texture now uploaded, do something >> }); >> // gl.texImage2DAsync also implicitly unbinds the texture >> >> This might lead to the second advantage of eventually allowing the browser >> to JPEG/PNG decode the image in a separate, low-priority, thread. >> >> Does this make sense? >> >> Many thanks, >> Tom >> >> >> [1] http://www.chromium.org/developers/design-documents/impl-side-painting >> section "Texture Upload" >> >> >> >> -- >> Camptocamp SA >> Tom PAYNE >> PSE A >> CH-1015 Lausanne >> >> +41 21 619 10 13 (direct) >> +41 21 619 10 10 (centrale) >> +41 21 619 10 00 (fax) > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From tom...@ Thu Apr 25 11:55:13 2013 From: tom...@ (Tom Payne) Date: Thu, 25 Apr 2013 20:55:13 +0200 Subject: [Public WebGL] WebGL API request: asynchronous texture uploads In-Reply-To: References: Message-ID: Thanks all for the fast and informed responses. Consider this request closed. But I am looking forward to support for WebGL and Canvas in WebWorkers :) A bit of background info, to explain "slow": - Map and globe applications, like Google Maps, have more-or-less standardized on 256x256 pixel image tiles - A low-resolution screen is 1024x768 pixels - This requires 5x4 = 20 image tiles (5x4 rather than 4x3 because 4x3 only applies if your screen is perfectly aligned on tile boundaries) - So, when the user clicks zoom, you need to upload 20 textures - If it takes 1ms second per texture (and the Chrome developers have witnessed 2-5ms per texture on mobile) then you completely blow your frame budget Right now, I'm getting better performance from using Canvas 2D than I'm getting from WebGL. This is annoying, because WebGL is lower level and should be able to do better. Texture uploads are a key source of jank, even though we limit texture uploads to one per second. Try the following demos: WebGL: http://ol3js.org/ol3/master/examples/full-screen-drag-rotate-and-zoom.html?renderer=webgl Canvas: http://ol3js.org/ol3/master/examples/full-screen-drag-rotate-and-zoom.html?renderer=canvas WebGL of course offers a lot more, but it would be nice to at least match Canvas 2D performance :) Thanks again - will wait for WebGL support in WebWorkers, because this is certainly a better long solution in the long term. Tom On 25 April 2013 20:29, Kenneth Russell wrote: > Agreed -- the best solution is to support real multithreading in > WebGL. We should push forward integrating sharing and Canvas in > workers, and not get distracted adding async APIs for every expensive > WebGL operation. > > -Ken > > > > On Thu, Apr 25, 2013 at 9:33 AM, Gregg Tavares wrote: > > Rather than making 50 async APIs the solution to asynchronous features in > > WebGL is allowing WebGL in web workers. > > > > http://www.khronos.org/webgl/wiki/SharedResouces > > > > http://wiki.whatwg.org/wiki/CanvasInWorkers > > > > Which are being actively worked on. > > > > > > > > On Thu, Apr 25, 2013 at 3:44 AM, Tom Payne > wrote: > >> > >> Texture uploads are slow on mobile devices [1], and have unpredictable > >> performance, and it's hard to avoid jank. Applications that stream > textures > >> on demand, like map and virtual globe applications, are particularly > >> sensitive to this. > >> > >> Can the WebGL API be extended to allow asynchronous texture uploads? > >> > >> Something like: > >> > >> var texture = gl.createTexture(); > >> gl.bindTexture(gl.TEXTURE_2D, texture); > >> gl.texImage2DAsync( > >> gl.TEXTURE_2D, 0, gl.RGBA, gl.RGBA, gl.UNSIGNED_BYTE, image, > >> function() { > >> // texture now uploaded, do something > >> }); > >> // gl.texImage2DAsync also implicitly unbinds the texture > >> > >> This might lead to the second advantage of eventually allowing the > browser > >> to JPEG/PNG decode the image in a separate, low-priority, thread. > >> > >> Does this make sense? > >> > >> Many thanks, > >> Tom > >> > >> > >> [1] > http://www.chromium.org/developers/design-documents/impl-side-painting > >> section "Texture Upload" > >> > >> > >> > >> -- > >> Camptocamp SA > >> Tom PAYNE > >> PSE A > >> CH-1015 Lausanne > >> > >> +41 21 619 10 13 (direct) > >> +41 21 619 10 10 (centrale) > >> +41 21 619 10 00 (fax) > > > > > -- Camptocamp SA Tom PAYNE PSE A CH-1015 Lausanne +41 21 619 10 13 (direct) +41 21 619 10 10 (centrale) +41 21 619 10 00 (fax) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom...@ Thu Apr 25 11:56:29 2013 From: tom...@ (Tom Payne) Date: Thu, 25 Apr 2013 20:56:29 +0200 Subject: [Public WebGL] WebGL API request: asynchronous texture uploads In-Reply-To: References: Message-ID: On 25 April 2013 20:55, Tom Payne wrote: > Texture uploads are a key source of jank, even though we limit texture > uploads to one per second. > s/second/frame/ -- Camptocamp SA Tom PAYNE PSE A CH-1015 Lausanne +41 21 619 10 13 (direct) +41 21 619 10 10 (centrale) +41 21 619 10 00 (fax) -------------- next part -------------- An HTML attachment was scrubbed... URL: From tpa...@ Thu Apr 25 12:07:18 2013 From: tpa...@ (Tony Parisi) Date: Thu, 25 Apr 2013 12:07:18 -0700 Subject: [Public WebGL] WebGL API request: asynchronous texture uploads In-Reply-To: References: Message-ID: Hi Tom FWIW I'm seeing slightly more "jank" out of your canvas version than the WebGL version. Though, they are pretty close. I'm on a Macbook Air using Chrome. Tony On Thu, Apr 25, 2013 at 11:56 AM, Tom Payne wrote: > On 25 April 2013 20:55, Tom Payne wrote: > >> Texture uploads are a key source of jank, even though we limit texture >> uploads to one per second. >> > > s/second/frame/ > > -- > Camptocamp SA > Tom PAYNE > PSE A > CH-1015 Lausanne > > +41 21 619 10 13 (direct) > +41 21 619 10 10 (centrale) > +41 21 619 10 00 (fax) > -- Tony Parisi tparisi...@ CTO at Large 415.902.8002 Skype auradeluxe Follow me on Twitter! http://twitter.com/auradeluxe Read my blog at http://www.tonyparisi.com/ Learn WebGL http://learningwebgl.com/ Read my book! *WebGL, Up and Running* http://shop.oreilly.com/product/0636920024729.do http://www.amazon.com/dp/144932357X -------------- next part -------------- An HTML attachment was scrubbed... URL: From cab...@ Thu Apr 25 13:26:00 2013 From: cab...@ (Rik Cabanier) Date: Thu, 25 Apr 2013 13:26:00 -0700 Subject: [Public WebGL] 2d canvas context to WebGL In-Reply-To: References: <517844DE.9070601@mozilla.com> Message-ID: One of our frameworks draws into a 2d canvas, transfers it to WebGL, runs a shader and then brings the result back. Just copying a 500x500 canvas to and from WebGL takes: - 16ms on Chrome - 14ms on Firefox - 40ms on Safari This is way to slow to make fluid animations such as this one: http://ads2.msads.net/CIS/48/000/000/000/039/337.swf?fd=www.msn.com (sorry for the flash movie). If you look closely, you will see that the text is blurred during the animation. In most (all?) implementations, the canvas bits were already on the GPU so this time *could* be brought down to zero. Safari is twice as bad as chrome and Firefox. This is probably caused by the optimizations you mentioned. The bug you mentioned is because of synchronous readback, Ideally there would be no readback at all :-) On Wed, Apr 24, 2013 at 2:07 PM, Kenneth Russell wrote: > There is definitely code in Chrome to make Canvas -> WebGL uploads > efficient (as well as the reverse direction), but I believe there are > still some slow paths. See > https://code.google.com/p/chromium/issues/detail?id=233205 for > example. I don't know how much of this made it in to Safari. > > > > On Wed, Apr 24, 2013 at 1:59 PM, Rik Cabanier wrote: > > Great! > > So Safari and Chrome implement this efficiently? Also is this documented > > somewhere? > > > > > > On Wed, Apr 24, 2013 at 1:47 PM, Benoit Jacob > wrote: > >> > >> > >> A 2D canvas can be passed directly to WebGL texImage2D. > >> > >> This happens to be slow in Firefox at the moment (the canvas is > >> currently read back and re-uploaded), but that could probably be fixed > >> if there is real-world pressure in that direction. > >> > >> Benoit > >> > >> On 13-04-24 04:23 PM, Rik Cabanier wrote: > >> > All, > >> > > >> > Sorry if this is already documented but is there a way to efficiently > >> > use a 2d canvas context in WebGL? > >> > We've seen cases where people want to apply effects on 2d contexts and > >> > they're doing this by copying the 2d canvas to a buffer, running a > >> > shader on it and getting the result back. > >> > This is an expensive workflow both in time and memory. > >> > > >> > Since the 2d canvas is already on the GPU (on most browsers), is there > >> > a way to directly access it from WebGL? > >> > > >> > Thanks! > >> > >> > >> ----------------------------------------------------------- > >> You are currently subscribed to public_webgl...@ > >> To unsubscribe, send an email to majordomo...@ with > >> the following command in the body of your email: > >> unsubscribe public_webgl > >> ----------------------------------------------------------- > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Apr 25 13:31:07 2013 From: kbr...@ (Kenneth Russell) Date: Thu, 25 Apr 2013 13:31:07 -0700 Subject: [Public WebGL] 2d canvas context to WebGL In-Reply-To: References: <517844DE.9070601@mozilla.com> Message-ID: Please file a bug with a self-contained test case. Exposing these issues is the only way they are going to be fixed. -Ken On Thu, Apr 25, 2013 at 1:26 PM, Rik Cabanier wrote: > One of our frameworks draws into a 2d canvas, transfers it to WebGL, runs a > shader and then brings the result back. > Just copying a 500x500 canvas to and from WebGL takes: > > - 16ms on Chrome > - 14ms on Firefox > - 40ms on Safari > > > This is way to slow to make fluid animations such as this one: > http://ads2.msads.net/CIS/48/000/000/000/039/337.swf?fd=www.msn.com (sorry > for the flash movie). If you look closely, you will see that the text is > blurred during the animation. > In most (all?) implementations, the canvas bits were already on the GPU so > this time *could* be brought down to zero. > > Safari is twice as bad as chrome and Firefox. This is probably caused by the > optimizations you mentioned. > > The bug you mentioned is because of synchronous readback, Ideally there > would be no readback at all :-) > > On Wed, Apr 24, 2013 at 2:07 PM, Kenneth Russell wrote: >> >> There is definitely code in Chrome to make Canvas -> WebGL uploads >> efficient (as well as the reverse direction), but I believe there are >> still some slow paths. See >> https://code.google.com/p/chromium/issues/detail?id=233205 for >> example. I don't know how much of this made it in to Safari. >> >> >> >> On Wed, Apr 24, 2013 at 1:59 PM, Rik Cabanier wrote: >> > Great! >> > So Safari and Chrome implement this efficiently? Also is this documented >> > somewhere? >> > >> > >> > On Wed, Apr 24, 2013 at 1:47 PM, Benoit Jacob >> > wrote: >> >> >> >> >> >> A 2D canvas can be passed directly to WebGL texImage2D. >> >> >> >> This happens to be slow in Firefox at the moment (the canvas is >> >> currently read back and re-uploaded), but that could probably be fixed >> >> if there is real-world pressure in that direction. >> >> >> >> Benoit >> >> >> >> On 13-04-24 04:23 PM, Rik Cabanier wrote: >> >> > All, >> >> > >> >> > Sorry if this is already documented but is there a way to efficiently >> >> > use a 2d canvas context in WebGL? >> >> > We've seen cases where people want to apply effects on 2d contexts >> >> > and >> >> > they're doing this by copying the 2d canvas to a buffer, running a >> >> > shader on it and getting the result back. >> >> > This is an expensive workflow both in time and memory. >> >> > >> >> > Since the 2d canvas is already on the GPU (on most browsers), is >> >> > there >> >> > a way to directly access it from WebGL? >> >> > >> >> > Thanks! >> >> >> >> >> >> ----------------------------------------------------------- >> >> You are currently subscribed to public_webgl...@ >> >> To unsubscribe, send an email to majordomo...@ with >> >> the following command in the body of your email: >> >> unsubscribe public_webgl >> >> ----------------------------------------------------------- >> >> >> > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ben...@ Thu Apr 25 13:40:16 2013 From: ben...@ (Ben Vanik) Date: Thu, 25 Apr 2013 13:40:16 -0700 Subject: [Public WebGL] WebGL API request: asynchronous texture uploads In-Reply-To: References: Message-ID: Gregg, I still am not sure how WebGL in workers helps with removing jankiness caused by long/many texture uploads. It doesn't matter what thread is driving the drawing - it *must* run under 16ms, or animations will skip. Can you explain how you see it helping? I still see a strong need for async texture upload and async read pixels. The only way of removing the need for those APIs, as I see it, is resource sharing between multiple contexts operating in separate threads. That'd be awesome, too, but would require a significant amount more work for a developer to get going than a simple readPixelsAsync call and is a pretty disappointing answer to the problem. On Thu, Apr 25, 2013 at 12:07 PM, Tony Parisi wrote: > Hi Tom > > FWIW I'm seeing slightly more "jank" out of your canvas version than the > WebGL version. Though, they are pretty close. > > I'm on a Macbook Air using Chrome. > > Tony > > > On Thu, Apr 25, 2013 at 11:56 AM, Tom Payne wrote: > >> On 25 April 2013 20:55, Tom Payne wrote: >> >>> Texture uploads are a key source of jank, even though we limit texture >>> uploads to one per second. >>> >> >> s/second/frame/ >> >> -- >> Camptocamp SA >> Tom PAYNE >> PSE A >> CH-1015 Lausanne >> >> +41 21 619 10 13 (direct) >> +41 21 619 10 10 (centrale) >> +41 21 619 10 00 (fax) >> > > > > -- > Tony Parisi tparisi...@ > CTO at Large 415.902.8002 > Skype auradeluxe > Follow me on Twitter! http://twitter.com/auradeluxe > Read my blog at http://www.tonyparisi.com/ > Learn WebGL http://learningwebgl.com/ > > Read my book! *WebGL, Up and Running* > http://shop.oreilly.com/product/0636920024729.do > http://www.amazon.com/dp/144932357X > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Thu Apr 25 13:59:03 2013 From: kbr...@ (Kenneth Russell) Date: Thu, 25 Apr 2013 13:59:03 -0700 Subject: [Public WebGL] WebGL API request: asynchronous texture uploads In-Reply-To: References: Message-ID: On Thu, Apr 25, 2013 at 1:40 PM, Ben Vanik wrote: > Gregg, I still am not sure how WebGL in workers helps with removing > jankiness caused by long/many texture uploads. It doesn't matter what thread > is driving the drawing - it *must* run under 16ms, or animations will skip. > Can you explain how you see it helping? > > I still see a strong need for async texture upload and async read pixels. > The only way of removing the need for those APIs, as I see it, is resource > sharing between multiple contexts operating in separate threads. That'd be > awesome, too, but would require a significant amount more work for a > developer to get going than a simple readPixelsAsync call and is a pretty > disappointing answer to the problem. Sorry for jumping in here, but I disagree with the statement that the general solution of WebGL in workers plus resource sharing is a "pretty disappointing answer to the problem". It would be disappointing if every expensive operation in WebGL -- shader compilation, texture uploads, pixel readback, ... -- required a new, specialized, asynchronous API. With the infrastructure work Gregg has already done spec'ing out resource sharing and WebGL in workers, as well as implementing them in Chrome, we're close to seeing prototypes in action. Let's complete this effort and see how well it works in practice. -Ken > On Thu, Apr 25, 2013 at 12:07 PM, Tony Parisi wrote: >> >> Hi Tom >> >> FWIW I'm seeing slightly more "jank" out of your canvas version than the >> WebGL version. Though, they are pretty close. >> >> I'm on a Macbook Air using Chrome. >> >> Tony >> >> >> On Thu, Apr 25, 2013 at 11:56 AM, Tom Payne >> wrote: >>> >>> On 25 April 2013 20:55, Tom Payne wrote: >>>> >>>> Texture uploads are a key source of jank, even though we limit texture >>>> uploads to one per second. >>> >>> >>> s/second/frame/ >>> >>> -- >>> Camptocamp SA >>> Tom PAYNE >>> PSE A >>> CH-1015 Lausanne >>> >>> +41 21 619 10 13 (direct) >>> +41 21 619 10 10 (centrale) >>> +41 21 619 10 00 (fax) >> >> >> >> >> -- >> Tony Parisi tparisi...@ >> CTO at Large 415.902.8002 >> Skype auradeluxe >> Follow me on Twitter! http://twitter.com/auradeluxe >> Read my blog at http://www.tonyparisi.com/ >> Learn WebGL http://learningwebgl.com/ >> >> Read my book! WebGL, Up and Running >> http://shop.oreilly.com/product/0636920024729.do >> http://www.amazon.com/dp/144932357X >> > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From ben...@ Thu Apr 25 14:44:53 2013 From: ben...@ (Ben Vanik) Date: Thu, 25 Apr 2013 14:44:53 -0700 Subject: [Public WebGL] WebGL API request: asynchronous texture uploads In-Reply-To: References: Message-ID: Ah, sorry, bad wording - not exactly what I meant. It's 'disappointing' --- in my opinion --- that the 'right way' (the way that leads to the best user experience of no jank/etc) of doing something requires so much work. That if a developer working in WebGL asked 'how do I make this perform better?' the answer is 'spend days or weeks or months rearchitecting your code' instead of 'change this one line that is good enough for 90% of all cases'. See Jeff Atwood's great article on 'falling into the pit of success': http://www.codinghorror.com/blog/2007/08/falling-into-the-pit-of-success.html . Making the easy way the least performant and most likely to cause issues and then requiring a non-trivial amount of work to do it right is just encouraging a proliferation of bad experiences that negatively reflects on the developers, the browser, and WebGL. That is what I mean by 'disappointing'. Believe me, I want off thread WebGL and resource sharing and am excited to see it land -- but I (and the software I work on) represent a small minority of web developers. Most people using threejs, impact, flash-like js libraries, emscripten, etc and will not be able to easily make use of these new systems as they would a much more accessible API. Nor would they spend the time to learn about the intricacies of Web Workers or transferrable arrays (which still aren't supported in FF) or shared contexts or cross-thread frame buffer flipping or triple buffering of resources or whatever. I know about this stuff, you know about this stuff, but I believe most people don't and shouldn't have to unless absolutely required. And of course there's great possibility with the currently APIs to implement better handling under the covers. For example, texture/buffer uploads that are not used in the same frame could be rescheduled by the browser for decode/upload/copying/etc. Or copy-on-write memory could also be used to prevent the need for most copies in well written code. Throw in better caching of programs, better pixel pipelines to reduce software overhead of texture processing, etc. All help and require no changes. ... BUT as a software developer trying to ship applications, this is scary: every browser will behave differently and it would be *impossible* to build a robust piece of software that performed well everywhere. Just look at the disparity in numbers for canvas to webgl uploads via texImage2D today, and how much slower it still is than it needs to be. I'd be disappointed if the answer forevermore is to require every developer of WebGL to measure every operation they use on every browser on every platform every time they change something to know if their application will run at 5fps or 50. So, again - I didn't mean to disparage the off-thread work - I just don't see how it helps the issue that is the topic of this thread (and one I've been struggling with for years in all platforms, not just WebGL). And because of that, I'd like to see discussion about adding APIs that ensure that browser implementers can expose and developers can consume WebGL functionality in the best way possible with the least chance of failure. I'd like to at least be reasonable convinced that this way is the 'right' way before wasting months or years waiting for this to be fully baked in all browsers and rewriting all of my code and finding out that it just doesn't work. On Thu, Apr 25, 2013 at 1:59 PM, Kenneth Russell wrote: > On Thu, Apr 25, 2013 at 1:40 PM, Ben Vanik wrote: > > Gregg, I still am not sure how WebGL in workers helps with removing > > jankiness caused by long/many texture uploads. It doesn't matter what > thread > > is driving the drawing - it *must* run under 16ms, or animations will > skip. > > Can you explain how you see it helping? > > > > I still see a strong need for async texture upload and async read pixels. > > The only way of removing the need for those APIs, as I see it, is > resource > > sharing between multiple contexts operating in separate threads. That'd > be > > awesome, too, but would require a significant amount more work for a > > developer to get going than a simple readPixelsAsync call and is a pretty > > disappointing answer to the problem. > > Sorry for jumping in here, but I disagree with the statement that the > general solution of WebGL in workers plus resource sharing is a > "pretty disappointing answer to the problem". > > It would be disappointing if every expensive operation in WebGL -- > shader compilation, texture uploads, pixel readback, ... -- required a > new, specialized, asynchronous API. With the infrastructure work Gregg > has already done spec'ing out resource sharing and WebGL in workers, > as well as implementing them in Chrome, we're close to seeing > prototypes in action. Let's complete this effort and see how well it > works in practice. > > -Ken > > > > On Thu, Apr 25, 2013 at 12:07 PM, Tony Parisi wrote: > >> > >> Hi Tom > >> > >> FWIW I'm seeing slightly more "jank" out of your canvas version than the > >> WebGL version. Though, they are pretty close. > >> > >> I'm on a Macbook Air using Chrome. > >> > >> Tony > >> > >> > >> On Thu, Apr 25, 2013 at 11:56 AM, Tom Payne > >> wrote: > >>> > >>> On 25 April 2013 20:55, Tom Payne wrote: > >>>> > >>>> Texture uploads are a key source of jank, even though we limit > texture > >>>> uploads to one per second. > >>> > >>> > >>> s/second/frame/ > >>> > >>> -- > >>> Camptocamp SA > >>> Tom PAYNE > >>> PSE A > >>> CH-1015 Lausanne > >>> > >>> +41 21 619 10 13 (direct) > >>> +41 21 619 10 10 (centrale) > >>> +41 21 619 10 00 (fax) > >> > >> > >> > >> > >> -- > >> Tony Parisi tparisi...@ > >> CTO at Large 415.902.8002 > >> Skype auradeluxe > >> Follow me on Twitter! http://twitter.com/auradeluxe > >> Read my blog at http://www.tonyparisi.com/ > >> Learn WebGL http://learningwebgl.com/ > >> > >> Read my book! WebGL, Up and Running > >> http://shop.oreilly.com/product/0636920024729.do > >> http://www.amazon.com/dp/144932357X > >> > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Thu Apr 25 15:10:01 2013 From: jgi...@ (Jeff Gilbert) Date: Thu, 25 Apr 2013 15:10:01 -0700 (PDT) Subject: [Public WebGL] 2d canvas context to WebGL In-Reply-To: Message-ID: <832327574.2396275.1366927801326.JavaMail.root@mozilla.com> Firefox does not currently optimize canvas->canvas transfers, though we would like to implement this optimization in the future. We definitely readback and re-upload for texImage2D(. -Jeff ----- Original Message ----- From: "Kenneth Russell" To: "Rik Cabanier" Cc: "Benoit Jacob" , "public webgl" Sent: Thursday, April 25, 2013 1:31:07 PM Subject: Re: [Public WebGL] 2d canvas context to WebGL Please file a bug with a self-contained test case. Exposing these issues is the only way they are going to be fixed. -Ken On Thu, Apr 25, 2013 at 1:26 PM, Rik Cabanier wrote: > One of our frameworks draws into a 2d canvas, transfers it to WebGL, runs a > shader and then brings the result back. > Just copying a 500x500 canvas to and from WebGL takes: > > - 16ms on Chrome > - 14ms on Firefox > - 40ms on Safari > > > This is way to slow to make fluid animations such as this one: > http://ads2.msads.net/CIS/48/000/000/000/039/337.swf?fd=www.msn.com (sorry > for the flash movie). If you look closely, you will see that the text is > blurred during the animation. > In most (all?) implementations, the canvas bits were already on the GPU so > this time *could* be brought down to zero. > > Safari is twice as bad as chrome and Firefox. This is probably caused by the > optimizations you mentioned. > > The bug you mentioned is because of synchronous readback, Ideally there > would be no readback at all :-) > > On Wed, Apr 24, 2013 at 2:07 PM, Kenneth Russell wrote: >> >> There is definitely code in Chrome to make Canvas -> WebGL uploads >> efficient (as well as the reverse direction), but I believe there are >> still some slow paths. See >> https://code.google.com/p/chromium/issues/detail?id=233205 for >> example. I don't know how much of this made it in to Safari. >> >> >> >> On Wed, Apr 24, 2013 at 1:59 PM, Rik Cabanier wrote: >> > Great! >> > So Safari and Chrome implement this efficiently? Also is this documented >> > somewhere? >> > >> > >> > On Wed, Apr 24, 2013 at 1:47 PM, Benoit Jacob >> > wrote: >> >> >> >> >> >> A 2D canvas can be passed directly to WebGL texImage2D. >> >> >> >> This happens to be slow in Firefox at the moment (the canvas is >> >> currently read back and re-uploaded), but that could probably be fixed >> >> if there is real-world pressure in that direction. >> >> >> >> Benoit >> >> >> >> On 13-04-24 04:23 PM, Rik Cabanier wrote: >> >> > All, >> >> > >> >> > Sorry if this is already documented but is there a way to efficiently >> >> > use a 2d canvas context in WebGL? >> >> > We've seen cases where people want to apply effects on 2d contexts >> >> > and >> >> > they're doing this by copying the 2d canvas to a buffer, running a >> >> > shader on it and getting the result back. >> >> > This is an expensive workflow both in time and memory. >> >> > >> >> > Since the 2d canvas is already on the GPU (on most browsers), is >> >> > there >> >> > a way to directly access it from WebGL? >> >> > >> >> > Thanks! >> >> >> >> >> >> ----------------------------------------------------------- >> >> You are currently subscribed to public_webgl...@ >> >> To unsubscribe, send an email to majordomo...@ with >> >> the following command in the body of your email: >> >> unsubscribe public_webgl >> >> ----------------------------------------------------------- >> >> >> > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From cab...@ Thu Apr 25 16:09:52 2013 From: cab...@ (Rik Cabanier) Date: Thu, 25 Apr 2013 16:09:52 -0700 Subject: [Public WebGL] 2d canvas context to WebGL In-Reply-To: <832327574.2396275.1366927801326.JavaMail.root@mozilla.com> References: <832327574.2396275.1366927801326.JavaMail.root@mozilla.com> Message-ID: Do you also not optimize drawImage with a WebGL canvas? On Thu, Apr 25, 2013 at 3:10 PM, Jeff Gilbert wrote: > Firefox does not currently optimize canvas->canvas transfers, though we > would like to implement this optimization in the future. We definitely > readback and re-upload for texImage2D(. > > -Jeff > > ----- Original Message ----- > From: "Kenneth Russell" > To: "Rik Cabanier" > Cc: "Benoit Jacob" , "public webgl" < > public_webgl...@> > Sent: Thursday, April 25, 2013 1:31:07 PM > Subject: Re: [Public WebGL] 2d canvas context to WebGL > > > Please file a bug with a self-contained test case. Exposing these > issues is the only way they are going to be fixed. > > -Ken > > > On Thu, Apr 25, 2013 at 1:26 PM, Rik Cabanier wrote: > > One of our frameworks draws into a 2d canvas, transfers it to WebGL, > runs a > > shader and then brings the result back. > > Just copying a 500x500 canvas to and from WebGL takes: > > > > - 16ms on Chrome > > - 14ms on Firefox > > - 40ms on Safari > > > > > > This is way to slow to make fluid animations such as this one: > > http://ads2.msads.net/CIS/48/000/000/000/039/337.swf?fd=www.msn.com(sorry > > for the flash movie). If you look closely, you will see that the text is > > blurred during the animation. > > In most (all?) implementations, the canvas bits were already on the GPU > so > > this time *could* be brought down to zero. > > > > Safari is twice as bad as chrome and Firefox. This is probably caused by > the > > optimizations you mentioned. > > > > The bug you mentioned is because of synchronous readback, Ideally there > > would be no readback at all :-) > > > > On Wed, Apr 24, 2013 at 2:07 PM, Kenneth Russell wrote: > >> > >> There is definitely code in Chrome to make Canvas -> WebGL uploads > >> efficient (as well as the reverse direction), but I believe there are > >> still some slow paths. See > >> https://code.google.com/p/chromium/issues/detail?id=233205 for > >> example. I don't know how much of this made it in to Safari. > >> > >> > >> > >> On Wed, Apr 24, 2013 at 1:59 PM, Rik Cabanier > wrote: > >> > Great! > >> > So Safari and Chrome implement this efficiently? Also is this > documented > >> > somewhere? > >> > > >> > > >> > On Wed, Apr 24, 2013 at 1:47 PM, Benoit Jacob > >> > wrote: > >> >> > >> >> > >> >> A 2D canvas can be passed directly to WebGL texImage2D. > >> >> > >> >> This happens to be slow in Firefox at the moment (the canvas is > >> >> currently read back and re-uploaded), but that could probably be > fixed > >> >> if there is real-world pressure in that direction. > >> >> > >> >> Benoit > >> >> > >> >> On 13-04-24 04:23 PM, Rik Cabanier wrote: > >> >> > All, > >> >> > > >> >> > Sorry if this is already documented but is there a way to > efficiently > >> >> > use a 2d canvas context in WebGL? > >> >> > We've seen cases where people want to apply effects on 2d contexts > >> >> > and > >> >> > they're doing this by copying the 2d canvas to a buffer, running a > >> >> > shader on it and getting the result back. > >> >> > This is an expensive workflow both in time and memory. > >> >> > > >> >> > Since the 2d canvas is already on the GPU (on most browsers), is > >> >> > there > >> >> > a way to directly access it from WebGL? > >> >> > > >> >> > Thanks! > >> >> > >> >> > >> >> ----------------------------------------------------------- > >> >> You are currently subscribed to public_webgl...@ > >> >> To unsubscribe, send an email to majordomo...@ with > >> >> the following command in the body of your email: > >> >> unsubscribe public_webgl > >> >> ----------------------------------------------------------- > >> >> > >> > > > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Thu Apr 25 16:14:04 2013 From: jgi...@ (Jeff Gilbert) Date: Thu, 25 Apr 2013 16:14:04 -0700 (PDT) Subject: [Public WebGL] 2d canvas context to WebGL In-Reply-To: Message-ID: <546008185.2405756.1366931644913.JavaMail.root@mozilla.com> I don't believe Firefox does, no. -Jeff ----- Original Message ----- From: "Rik Cabanier" To: "Jeff Gilbert" Cc: "Kenneth Russell" , "Benoit Jacob" , "public webgl" Sent: Thursday, April 25, 2013 4:09:52 PM Subject: Re: [Public WebGL] 2d canvas context to WebGL Do you also not optimize drawImage with a WebGL canvas? On Thu, Apr 25, 2013 at 3:10 PM, Jeff Gilbert < jgilbert...@ > wrote: Firefox does not currently optimize canvas->canvas transfers, though we would like to implement this optimization in the future. We definitely readback and re-upload for texImage2D(. -Jeff ----- Original Message ----- From: "Kenneth Russell" < kbr...@ > To: "Rik Cabanier" < cabanier...@ > Cc: "Benoit Jacob" < bjacob...@ >, "public webgl" < public_webgl...@ > Sent: Thursday, April 25, 2013 1:31:07 PM Subject: Re: [Public WebGL] 2d canvas context to WebGL Please file a bug with a self-contained test case. Exposing these issues is the only way they are going to be fixed. -Ken On Thu, Apr 25, 2013 at 1:26 PM, Rik Cabanier < cabanier...@ > wrote: > One of our frameworks draws into a 2d canvas, transfers it to WebGL, runs a > shader and then brings the result back. > Just copying a 500x500 canvas to and from WebGL takes: > > - 16ms on Chrome > - 14ms on Firefox > - 40ms on Safari > > > This is way to slow to make fluid animations such as this one: > http://ads2.msads.net/CIS/48/000/000/000/039/337.swf?fd=www.msn.com (sorry > for the flash movie). If you look closely, you will see that the text is > blurred during the animation. > In most (all?) implementations, the canvas bits were already on the GPU so > this time *could* be brought down to zero. > > Safari is twice as bad as chrome and Firefox. This is probably caused by the > optimizations you mentioned. > > The bug you mentioned is because of synchronous readback, Ideally there > would be no readback at all :-) > > On Wed, Apr 24, 2013 at 2:07 PM, Kenneth Russell < kbr...@ > wrote: >> >> There is definitely code in Chrome to make Canvas -> WebGL uploads >> efficient (as well as the reverse direction), but I believe there are >> still some slow paths. See >> https://code.google.com/p/chromium/issues/detail?id=233205 for >> example. I don't know how much of this made it in to Safari. >> >> >> >> On Wed, Apr 24, 2013 at 1:59 PM, Rik Cabanier < cabanier...@ > wrote: >> > Great! >> > So Safari and Chrome implement this efficiently? Also is this documented >> > somewhere? >> > >> > >> > On Wed, Apr 24, 2013 at 1:47 PM, Benoit Jacob < bjacob...@ > >> > wrote: >> >> >> >> >> >> A 2D canvas can be passed directly to WebGL texImage2D. >> >> >> >> This happens to be slow in Firefox at the moment (the canvas is >> >> currently read back and re-uploaded), but that could probably be fixed >> >> if there is real-world pressure in that direction. >> >> >> >> Benoit >> >> >> >> On 13-04-24 04:23 PM, Rik Cabanier wrote: >> >> > All, >> >> > >> >> > Sorry if this is already documented but is there a way to efficiently >> >> > use a 2d canvas context in WebGL? >> >> > We've seen cases where people want to apply effects on 2d contexts >> >> > and >> >> > they're doing this by copying the 2d canvas to a buffer, running a >> >> > shader on it and getting the result back. >> >> > This is an expensive workflow both in time and memory. >> >> > >> >> > Since the 2d canvas is already on the GPU (on most browsers), is >> >> > there >> >> > a way to directly access it from WebGL? >> >> > >> >> > Thanks! >> >> >> >> >> >> ----------------------------------------------------------- >> >> You are currently subscribed to public_webgl...@ . >> >> To unsubscribe, send an email to majordomo...@ with >> >> the following command in the body of your email: >> >> unsubscribe public_webgl >> >> ----------------------------------------------------------- >> >> >> > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ . To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From gma...@ Thu Apr 25 17:07:08 2013 From: gma...@ (Gregg Tavares) Date: Thu, 25 Apr 2013 17:07:08 -0700 Subject: [Public WebGL] WebGL API request: asynchronous texture uploads In-Reply-To: References: Message-ID: On Thu, Apr 25, 2013 at 2:44 PM, Ben Vanik wrote: > Ah, sorry, bad wording - not exactly what I meant. > > It's 'disappointing' --- in my opinion --- that the 'right way' (the way > that leads to the best user experience of no jank/etc) of doing something > requires so much work. That if a developer working in WebGL asked 'how do I > make this perform better?' the answer is 'spend days or weeks or months > rearchitecting your code' instead of 'change this one line that is good > enough for 90% of all cases'. > See Jeff Atwood's great article on 'falling into the pit of success': > http://www.codinghorror.com/blog/2007/08/falling-into-the-pit-of-success.html > . > Making the easy way the least performant and most likely to cause issues > and then requiring a non-trivial amount of work to do it right is just > encouraging a proliferation of bad experiences that negatively reflects on > the developers, the browser, and WebGL. That is what I mean by > 'disappointing'. > > Believe me, I want off thread WebGL and resource sharing and am excited to > see it land -- but I (and the software I work on) represent a small > minority of web developers. Most people using threejs, impact, flash-like > js libraries, emscripten, etc and will not be able to easily make use of > these new systems as they would a much more accessible API. > Really? I'd expect that three.js, impact, flash-like js libraries would add add support and magically all users would get these features. Certainly for texture uploads this is the case and pretty much every library expects textures to happen async so the library can download the image and upload it async using a worker and only after call the user's callback back in the main thread. The three.js user doesn't have to change a thing. For shaders/programs they are not async now but I'd guess a library like three.js would just add its own simple async functions so these are easy for the user. > Nor would they spend the time to learn about the intricacies of Web > Workers or transferrable arrays (which still aren't supported in FF) or > shared contexts or cross-thread frame buffer flipping or triple buffering > of resources or whatever. I know about this stuff, you know about this > stuff, but I believe most people don't and shouldn't have to unless > absolutely required. > By this argument we should get rid of WebGL because "most developers" will never figure out the intricacies of 3d math, lighting equations, shader generation, projection matrices. Instead we should just build X3D into the browser (please NO!) The reason to expose low level APIs is because we can't know everything people want to do and what will meet there needs. It's much better IMO to provide the low-level features and a few simple libraries to use them than hard code the high level solution thereby preventing 1000s of use cases because our high level solution didn't meet other people's needs. Maybe I'd like to load .WAD files (or similar) rather than just images but if we just add async load image and no worker support too bad for that. > > And of course there's great possibility with the currently APIs to > implement better handling under the covers. For example, texture/buffer > uploads that are not used in the same frame could be rescheduled by the > browser for decode/upload/copying/etc. Or copy-on-write memory could also > be used to prevent the need for most copies in well written code. Throw in > better caching of programs, better pixel pipelines to reduce software > overhead of texture processing, etc. All help and require no changes. > ... > BUT as a software developer trying to ship applications, this is scary: > every browser will behave differently and it would be *impossible* to build > a robust piece of software that performed well everywhere. Just look at the > disparity in numbers for canvas to webgl uploads via texImage2D today, and > how much slower it still is than it needs to be. I'd be disappointed if the > answer forevermore is to require every developer of WebGL to measure every > operation they use on every browser on every platform every time they > change something to know if their application will run at 5fps or 50. > I don't see how specing async APIs changes this. Any browser can chose not to implement some of the APIs. They can also implement them poorly. Workers or async APIs isn't the issue there. > > So, again - I didn't mean to disparage the off-thread work - I just don't > see how it helps the issue that is the topic of this thread (and one I've > been struggling with for years in all platforms, not just WebGL). > And because of that, I'd like to see discussion about adding APIs that > ensure that browser implementers can expose and developers can consume > WebGL functionality in the best way possible with the least chance of > failure. I'd like to at least be reasonable convinced that this way is the > 'right' way before wasting months or years waiting for this to be fully > baked in all browsers and rewriting all of my code and finding out that it > just doesn't work. > > > > On Thu, Apr 25, 2013 at 1:59 PM, Kenneth Russell wrote: > >> On Thu, Apr 25, 2013 at 1:40 PM, Ben Vanik wrote: >> > Gregg, I still am not sure how WebGL in workers helps with removing >> > jankiness caused by long/many texture uploads. It doesn't matter what >> thread >> > is driving the drawing - it *must* run under 16ms, or animations will >> skip. >> > Can you explain how you see it helping? >> > >> > I still see a strong need for async texture upload and async read >> pixels. >> > The only way of removing the need for those APIs, as I see it, is >> resource >> > sharing between multiple contexts operating in separate threads. That'd >> be >> > awesome, too, but would require a significant amount more work for a >> > developer to get going than a simple readPixelsAsync call and is a >> pretty >> > disappointing answer to the problem. >> >> Sorry for jumping in here, but I disagree with the statement that the >> general solution of WebGL in workers plus resource sharing is a >> "pretty disappointing answer to the problem". >> >> It would be disappointing if every expensive operation in WebGL -- >> shader compilation, texture uploads, pixel readback, ... -- required a >> new, specialized, asynchronous API. With the infrastructure work Gregg >> has already done spec'ing out resource sharing and WebGL in workers, >> as well as implementing them in Chrome, we're close to seeing >> prototypes in action. Let's complete this effort and see how well it >> works in practice. >> >> -Ken >> >> >> > On Thu, Apr 25, 2013 at 12:07 PM, Tony Parisi >> wrote: >> >> >> >> Hi Tom >> >> >> >> FWIW I'm seeing slightly more "jank" out of your canvas version than >> the >> >> WebGL version. Though, they are pretty close. >> >> >> >> I'm on a Macbook Air using Chrome. >> >> >> >> Tony >> >> >> >> >> >> On Thu, Apr 25, 2013 at 11:56 AM, Tom Payne >> >> wrote: >> >>> >> >>> On 25 April 2013 20:55, Tom Payne wrote: >> >>>> >> >>>> Texture uploads are a key source of jank, even though we limit >> texture >> >>>> uploads to one per second. >> >>> >> >>> >> >>> s/second/frame/ >> >>> >> >>> -- >> >>> Camptocamp SA >> >>> Tom PAYNE >> >>> PSE A >> >>> CH-1015 Lausanne >> >>> >> >>> +41 21 619 10 13 (direct) >> >>> +41 21 619 10 10 (centrale) >> >>> +41 21 619 10 00 (fax) >> >> >> >> >> >> >> >> >> >> -- >> >> Tony Parisi tparisi...@ >> >> CTO at Large 415.902.8002 >> >> Skype auradeluxe >> >> Follow me on Twitter! http://twitter.com/auradeluxe >> >> Read my blog at http://www.tonyparisi.com/ >> >> Learn WebGL http://learningwebgl.com/ >> >> >> >> Read my book! WebGL, Up and Running >> >> http://shop.oreilly.com/product/0636920024729.do >> >> http://www.amazon.com/dp/144932357X >> >> >> > >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cab...@ Thu Apr 25 21:09:28 2013 From: cab...@ (Rik Cabanier) Date: Thu, 25 Apr 2013 21:09:28 -0700 Subject: [Public WebGL] 2d canvas context to WebGL In-Reply-To: <546008185.2405756.1366931644913.JavaMail.root@mozilla.com> References: <546008185.2405756.1366931644913.JavaMail.root@mozilla.com> Message-ID: Should I log bugs against mozilla too? (It's a bit strange since there's nothing wrong per se) On Thu, Apr 25, 2013 at 4:14 PM, Jeff Gilbert wrote: > I don't believe Firefox does, no. > > -Jeff > > ----- Original Message ----- > From: "Rik Cabanier" > To: "Jeff Gilbert" > Cc: "Kenneth Russell" , "Benoit Jacob" , > "public webgl" > Sent: Thursday, April 25, 2013 4:09:52 PM > Subject: Re: [Public WebGL] 2d canvas context to WebGL > > Do you also not optimize drawImage with a WebGL canvas? > > > On Thu, Apr 25, 2013 at 3:10 PM, Jeff Gilbert < jgilbert...@ > > wrote: > > > Firefox does not currently optimize canvas->canvas transfers, though we > would like to implement this optimization in the future. We definitely > readback and re-upload for texImage2D(. > > -Jeff > > > > ----- Original Message ----- > From: "Kenneth Russell" < kbr...@ > > To: "Rik Cabanier" < cabanier...@ > > Cc: "Benoit Jacob" < bjacob...@ >, "public webgl" < > public_webgl...@ > > Sent: Thursday, April 25, 2013 1:31:07 PM > Subject: Re: [Public WebGL] 2d canvas context to WebGL > > > Please file a bug with a self-contained test case. Exposing these > issues is the only way they are going to be fixed. > > -Ken > > > On Thu, Apr 25, 2013 at 1:26 PM, Rik Cabanier < cabanier...@ > > wrote: > > One of our frameworks draws into a 2d canvas, transfers it to WebGL, > runs a > > shader and then brings the result back. > > Just copying a 500x500 canvas to and from WebGL takes: > > > > - 16ms on Chrome > > - 14ms on Firefox > > - 40ms on Safari > > > > > > This is way to slow to make fluid animations such as this one: > > http://ads2.msads.net/CIS/48/000/000/000/039/337.swf?fd=www.msn.com(sorry > > for the flash movie). If you look closely, you will see that the text is > > blurred during the animation. > > In most (all?) implementations, the canvas bits were already on the GPU > so > > this time *could* be brought down to zero. > > > > Safari is twice as bad as chrome and Firefox. This is probably caused by > the > > optimizations you mentioned. > > > > The bug you mentioned is because of synchronous readback, Ideally there > > would be no readback at all :-) > > > > On Wed, Apr 24, 2013 at 2:07 PM, Kenneth Russell < kbr...@ > > wrote: > >> > >> There is definitely code in Chrome to make Canvas -> WebGL uploads > >> efficient (as well as the reverse direction), but I believe there are > >> still some slow paths. See > >> https://code.google.com/p/chromium/issues/detail?id=233205 for > >> example. I don't know how much of this made it in to Safari. > >> > >> > >> > >> On Wed, Apr 24, 2013 at 1:59 PM, Rik Cabanier < cabanier...@ > > wrote: > >> > Great! > >> > So Safari and Chrome implement this efficiently? Also is this > documented > >> > somewhere? > >> > > >> > > >> > On Wed, Apr 24, 2013 at 1:47 PM, Benoit Jacob < bjacob...@ > > >> > wrote: > >> >> > >> >> > >> >> A 2D canvas can be passed directly to WebGL texImage2D. > >> >> > >> >> This happens to be slow in Firefox at the moment (the canvas is > >> >> currently read back and re-uploaded), but that could probably be > fixed > >> >> if there is real-world pressure in that direction. > >> >> > >> >> Benoit > >> >> > >> >> On 13-04-24 04:23 PM, Rik Cabanier wrote: > >> >> > All, > >> >> > > >> >> > Sorry if this is already documented but is there a way to > efficiently > >> >> > use a 2d canvas context in WebGL? > >> >> > We've seen cases where people want to apply effects on 2d contexts > >> >> > and > >> >> > they're doing this by copying the 2d canvas to a buffer, running a > >> >> > shader on it and getting the result back. > >> >> > This is an expensive workflow both in time and memory. > >> >> > > >> >> > Since the 2d canvas is already on the GPU (on most browsers), is > >> >> > there > >> >> > a way to directly access it from WebGL? > >> >> > > >> >> > Thanks! > >> >> > >> >> > >> >> ----------------------------------------------------------- > >> >> You are currently subscribed to public_webgl...@ . > >> >> To unsubscribe, send an email to majordomo...@ with > >> >> the following command in the body of your email: > >> >> unsubscribe public_webgl > >> >> ----------------------------------------------------------- > >> >> > >> > > > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ . > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jgi...@ Thu Apr 25 21:22:55 2013 From: jgi...@ (Jeff Gilbert) Date: Thu, 25 Apr 2013 21:22:55 -0700 (PDT) Subject: [Public WebGL] 2d canvas context to WebGL In-Reply-To: Message-ID: <1423519292.2437417.1366950175426.JavaMail.root@mozilla.com> Sure! It's on my list of Things To Fix, but it will need to have a bug filed sooner or later. Please email me when you create it. (Or just CC me on the bug) -Jeff ----- Original Message ----- From: "Rik Cabanier" To: "Jeff Gilbert" Cc: "Kenneth Russell" , "Benoit Jacob" , "public webgl" Sent: Thursday, April 25, 2013 9:09:28 PM Subject: Re: [Public WebGL] 2d canvas context to WebGL Should I log bugs against mozilla too? (It's a bit strange since there's nothing wrong per se) On Thu, Apr 25, 2013 at 4:14 PM, Jeff Gilbert < jgilbert...@ > wrote: I don't believe Firefox does, no. -Jeff ----- Original Message ----- From: "Rik Cabanier" < cabanier...@ > To: "Jeff Gilbert" < jgilbert...@ > Cc: "Kenneth Russell" < kbr...@ >, "Benoit Jacob" < bjacob...@ >, "public webgl" < public_webgl...@ > Sent: Thursday, April 25, 2013 4:09:52 PM Subject: Re: [Public WebGL] 2d canvas context to WebGL Do you also not optimize drawImage with a WebGL canvas? On Thu, Apr 25, 2013 at 3:10 PM, Jeff Gilbert < jgilbert...@ > wrote: Firefox does not currently optimize canvas->canvas transfers, though we would like to implement this optimization in the future. We definitely readback and re-upload for texImage2D(. -Jeff ----- Original Message ----- From: "Kenneth Russell" < kbr...@ > To: "Rik Cabanier" < cabanier...@ > Cc: "Benoit Jacob" < bjacob...@ >, "public webgl" < public_webgl...@ > Sent: Thursday, April 25, 2013 1:31:07 PM Subject: Re: [Public WebGL] 2d canvas context to WebGL Please file a bug with a self-contained test case. Exposing these issues is the only way they are going to be fixed. -Ken On Thu, Apr 25, 2013 at 1:26 PM, Rik Cabanier < cabanier...@ > wrote: > One of our frameworks draws into a 2d canvas, transfers it to WebGL, runs a > shader and then brings the result back. > Just copying a 500x500 canvas to and from WebGL takes: > > - 16ms on Chrome > - 14ms on Firefox > - 40ms on Safari > > > This is way to slow to make fluid animations such as this one: > http://ads2.msads.net/CIS/48/000/000/000/039/337.swf?fd=www.msn.com (sorry > for the flash movie). If you look closely, you will see that the text is > blurred during the animation. > In most (all?) implementations, the canvas bits were already on the GPU so > this time *could* be brought down to zero. > > Safari is twice as bad as chrome and Firefox. This is probably caused by the > optimizations you mentioned. > > The bug you mentioned is because of synchronous readback, Ideally there > would be no readback at all :-) > > On Wed, Apr 24, 2013 at 2:07 PM, Kenneth Russell < kbr...@ > wrote: >> >> There is definitely code in Chrome to make Canvas -> WebGL uploads >> efficient (as well as the reverse direction), but I believe there are >> still some slow paths. See >> https://code.google.com/p/chromium/issues/detail?id=233205 for >> example. I don't know how much of this made it in to Safari. >> >> >> >> On Wed, Apr 24, 2013 at 1:59 PM, Rik Cabanier < cabanier...@ > wrote: >> > Great! >> > So Safari and Chrome implement this efficiently? Also is this documented >> > somewhere? >> > >> > >> > On Wed, Apr 24, 2013 at 1:47 PM, Benoit Jacob < bjacob...@ > >> > wrote: >> >> >> >> >> >> A 2D canvas can be passed directly to WebGL texImage2D. >> >> >> >> This happens to be slow in Firefox at the moment (the canvas is >> >> currently read back and re-uploaded), but that could probably be fixed >> >> if there is real-world pressure in that direction. >> >> >> >> Benoit >> >> >> >> On 13-04-24 04:23 PM, Rik Cabanier wrote: >> >> > All, >> >> > >> >> > Sorry if this is already documented but is there a way to efficiently >> >> > use a 2d canvas context in WebGL? >> >> > We've seen cases where people want to apply effects on 2d contexts >> >> > and >> >> > they're doing this by copying the 2d canvas to a buffer, running a >> >> > shader on it and getting the result back. >> >> > This is an expensive workflow both in time and memory. >> >> > >> >> > Since the 2d canvas is already on the GPU (on most browsers), is >> >> > there >> >> > a way to directly access it from WebGL? >> >> > >> >> > Thanks! >> >> >> >> >> >> ----------------------------------------------------------- >> >> You are currently subscribed to public_webgl...@ . >> >> To unsubscribe, send an email to majordomo...@ with >> >> the following command in the body of your email: >> >> unsubscribe public_webgl >> >> ----------------------------------------------------------- >> >> >> > > > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ . To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From kan...@ Thu Apr 25 23:18:52 2013 From: kan...@ (Kang-Hao (Kenny) Lu) Date: Fri, 26 Apr 2013 14:18:52 +0800 Subject: [Public WebGL] 2d canvas context to WebGL In-Reply-To: <1423519292.2437417.1366950175426.JavaMail.root@mozilla.com> References: <1423519292.2437417.1366950175426.JavaMail.root@mozilla.com> Message-ID: <517A1C4C.5090308@oupeng.com> It would be nice if you share the bug number with the list too! (13/04/26 12:22), Jeff Gilbert wrote: > > Sure! It's on my list of Things To Fix, but it will need to have a bug filed sooner or later. > > Please email me when you create it. (Or just CC me on the bug) > > -Jeff > > ----- Original Message ----- > From: "Rik Cabanier" > To: "Jeff Gilbert" > Cc: "Kenneth Russell" , "Benoit Jacob" , "public webgl" > Sent: Thursday, April 25, 2013 9:09:28 PM > Subject: Re: [Public WebGL] 2d canvas context to WebGL > > Should I log bugs against mozilla too? (It's a bit strange since there's nothing wrong per se) > > > > On Thu, Apr 25, 2013 at 4:14 PM, Jeff Gilbert < jgilbert...@ > wrote: > > > I don't believe Firefox does, no. > > > -Jeff > > ----- Original Message ----- > > > From: "Rik Cabanier" < cabanier...@ > > To: "Jeff Gilbert" < jgilbert...@ > > Cc: "Kenneth Russell" < kbr...@ >, "Benoit Jacob" < bjacob...@ >, "public webgl" < public_webgl...@ > > Sent: Thursday, April 25, 2013 4:09:52 PM > Subject: Re: [Public WebGL] 2d canvas context to WebGL > > Do you also not optimize drawImage with a WebGL canvas? > > > On Thu, Apr 25, 2013 at 3:10 PM, Jeff Gilbert < jgilbert...@ > wrote: > > > Firefox does not currently optimize canvas->canvas transfers, though we would like to implement this optimization in the future. We definitely readback and re-upload for texImage2D(. > > -Jeff > > > > ----- Original Message ----- > From: "Kenneth Russell" < kbr...@ > > To: "Rik Cabanier" < cabanier...@ > > Cc: "Benoit Jacob" < bjacob...@ >, "public webgl" < public_webgl...@ > > Sent: Thursday, April 25, 2013 1:31:07 PM > Subject: Re: [Public WebGL] 2d canvas context to WebGL > > > Please file a bug with a self-contained test case. Exposing these > issues is the only way they are going to be fixed. > > -Ken > > > On Thu, Apr 25, 2013 at 1:26 PM, Rik Cabanier < cabanier...@ > wrote: >> One of our frameworks draws into a 2d canvas, transfers it to WebGL, runs a >> shader and then brings the result back. >> Just copying a 500x500 canvas to and from WebGL takes: >> >> - 16ms on Chrome >> - 14ms on Firefox >> - 40ms on Safari >> >> >> This is way to slow to make fluid animations such as this one: >> http://ads2.msads.net/CIS/48/000/000/000/039/337.swf?fd=www.msn.com (sorry >> for the flash movie). If you look closely, you will see that the text is >> blurred during the animation. >> In most (all?) implementations, the canvas bits were already on the GPU so >> this time *could* be brought down to zero. >> >> Safari is twice as bad as chrome and Firefox. This is probably caused by the >> optimizations you mentioned. >> >> The bug you mentioned is because of synchronous readback, Ideally there >> would be no readback at all :-) >> >> On Wed, Apr 24, 2013 at 2:07 PM, Kenneth Russell < kbr...@ > wrote: >>> >>> There is definitely code in Chrome to make Canvas -> WebGL uploads >>> efficient (as well as the reverse direction), but I believe there are >>> still some slow paths. See >>> https://code.google.com/p/chromium/issues/detail?id=233205 for >>> example. I don't know how much of this made it in to Safari. >>> >>> >>> >>> On Wed, Apr 24, 2013 at 1:59 PM, Rik Cabanier < cabanier...@ > wrote: >>>> Great! >>>> So Safari and Chrome implement this efficiently? Also is this documented >>>> somewhere? >>>> >>>> >>>> On Wed, Apr 24, 2013 at 1:47 PM, Benoit Jacob < bjacob...@ > >>>> wrote: >>>>> >>>>> >>>>> A 2D canvas can be passed directly to WebGL texImage2D. >>>>> >>>>> This happens to be slow in Firefox at the moment (the canvas is >>>>> currently read back and re-uploaded), but that could probably be fixed >>>>> if there is real-world pressure in that direction. >>>>> >>>>> Benoit >>>>> >>>>> On 13-04-24 04:23 PM, Rik Cabanier wrote: >>>>>> All, >>>>>> >>>>>> Sorry if this is already documented but is there a way to efficiently >>>>>> use a 2d canvas context in WebGL? >>>>>> We've seen cases where people want to apply effects on 2d contexts >>>>>> and >>>>>> they're doing this by copying the 2d canvas to a buffer, running a >>>>>> shader on it and getting the result back. >>>>>> This is an expensive workflow both in time and memory. >>>>>> >>>>>> Since the 2d canvas is already on the GPU (on most browsers), is >>>>>> there >>>>>> a way to directly access it from WebGL? >>>>>> >>>>>> Thanks! >>>>> >>>>> >>>>> ----------------------------------------------------------- >>>>> You are currently subscribed to public_webgl...@ . >>>>> To unsubscribe, send an email to majordomo...@ with >>>>> the following command in the body of your email: >>>>> unsubscribe public_webgl >>>>> ----------------------------------------------------------- >>>>> >>>> >> >> > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ . > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > > > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > To unsubscribe, send an email to majordomo...@ with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > Cheers, Kenny -- Web Specialist, Opera Sphinx Game Force, Oupeng Browser, Beijing Try Oupeng: http://www.oupeng.com/ ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl ----------------------------------------------------------- From dfo...@ Fri Apr 26 08:53:34 2013 From: dfo...@ (dforce) Date: Fri, 26 Apr 2013 17:53:34 +0200 Subject: [Public WebGL] Re: Contributing to the WebGL mailing list In-Reply-To: References: <5170FFA1.2020103@jetbrains.com> <517143D3.2050403@mozilla.com> <51742DEF.8080602@artspark.co.jp> <517441AE.6030809@artspark.co.jp> Message-ID: <517AA2FE.5070908@zoho.com> asserting: gl.texImage2D with an image will be USELESS unless I can choose to load PNG files without the browser applying color correction and pre-multiplying the alpha! very good point. hopefully this will be true some time... Am 22.04.2013 23:00, schrieb Gregg Tavares: > Just to add my own 2?. > > I personally have the issue that I often say things in way that causes > offence or directly or indirectly puts the other person down. If I'm > lucky you haven't seen examples on this list but trust me I have this > problem. > > What I've noticed that helps me is (when I'm sane enough to follow my > own advice) > > 1) I don't reply immediately > > 2) If I do write a reply and manage to notice it's confrontational I > don't send it. Then re-write it tomorrow or at least several hours later. > > 3) Ask questions instead of asserting my opinion > > eg: > > asserting: gl.texImage2D with an image will be USELESS unless I can > choose to load PNG files without the browser applying color correction > and pre-multiplying the alpha! > > questioning: How would I load an normal map with height in the alpha > channel if there is no way to load a PNG file without the browser > applying color correction and pre-multiplying the alpha? > > I'm sure I still sometimes phrase the question in an insulting way but > hopefully the act of putting issues into questions helps me catch > myself. I've learned this technique from fellow developers who review > my code and noticing my own reactions. When they assert that my code > sucks I get defensive. When they ask if I thought about an issue I > don't get defensive and instead get more thoughtful and listen to what > they are saying. > > > > > > > On Mon, Apr 22, 2013 at 1:33 PM, Kenneth Russell > wrote: > > > Florian, I value your contributions to the WebGL community; you've > added several valuable extensions and helped clear up several corner > cases in the specification and conformance tests. I echo Dean's > sentiment that I want you to continue to contribute. > > Unfortunately, these rude interactions damage not only your reputation > but also damage the WebGL community. Other long-time contributors to > OpenGL, OpenGL ES, and WebGL are on the verge of abandoning the WebGL > mailing list as a direct consequence of the abrasive interactions that > have happened here over the past few months. I personally do not want > that to happen, and will take administrative actions to prevent it. > > Understanding your personal issues, I can suggest a couple of > techniques which might help, such as not sending replies immediately, > but letting them sit for an hour and then re-reading them. Feel free > to contact me offline if you want to discuss more ideas. > > All, let's please let our emotions cool down and move forward with a > civil, professional and technically focused tone. There's a lot of > work to be done to move forward the WebGL spec and make > implementations robust. Let's focus on that. > > -Ken > > > > On Sun, Apr 21, 2013 at 11:30 PM, Florian B?sch > wrote: > > Sometimes I'm an insufferable asshole and sometimes I'm not. It > depends on > > where between down or up I am which influences my sensitivity, > feeling of > > self worth, contentness, patience etc. > > > > I wish I had some control over this, but I don't. The cycles > wash over me > > like the tides coming and going. This makes my life difficult, > and it makes > > it difficult for everybody around me, and I know that. I try to > put a wall > > between me and the outside world to protect them from my > emotional life. It > > does mostly work, but sometimes it is leaky, and rarely it has a > breakdown. > > > > There's choices I have to make in how to deal with this issue. I > could just > > dig in for however long it takes to wash over me, but that's not > a terribly > > good idea. I wouldn't get anything done for weeks on end if I > did that. So > > about the only choice I have when I want to be halfways > functional is carry > > on, and life with the unpleasant side effects, warts'n all. > > ----------------------------------------------------------- > You are currently subscribed to public_webgl...@ > . > To unsubscribe, send an email to majordomo...@ > with > the following command in the body of your email: > unsubscribe public_webgl > ----------------------------------------------------------- > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cab...@ Fri Apr 26 15:13:21 2013 From: cab...@ (Rik Cabanier) Date: Fri, 26 Apr 2013 15:13:21 -0700 Subject: [Public WebGL] 2d canvas context to WebGL In-Reply-To: <517A1C4C.5090308@oupeng.com> References: <1423519292.2437417.1366950175426.JavaMail.root@mozilla.com> <517A1C4C.5090308@oupeng.com> Message-ID: I filed it under https://bugzilla.mozilla.org/show_bug.cgi?id=866300 I rewrote Sven's fiddle (thanks!) a bit to show the problem more clearly. It seems that Chrome remembers that the texture was uploaded so running things in a loop is skewing the result. It's very clear on Firefox though. Rik On Thu, Apr 25, 2013 at 11:18 PM, Kang-Hao (Kenny) Lu wrote: > It would be nice if you share the bug number with the list too! > > (13/04/26 12:22), Jeff Gilbert wrote: > > > > Sure! It's on my list of Things To Fix, but it will need to have a bug > filed sooner or later. > > > > Please email me when you create it. (Or just CC me on the bug) > > > > -Jeff > > > > ----- Original Message ----- > > From: "Rik Cabanier" > > To: "Jeff Gilbert" > > Cc: "Kenneth Russell" , "Benoit Jacob" < > bjacob...@>, "public webgl" > > Sent: Thursday, April 25, 2013 9:09:28 PM > > Subject: Re: [Public WebGL] 2d canvas context to WebGL > > > > Should I log bugs against mozilla too? (It's a bit strange since there's > nothing wrong per se) > > > > > > > > On Thu, Apr 25, 2013 at 4:14 PM, Jeff Gilbert < jgilbert...@ > > wrote: > > > > > > I don't believe Firefox does, no. > > > > > > -Jeff > > > > ----- Original Message ----- > > > > > > From: "Rik Cabanier" < cabanier...@ > > > To: "Jeff Gilbert" < jgilbert...@ > > > Cc: "Kenneth Russell" < kbr...@ >, "Benoit Jacob" < > bjacob...@ >, "public webgl" < public_webgl...@ > > > Sent: Thursday, April 25, 2013 4:09:52 PM > > Subject: Re: [Public WebGL] 2d canvas context to WebGL > > > > Do you also not optimize drawImage with a WebGL canvas? > > > > > > On Thu, Apr 25, 2013 at 3:10 PM, Jeff Gilbert < jgilbert...@ > > wrote: > > > > > > Firefox does not currently optimize canvas->canvas transfers, though we > would like to implement this optimization in the future. We definitely > readback and re-upload for texImage2D(. > > > > -Jeff > > > > > > > > ----- Original Message ----- > > From: "Kenneth Russell" < kbr...@ > > > To: "Rik Cabanier" < cabanier...@ > > > Cc: "Benoit Jacob" < bjacob...@ >, "public webgl" < > public_webgl...@ > > > Sent: Thursday, April 25, 2013 1:31:07 PM > > Subject: Re: [Public WebGL] 2d canvas context to WebGL > > > > > > Please file a bug with a self-contained test case. Exposing these > > issues is the only way they are going to be fixed. > > > > -Ken > > > > > > On Thu, Apr 25, 2013 at 1:26 PM, Rik Cabanier < cabanier...@ > > wrote: > >> One of our frameworks draws into a 2d canvas, transfers it to WebGL, > runs a > >> shader and then brings the result back. > >> Just copying a 500x500 canvas to and from WebGL takes: > >> > >> - 16ms on Chrome > >> - 14ms on Firefox > >> - 40ms on Safari > >> > >> > >> This is way to slow to make fluid animations such as this one: > >> http://ads2.msads.net/CIS/48/000/000/000/039/337.swf?fd=www.msn.com(sorry > >> for the flash movie). If you look closely, you will see that the text is > >> blurred during the animation. > >> In most (all?) implementations, the canvas bits were already on the GPU > so > >> this time *could* be brought down to zero. > >> > >> Safari is twice as bad as chrome and Firefox. This is probably caused > by the > >> optimizations you mentioned. > >> > >> The bug you mentioned is because of synchronous readback, Ideally there > >> would be no readback at all :-) > >> > >> On Wed, Apr 24, 2013 at 2:07 PM, Kenneth Russell < kbr...@ > > wrote: > >>> > >>> There is definitely code in Chrome to make Canvas -> WebGL uploads > >>> efficient (as well as the reverse direction), but I believe there are > >>> still some slow paths. See > >>> https://code.google.com/p/chromium/issues/detail?id=233205 for > >>> example. I don't know how much of this made it in to Safari. > >>> > >>> > >>> > >>> On Wed, Apr 24, 2013 at 1:59 PM, Rik Cabanier < cabanier...@ > > wrote: > >>>> Great! > >>>> So Safari and Chrome implement this efficiently? Also is this > documented > >>>> somewhere? > >>>> > >>>> > >>>> On Wed, Apr 24, 2013 at 1:47 PM, Benoit Jacob < bjacob...@ > > >>>> wrote: > >>>>> > >>>>> > >>>>> A 2D canvas can be passed directly to WebGL texImage2D. > >>>>> > >>>>> This happens to be slow in Firefox at the moment (the canvas is > >>>>> currently read back and re-uploaded), but that could probably be > fixed > >>>>> if there is real-world pressure in that direction. > >>>>> > >>>>> Benoit > >>>>> > >>>>> On 13-04-24 04:23 PM, Rik Cabanier wrote: > >>>>>> All, > >>>>>> > >>>>>> Sorry if this is already documented but is there a way to > efficiently > >>>>>> use a 2d canvas context in WebGL? > >>>>>> We've seen cases where people want to apply effects on 2d contexts > >>>>>> and > >>>>>> they're doing this by copying the 2d canvas to a buffer, running a > >>>>>> shader on it and getting the result back. > >>>>>> This is an expensive workflow both in time and memory. > >>>>>> > >>>>>> Since the 2d canvas is already on the GPU (on most browsers), is > >>>>>> there > >>>>>> a way to directly access it from WebGL? > >>>>>> > >>>>>> Thanks! > >>>>> > >>>>> > >>>>> ----------------------------------------------------------- > >>>>> You are currently subscribed to public_webgl...@ . > >>>>> To unsubscribe, send an email to majordomo...@ with > >>>>> the following command in the body of your email: > >>>>> unsubscribe public_webgl > >>>>> ----------------------------------------------------------- > >>>>> > >>>> > >> > >> > > > > ----------------------------------------------------------- > > You are currently subscribed to public_webgl...@ . > > To unsubscribe, send an email to majordomo...@ with > > the following command in the body of your email: > > unsubscribe public_webgl > > ----------------------------------------------------------- > > > > > > > > > > ----------------------------------------------------------- > > You are currently subscribed to public_webgl...@ > > To unsubscribe, send an email to majordomo...@ with > > the following command in the body of your email: > > unsubscribe public_webgl > > ----------------------------------------------------------- > > > > Cheers, > Kenny > -- > Web Specialist, Opera Sphinx Game Force, Oupeng Browser, Beijing > Try Oupeng: http://www.oupeng.com/ > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gma...@ Mon Apr 29 16:01:48 2013 From: gma...@ (Gregg Tavares) Date: Mon, 29 Apr 2013 16:01:48 -0700 Subject: [Public WebGL] Moving WebGL_shared_resources to draft Message-ID: I've updated the WEBGL_shared_resource proposal specto match the proposal on the wiki with updates that have been discussed since then. Any comments or objections to moving these to draft status? -------------- next part -------------- An HTML attachment was scrubbed... URL: From kbr...@ Mon Apr 29 16:15:16 2013 From: kbr...@ (Kenneth Russell) Date: Mon, 29 Apr 2013 16:15:16 -0700 Subject: [Public WebGL] Moving WebGL_shared_resources to draft In-Reply-To: References: Message-ID: Great work on getting shared resources to behave identically among platforms. +1 to moving it to draft status. I would personally like to put this into the specification rather than adding it as an extension, but let's not delay this functionality further. One minor issue: could you please update the last modified date and revision? -Ken On Mon, Apr 29, 2013 at 4:01 PM, Gregg Tavares wrote: > I've updated the WEBGL_shared_resource proposal spec to match the proposal > on the wiki with updates that have been discussed since then. > > Any comments or objections to moving these to draft status? > ----------------------------------------------------------- You are currently subscribed to public_webgl...@ To unsubscribe, send an email to majordomo...@ with the following command in the body of your email: unsubscribe public_webgl -----------------------------------------------------------