Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Wed, Mar 21, 2012 at 8:29 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 20, 2012, at 12:00 PM, James Robinson wrote: If we are adding new APIs for manipulating the backing directly, can we make them asynchronous? This would allow for many optimization opportunities that are currently difficult or impossible. Neat idea to offer async backing store access. I'm not sure that we should tie this to backing store access at true backing store resolution vs at CSS pixel nominal resolution, because it will significantly raise the barrier to authors recoding their existing apps to take full advantage of higher resolutions. With Ted's proposal, all they would have to do is use the HD versions of calls and change their loops to read the bounds from the ImageData object instead of assuming. If we also forced the new calls to be async, then more extensive changes would be required. I hear you on the benefits of async calls, but I think it would be better to sell authors on their benefits separately. Cheers, Maciej Carrots and Sticks. Aren't we missing an opportunity here? By giving web developers this easy migration path, you're also giving up the opportunity to encourage them to use a better API. Asynchronous APIs are harder to use, and that's why we need to encourage their adoption. If you just give people a synchronous version that accomplishes the same thing, then they will just use that, even if doing so causes their app to perform poorly. See synchronous XMLHttpRequest. I'm sure every browser vendor wishes that didn't exist. Note how we recently withdrew support for synchronous ArrayBuffer access on XHR? We did this precisely to discourage use of synchronous mode XHR. Doing so actually broke some existing web pages. The pain was deemed worth it. GPU readback of a HD buffer is going to suck. Any use of this new API is going to suck. -Darin - James On Mar 20, 2012 10:29 AM, Edward Oapos;Connor eocon...@apple.com wrote: Hi, Unfortunately, lots of canvas content (especially content which calls {create,get,put}ImageData methods) assumes that the canvas's backing store pixels correspond 1:1 to CSS pixels, even though the spec has been written to allow for the backing store to be at a different scale factor. Especially problematic is that developers have to round trip image data through a canvas in order to detect that a different scale factor is being used. I'd like to propose the addition of a backingStorePixelRatio property to the 2D context object. Just as window.devicePixelRatio expresses the ratio of device pixels to CSS pixels, ctx.backingStorePixelRatio would express the ratio of backing store pixels to CSS pixels. This allows developers to easily branch to handle different backing store scale factors. Additionally, I think the existing {create,get,put}ImageData API needs to be defined to be in terms of CSS pixels, since that's what existing content assumes. I propose the addition of a new set of methods for working directly with backing store image data. (New methods are easier to feature detect than adding optional arguments to the existing methods.) At the moment I'm calling these {create,get,put}ImageDataHD, but I'm not wedded to the names. (Nor do I want to bikeshed them.) Thanks for your consideration, Ted
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Apr 16, 2012, at 11:07 AM, Darin Fisher da...@chromium.org wrote: Carrots and Sticks. Aren't we missing an opportunity here? By giving web developers this easy migration path, you're also giving up the opportunity to encourage them to use a better API. Asynchronous APIs are harder to use, and that's why we need to encourage their adoption. If you just give people a synchronous version that accomplishes the same thing, then they will just use that, even if doing so causes their app to perform poorly. See synchronous XMLHttpRequest. I'm sure every browser vendor wishes that didn't exist. Note how we recently withdrew support for synchronous ArrayBuffer access on XHR? We did this precisely to discourage use of synchronous mode XHR. Doing so actually broke some existing web pages. The pain was deemed worth it. GPU readback of a HD buffer is going to suck. Any use of this new API is going to suck. -Darin Any use of imagedata i've seen assumes that they can avoid intermediate states in the canvas ever being visible, if you make reading and writing the data asynchronous you break that invariant and suddenly makes things much harder for the user. The reason we don't want IO synchronous is because IO can take a potentially unbound amount of time, if you're on a platform that makes a memcpy take similarly unbound time, i recommend that you work around it. Anyway, the sensible approach to imagedata + hardware backed canvas is to revert to a software backed canvas, as once someone has used imagedata once, they're likely to do it again (and again, and again) so it is probably a win to just do everything in software at that point. Presumably you could through in heuristics to determine whether or not it's worth going back to the GPU at some point, but many of the common image data use cases will have awful perf if you try to keep them on the GPU 100% of the time. --Oliver - James On Mar 20, 2012 10:29 AM, Edward Oapos;Connor eocon...@apple.com wrote: Hi, Unfortunately, lots of canvas content (especially content which calls {create,get,put}ImageData methods) assumes that the canvas's backing store pixels correspond 1:1 to CSS pixels, even though the spec has been written to allow for the backing store to be at a different scale factor. Especially problematic is that developers have to round trip image data through a canvas in order to detect that a different scale factor is being used. I'd like to propose the addition of a backingStorePixelRatio property to the 2D context object. Just as window.devicePixelRatio expresses the ratio of device pixels to CSS pixels, ctx.backingStorePixelRatio would express the ratio of backing store pixels to CSS pixels. This allows developers to easily branch to handle different backing store scale factors. Additionally, I think the existing {create,get,put}ImageData API needs to be defined to be in terms of CSS pixels, since that's what existing content assumes. I propose the addition of a new set of methods for working directly with backing store image data. (New methods are easier to feature detect than adding optional arguments to the existing methods.) At the moment I'm calling these {create,get,put}ImageDataHD, but I'm not wedded to the names. (Nor do I want to bikeshed them.) Thanks for your consideration, Ted
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On 4/16/2012 11:07 AM, Darin Fisher wrote: On Wed, Mar 21, 2012 at 8:29 PM, Maciej Stachowiakm...@apple.com wrote: On Mar 20, 2012, at 12:00 PM, James Robinson wrote: If we are adding new APIs for manipulating the backing directly, can we make them asynchronous? This would allow for many optimization opportunities that are currently difficult or impossible. I hear you on the benefits of async calls, but I think it would be better to sell authors on their benefits separately. Aren't we missing an opportunity here? By giving web developers this easy migration path, you're also giving up the opportunity to encourage them to use a better API. Asynchronous APIs are harder to use, and that's why we need to encourage their adoption. If you just give people a synchronous ... GPU readback of a HD buffer is going to suck. Any use of this new API is going to suck. The vibe I got from the discussion over at WHATWG is that developers and vendors would like to see an async getImageDataHD. put isn't so much of an issue, but get is. As developers, we're going to be using async more-and-more with Canvas; from the toBlob semantic to postMessage transfer semantics. As a Canvas developer, I'd be inclined to use the HD buffer even if it's the same backing size as the standard buffer, if it supported async semantics. ... Separately, I'm hoping to see this issue sorted out: https://lists.webkit.org/pipermail/webkit-dev/2011-April/016428.html IE9+: magicNumber = window.screen.deviceXDPI / window.screen.logicalXDPI; WebKit: magicNumber = (window.outerWidth / window.innerWidth) * (window.devicePixelRatio||1) ; 'with a small margin of error'; Canvas developers today need to use that nasty webkit hack to get their magic number. It's not fun, and I wish we could move off it. IE9 on the desktop works appropriately. I can use browser zoom and re-render with a crisp/sharp Canvas bitmap using the window.screen extensions. -Charles
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On 4/16/2012 11:17 AM, Oliver Hunt wrote: Anyway, the sensible approach to imagedata + hardware backed canvas is to revert to a software backed canvas, as once someone has used imagedata once, they're likely to do it again (and again, and again) so it is probably a win to just do everything in software at that point. Presumably you could through in heuristics to determine whether or not it's worth going back to the GPU at some point, but many of the common image data use cases will have awful perf if you try to keep them on the GPU 100% of the time. The RiverTrail and W16 projects suggest that we'll have a landscape with multiple cores, eventually, to work on image data chunks. Simple instructions can be transformed; simple filters such as Color Matrix filters could be compiled to work on the GPU. Not saying it'll happen, but there are proof of concept projects out there. -Charles
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mon, Apr 16, 2012 at 11:17 AM, Oliver Hunt oli...@apple.com wrote: On Apr 16, 2012, at 11:07 AM, Darin Fisher da...@chromium.org wrote: Carrots and Sticks. Aren't we missing an opportunity here? By giving web developers this easy migration path, you're also giving up the opportunity to encourage them to use a better API. Asynchronous APIs are harder to use, and that's why we need to encourage their adoption. If you just give people a synchronous version that accomplishes the same thing, then they will just use that, even if doing so causes their app to perform poorly. See synchronous XMLHttpRequest. I'm sure every browser vendor wishes that didn't exist. Note how we recently withdrew support for synchronous ArrayBuffer access on XHR? We did this precisely to discourage use of synchronous mode XHR. Doing so actually broke some existing web pages. The pain was deemed worth it. GPU readback of a HD buffer is going to suck. Any use of this new API is going to suck. -Darin Any use of imagedata i've seen assumes that they can avoid intermediate states in the canvas ever being visible, if you make reading and writing the data asynchronous you break that invariant and suddenly makes things much harder for the user. I agree with Charles Pritchard that it is only the reading of pixel data that should be asynchronous. I think developers could learn to cope with this new design just as they do with other asynchronous facets of the platform. The reason we don't want IO synchronous is because IO can take a potentially unbound amount of time, if you're on a platform that makes a memcpy take similarly unbound time, i recommend that you work around it. Of course, GPU readbacks do not compare to network IO. However, if the goal is to achieve smooth animations, then it is important that the main thread not hitch for multiple animation frames. GPU readbacks are irregular in duration and can sometimes be quite expensive if the GPU pipeline is heavily burdened. Anyway, the sensible approach to imagedata + hardware backed canvas is to revert to a software backed canvas, as once someone has used imagedata once, they're likely to do it again (and again, and again) so it is probably a win to just do everything in software at that point. Presumably you could through in heuristics to determine whether or not it's worth going back to the GPU at some point, but many of the common image data use cases will have awful perf if you try to keep them on the GPU 100% of the time. I don't think it is OK if at application startup (or animation startup) there is a big UI glitch as the system determines that it should not GPU-back a canvas. We have the opportunity now to design an API that does not have that bug. Why don't you want to take advantage of this opportunity? -Darin - James On Mar 20, 2012 10:29 AM, Edward Oapos;Connor eocon...@apple.com wrote: Hi, Unfortunately, lots of canvas content (especially content which calls {create,get,put}ImageData methods) assumes that the canvas's backing store pixels correspond 1:1 to CSS pixels, even though the spec has been written to allow for the backing store to be at a different scale factor. Especially problematic is that developers have to round trip image data through a canvas in order to detect that a different scale factor is being used. I'd like to propose the addition of a backingStorePixelRatio property to the 2D context object. Just as window.devicePixelRatio expresses the ratio of device pixels to CSS pixels, ctx.backingStorePixelRatio would express the ratio of backing store pixels to CSS pixels. This allows developers to easily branch to handle different backing store scale factors. Additionally, I think the existing {create,get,put}ImageData API needs to be defined to be in terms of CSS pixels, since that's what existing content assumes. I propose the addition of a new set of methods for working directly with backing store image data. (New methods are easier to feature detect than adding optional arguments to the existing methods.) At the moment I'm calling these {create,get,put}ImageDataHD, but I'm not wedded to the names. (Nor do I want to bikeshed them.) Thanks for your consideration, Ted
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Apr 16, 2012, at 11:38 AM, Darin Fisher da...@chromium.org wrote: On Mon, Apr 16, 2012 at 11:17 AM, Oliver Hunt oli...@apple.com wrote: On Apr 16, 2012, at 11:07 AM, Darin Fisher da...@chromium.org wrote: Carrots and Sticks. Aren't we missing an opportunity here? By giving web developers this easy migration path, you're also giving up the opportunity to encourage them to use a better API. Asynchronous APIs are harder to use, and that's why we need to encourage their adoption. If you just give people a synchronous version that accomplishes the same thing, then they will just use that, even if doing so causes their app to perform poorly. See synchronous XMLHttpRequest. I'm sure every browser vendor wishes that didn't exist. Note how we recently withdrew support for synchronous ArrayBuffer access on XHR? We did this precisely to discourage use of synchronous mode XHR. Doing so actually broke some existing web pages. The pain was deemed worth it. GPU readback of a HD buffer is going to suck. Any use of this new API is going to suck. -Darin Any use of imagedata i've seen assumes that they can avoid intermediate states in the canvas ever being visible, if you make reading and writing the data asynchronous you break that invariant and suddenly makes things much harder for the user. I agree with Charles Pritchard that it is only the reading of pixel data that should be asynchronous. I think developers could learn to cope with this new design just as they do with other asynchronous facets of the platform. The reason we don't want IO synchronous is because IO can take a potentially unbound amount of time, if you're on a platform that makes a memcpy take similarly unbound time, i recommend that you work around it. Of course, GPU readbacks do not compare to network IO. However, if the goal is to achieve smooth animations, then it is important that the main thread not hitch for multiple animation frames. GPU readbacks are irregular in duration and can sometimes be quite expensive if the GPU pipeline is heavily burdened. Anyway, the sensible approach to imagedata + hardware backed canvas is to revert to a software backed canvas, as once someone has used imagedata once, they're likely to do it again (and again, and again) so it is probably a win to just do everything in software at that point. Presumably you could through in heuristics to determine whether or not it's worth going back to the GPU at some point, but many of the common image data use cases will have awful perf if you try to keep them on the GPU 100% of the time. I don't think it is OK if at application startup (or animation startup) there is a big UI glitch as the system determines that it should not GPU-back a canvas. We have the opportunity now to design an API that does not have that bug. Why don't you want to take advantage of this opportunity? We can already do imagedata based access on a gpu backed canvas in webkit without ill effects simply by pulling the canvas off GPU memory. I don't understand why adding a runloop cycle to any read seems like something that would introduce a much more noticable delay than a memcopy. I also don't understand what makes reading from the GPU so expensive that adding a runloop cycle is necessary for good perf, but it's unnecessary for a write. This feels like an argument along the lines of we hate synchronous APIs, but they make sense for graphics. Let's try and make at least part of this asynchronous to satisfy that particular desire. Moving data to and from the GPU may be expensive, but i doubt it holds a candle to the cost of waiting for a full runloop cycle, unless you're doing something really inefficient in your backing store management. The fact is that the ImageData is a pixel manipulation API, and any such API is not conducive to good performance on the GPU. --Oliver -Darin - James On Mar 20, 2012 10:29 AM, Edward Oapos;Connor eocon...@apple.com wrote: Hi, Unfortunately, lots of canvas content (especially content which calls {create,get,put}ImageData methods) assumes that the canvas's backing store pixels correspond 1:1 to CSS pixels, even though the spec has been written to allow for the backing store to be at a different scale factor. Especially problematic is that developers have to round trip image data through a canvas in order to detect that a different scale factor is being used. I'd like to propose the addition of a backingStorePixelRatio property to the 2D context object. Just as window.devicePixelRatio expresses the ratio of device pixels to CSS pixels, ctx.backingStorePixelRatio would express the ratio of backing store pixels to CSS pixels. This allows developers to easily branch to handle different backing store scale factors. Additionally, I think the existing
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt oli...@apple.com wrote: I don't understand why adding a runloop cycle to any read seems like something that would introduce a much more noticable delay than a memcopy. The use case is deferred rendering. Canvas drawing calls don't need to complete synchronously (before the drawing call returns); they can be queued, so API calls return immediately and the actual draws can happen in a thread or on the GPU. This is exactly like OpenGL's pipelining model (and might well be implemented using it, on some platforms). The problem is that if you have a bunch of that work pipelined, and you perform a synchronous readback, you have to flush the queue. In OpenGL terms, you have to call glFinish(). That might take long enough to cause a visible UI hitch. By making the readback asynchronous, you can defer the actual operation until the operations before it have been completed, so you avoid any such blocking in the UI thread. I also don't understand what makes reading from the GPU so expensive that adding a runloop cycle is necessary for good perf, but it's unnecessary for a write. It has nothing to do with how expensive the GPU read is, and everything to do with the need to flush the pipeline. Writes don't need to do this; they simply queue, like any other drawing operation. -- Glenn Maynard
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
Could someone construct a demonstration of where the read back of the imagedata takes longer than a runloop cycle? You're asking for significant additional complexity for content authors, with a regression in general case performance, it would be good to see if it's possible to create an example, even if it's not something any sensible author would do, where their is a performance improvement. Remember, the application is only marginally better when it's not painting due to waiting for a runloop cycle than it is when blocked waiting on a graphics flush. Also, if the argument is wrt deferred rendering rather than GPU copyback, can we drop GPU related arguments from this thread? --Oliver On Apr 16, 2012, at 12:10 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt oli...@apple.com wrote: I don't understand why adding a runloop cycle to any read seems like something that would introduce a much more noticable delay than a memcopy. The use case is deferred rendering. Canvas drawing calls don't need to complete synchronously (before the drawing call returns); they can be queued, so API calls return immediately and the actual draws can happen in a thread or on the GPU. This is exactly like OpenGL's pipelining model (and might well be implemented using it, on some platforms). The problem is that if you have a bunch of that work pipelined, and you perform a synchronous readback, you have to flush the queue. In OpenGL terms, you have to call glFinish(). That might take long enough to cause a visible UI hitch. By making the readback asynchronous, you can defer the actual operation until the operations before it have been completed, so you avoid any such blocking in the UI thread. I also don't understand what makes reading from the GPU so expensive that adding a runloop cycle is necessary for good perf, but it's unnecessary for a write. It has nothing to do with how expensive the GPU read is, and everything to do with the need to flush the pipeline. Writes don't need to do this; they simply queue, like any other drawing operation. -- Glenn Maynard
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
Glenn summarizes my concerns exactly. Deferred rendering is indeed the more precise issue. On Mon, Apr 16, 2012 at 12:18 PM, Oliver Hunt oli...@apple.com wrote: Could someone construct a demonstration of where the read back of the imagedata takes longer than a runloop cycle? I bet this would be fairly easy to demonstrate. You're asking for significant additional complexity for content authors, with a regression in general case performance, it would be good to see if it's possible to create an example, even if it's not something any sensible author would do, where their is a performance improvement. Remember, the application is only marginally better when it's not painting due to waiting for a runloop cycle than it is when blocked waiting on a graphics flush. You can do a lot of other things during this time. For example, you can prepare the next animation frame. You can run JavaScript garbage collection. Also, it is common for a browser thread to handle animations for multiple windows. If you have animations going in both windows, it would be nice for those animations to update in parallel instead of being serialized. -Darin Also, if the argument is wrt deferred rendering rather than GPU copyback, can we drop GPU related arguments from this thread? --Oliver On Apr 16, 2012, at 12:10 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt oli...@apple.com wrote: I don't understand why adding a runloop cycle to any read seems like something that would introduce a much more noticable delay than a memcopy. The use case is deferred rendering. Canvas drawing calls don't need to complete synchronously (before the drawing call returns); they can be queued, so API calls return immediately and the actual draws can happen in a thread or on the GPU. This is exactly like OpenGL's pipelining model (and might well be implemented using it, on some platforms). The problem is that if you have a bunch of that work pipelined, and you perform a synchronous readback, you have to flush the queue. In OpenGL terms, you have to call glFinish(). That might take long enough to cause a visible UI hitch. By making the readback asynchronous, you can defer the actual operation until the operations before it have been completed, so you avoid any such blocking in the UI thread. I also don't understand what makes reading from the GPU so expensive that adding a runloop cycle is necessary for good perf, but it's unnecessary for a write. It has nothing to do with how expensive the GPU read is, and everything to do with the need to flush the pipeline. Writes don't need to do this; they simply queue, like any other drawing operation. -- Glenn Maynard
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote: On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote: dialog will give a better user experience than even a non-modal version of window.confirm() or window.alert(). Dialogs that are fully in-page Oops, got cut off here. What I meant to say is something like dialogs that are fully in-page are the emerging standard for high-quality page-modal prompting. Non-blocking window.{alert,confirm,prompt} would most likely be rendered by UAs as in-page overlays / tab-scoped dialogs. This is what we would do in Chrome, and it seems like others would do the same given the prevalence of the standard window.{alert,confirm,prompt} being implemented in a tab-scoped manner already by some browsers (albeit with bugs). I think people use alert, confirm and prompt in part because they are so easy to use. People who choose window.{alert,confirm,prompt} probably don't care about loss of customization or else they would roll their own dialogs. Why not provide less sucky versions of those common dialogs? Benefit: Less code for simple dialogs. Con: Another web platform API to standardize. Con: Encourages poor HI design (since these stock dialogs should almost never be used). That being said, I find in-page UI less objectionable than a pop-up alert, but in that case I'm not sure it makes sense to overload the existing API. It would be better to make new methods so feature testing is possible. Even given all that, I'm not confident of the value add over dialog. Regards, Maciej
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Apr 16, 2012, at 1:12 PM, Darin Fisher da...@chromium.org wrote: Glenn summarizes my concerns exactly. Deferred rendering is indeed the more precise issue. On Mon, Apr 16, 2012 at 12:18 PM, Oliver Hunt oli...@apple.com wrote: Could someone construct a demonstration of where the read back of the imagedata takes longer than a runloop cycle? I bet this would be fairly easy to demonstrate. Then by all means do :D You're asking for significant additional complexity for content authors, with a regression in general case performance, it would be good to see if it's possible to create an example, even if it's not something any sensible author would do, where their is a performance improvement. Remember, the application is only marginally better when it's not painting due to waiting for a runloop cycle than it is when blocked waiting on a graphics flush. You can do a lot of other things during this time. For example, you can prepare the next animation frame. You can run JavaScript garbage collection. Also, it is common for a browser thread to handle animations for multiple windows. If you have animations going in both windows, it would be nice for those animations to update in parallel instead of being serialized. None of which changes the fact that your actual developer now needs more complicated code, and has slower performance. If I'm doing purely imagedata based code then there isn't anything to defer, and so all you're doing is adding runloop latency. The other examples you give don't really apply either. Most imagedata both code i've seen is not GC heavy, if you're performing animations using css animations, etc then I believe that the browser is already able to hoist them onto another thread. If you have animations in multiple windows then chrome doesn't have a problem because those windows are a separate process, and if you're not, then all you're doing is allowing one runloop of work (which may or may not be enough to get a paint done) before you start processing your ImageData. I'm really not sure what it is that you're doing with your ImageData such that it takes so much less time than the canvas work, but it seems remarkable that there's some operation you can perform in JS over all the data returned that takes less time that the latency introduced by an async API. --Oliver -Darin Also, if the argument is wrt deferred rendering rather than GPU copyback, can we drop GPU related arguments from this thread? --Oliver On Apr 16, 2012, at 12:10 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt oli...@apple.com wrote: I don't understand why adding a runloop cycle to any read seems like something that would introduce a much more noticable delay than a memcopy. The use case is deferred rendering. Canvas drawing calls don't need to complete synchronously (before the drawing call returns); they can be queued, so API calls return immediately and the actual draws can happen in a thread or on the GPU. This is exactly like OpenGL's pipelining model (and might well be implemented using it, on some platforms). The problem is that if you have a bunch of that work pipelined, and you perform a synchronous readback, you have to flush the queue. In OpenGL terms, you have to call glFinish(). That might take long enough to cause a visible UI hitch. By making the readback asynchronous, you can defer the actual operation until the operations before it have been completed, so you avoid any such blocking in the UI thread. I also don't understand what makes reading from the GPU so expensive that adding a runloop cycle is necessary for good perf, but it's unnecessary for a write. It has nothing to do with how expensive the GPU read is, and everything to do with the need to flush the pipeline. Writes don't need to do this; they simply queue, like any other drawing operation. -- Glenn Maynard
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On 16 Apr 2012 at 19:07, Darin Fisher da...@chromium.org wrote: Aren't we missing an opportunity here? By giving web developers this easy migration path, you're also giving up the opportunity to encourage them to use a better API. Asynchronous APIs are harder to use, and that's why we need to encourage their adoption. If you just give people a synchronous version that accomplishes the same thing, then they will just use that, even if doing so causes their app to perform poorly. See synchronous XMLHttpRequest. I'm sure every browser vendor wishes that didn't exist. Note how we recently withdrew support for synchronous ArrayBuffer access on XHR? We did this precisely to discourage use of synchronous mode XHR. Doing so actually broke some existing web pages. The pain was deemed worth it. In my app I have about 90 async XMLHttpRequest calls. I have one synchronous one that I'd really like to keep as it facilitates a clean tidy up if the user ignores my Exit button and quits by closing the window. When the app closes I need to run a script in order to shut down a local apache instance amongst other things. I hope I'm not going to find this to be a problem if synchronous mode XMLHttpRequest is removed from Safari at some future point. My code looks like this: function quitbyClose () { // User clicked window close button. Must make a synchronous ajax call to tidy up. We have to ensure // SESE with no return being executed due to the odd way that onbeforeunload operates, in two cases: // 1) Where Safari re-opens myapp after user quits Safari and user has already restarted myapp // 2) Where user might try to start this file by hand var request, data; if (portnum0) { closeWindows (); // Close any popups data = datarootpath= + encodeURIComponent (datarootpath) + debugfl= + debugfl; request = new XMLHttpRequest (); request.open (POST, http://localhost:; + portnum + /bin/myapp-terminate.php, false); request.setRequestHeader (Content-Type, application/x-www-form-urlencoded; charset=utf-8); request.onreadystatechange = function() { if (request.readyState!=4) return false; } request.send (data); } } -- Cheers -- Tim
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Apr 16, 2012, at 11:07 AM, Darin Fisher da...@chromium.org wrote: See synchronous XMLHttpRequest. I'm sure every browser vendor wishes that didn't exist. Note how we recently withdrew support for synchronous ArrayBuffer access on XHR? We did this precisely to discourage use of synchronous mode XHR. Doing so actually broke some existing web pages. The pain was deemed worth it. Yes, but the reason for this is very simple: synchronous IO can take a literally interminable amount of time, in which nothing else can happen. We're talking about something entirely client side, that is theoretically going to be done sufficiently quickly to update a frame. The IO case has a best case of hundreds of milliseconds, whereas that is likely to be close to the worst case on the graphics side. --Oliver
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote: On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote: dialog will give a better user experience than even a non-modal version of window.confirm() or window.alert(). Dialogs that are fully in-page Oops, got cut off here. What I meant to say is something like dialogs that are fully in-page are the emerging standard for high-quality page-modal prompting. Non-blocking window.{alert,confirm,prompt} would most likely be rendered by UAs as in-page overlays / tab-scoped dialogs. This is what we would do in Chrome, and it seems like others would do the same given the prevalence of the standard window.{alert,confirm,prompt} being implemented in a tab-scoped manner already by some browsers (albeit with bugs). I think people use alert, confirm and prompt in part because they are so easy to use. People who choose window.{alert,confirm,prompt} probably don't care about loss of customization or else they would roll their own dialogs. Why not provide less sucky versions of those common dialogs? Benefit: Less code for simple dialogs. Con: Another web platform API to standardize. Con: Encourages poor HI design (since these stock dialogs should almost never be used). That being said, I find in-page UI less objectionable than a pop-up alert, but in that case I'm not sure it makes sense to overload the existing API. It would be better to make new methods so feature testing is possible. Even given all that, I'm not confident of the value add over dialog. It seems like poor HI design is rather subjective. Some might prefer the OS-native look-and-feel of these simple dialogs. Good point about feature testing. I'd be OK with async{Alert,Confirm,Prompt} or whatever name variant we prefer. You don't see much value in the simplicity of having these methods be provided by the platform? It seems like dialog requires much more code to setup. Regards, -Darin
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mon, Apr 16, 2012 at 1:45 PM, Oliver Hunt oli...@apple.com wrote: On Apr 16, 2012, at 11:07 AM, Darin Fisher da...@chromium.org wrote: See synchronous XMLHttpRequest. I'm sure every browser vendor wishes that didn't exist. Note how we recently withdrew support for synchronous ArrayBuffer access on XHR? We did this precisely to discourage use of synchronous mode XHR. Doing so actually broke some existing web pages. The pain was deemed worth it. Yes, but the reason for this is very simple: synchronous IO can take a literally interminable amount of time, in which nothing else can happen. We're talking about something entirely client side, that is theoretically going to be done sufficiently quickly to update a frame. The IO case has a best case of hundreds of milliseconds, whereas that is likely to be close to the worst case on the graphics side. Sorry, I did not make my point clear. I did not intend to equate network delays to graphics delays, as they are obviously not on the same order of magnitude. Let me try again. We decided that we didn't like synchronous XHR. We decided to withhold new features from synchronous XHR. I believe we did so in part to discourage use of synchronous XHR and encourage use of asynchronous XHR. I was suggesting that we have an opportunity to apply a similar approach to canvas ImageData. I have learned that it is not commonly accepted that reading ImageData can be slow. I had assumed otherwise. -Darin
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mon, Apr 16, 2012 at 1:52 PM, Darin Fisher da...@chromium.org wrote: On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak m...@apple.com wrote: Con: Encourages poor HI design (since these stock dialogs should almost never be used). That being said, I find in-page UI less objectionable than a pop-up alert, but in that case I'm not sure it makes sense to overload the existing API. It would be better to make new methods so feature testing is possible. Even given all that, I'm not confident of the value add over dialog. It seems like poor HI design is rather subjective. Some might prefer the OS-native look-and-feel of these simple dialogs. I think you'll have a hard time finding people who prefer that. ^_^ Good point about feature testing. I'd be OK with async{Alert,Confirm,Prompt} or whatever name variant we prefer. You don't see much value in the simplicity of having these methods be provided by the platform? It seems like dialog requires much more code to setup. Hixie provided (in another thread) an example of the code required for dialog that was feature-equivalent to popping a prompt. The difference is minimal. ~TJ
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Apr 16, 2012, at 2:00 PM, Darin Fisher da...@chromium.org wrote: I have learned that it is not commonly accepted that reading ImageData can be slow. I had assumed otherwise. Yes, it's possible to make reading image data slow, but i can make _anything_ slow. I could make postMessage slow even though it's ostensibly asynchronous simply by triggering a copy of a large enough object. The problem I have is that there has been any demonstration that making the data read asynchronous will save substantial time vs. a) the typical operations that will subsequently be performed on the retrieved data or b) that it would generally take longer than a runloop cycle. Knowingly adding complexity without any good metrics that show getImageData{HD} is sufficiently expensive to warrant that complexity seems like the wrong path to take. -Darin
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Apr 16, 2012, at 12:10 PM, Glenn Maynard wrote: On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt oli...@apple.com wrote: I don't understand why adding a runloop cycle to any read seems like something that would introduce a much more noticable delay than a memcopy. The use case is deferred rendering. Canvas drawing calls don't need to complete synchronously (before the drawing call returns); they can be queued, so API calls return immediately and the actual draws can happen in a thread or on the GPU. This is exactly like OpenGL's pipelining model (and might well be implemented using it, on some platforms). The problem is that if you have a bunch of that work pipelined, and you perform a synchronous readback, you have to flush the queue. In OpenGL terms, you have to call glFinish(). That might take long enough to cause a visible UI hitch. By making the readback asynchronous, you can defer the actual operation until the operations before it have been completed, so you avoid any such blocking in the UI thread. I also don't understand what makes reading from the GPU so expensive that adding a runloop cycle is necessary for good perf, but it's unnecessary for a write. It has nothing to do with how expensive the GPU read is, and everything to do with the need to flush the pipeline. Writes don't need to do this; they simply queue, like any other drawing operation. Would the async version still require a flush and immediate readback if you do any drawing after the get call but before the data is returned? Regards, Maciej
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Apr 16, 2012, at 1:52 PM, Darin Fisher wrote: On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 29, 2012, at 1:10 AM, Darin Fisher wrote: On Wed, Mar 21, 2012 at 8:03 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 21, 2012, at 7:54 PM, Maciej Stachowiak wrote: dialog will give a better user experience than even a non-modal version of window.confirm() or window.alert(). Dialogs that are fully in-page Oops, got cut off here. What I meant to say is something like dialogs that are fully in-page are the emerging standard for high-quality page-modal prompting. Non-blocking window.{alert,confirm,prompt} would most likely be rendered by UAs as in-page overlays / tab-scoped dialogs. This is what we would do in Chrome, and it seems like others would do the same given the prevalence of the standard window.{alert,confirm,prompt} being implemented in a tab-scoped manner already by some browsers (albeit with bugs). I think people use alert, confirm and prompt in part because they are so easy to use. People who choose window.{alert,confirm,prompt} probably don't care about loss of customization or else they would roll their own dialogs. Why not provide less sucky versions of those common dialogs? Benefit: Less code for simple dialogs. Con: Another web platform API to standardize. Con: Encourages poor HI design (since these stock dialogs should almost never be used). That being said, I find in-page UI less objectionable than a pop-up alert, but in that case I'm not sure it makes sense to overload the existing API. It would be better to make new methods so feature testing is possible. Even given all that, I'm not confident of the value add over dialog. It seems like poor HI design is rather subjective. Some might prefer the OS-native look-and-feel of these simple dialogs. The APIs as they currently exist are unable to provide an experience that is consistent with Mac OS X or iOS HI design. Modal alerts are rarely used in general, and when they are used, the buttons need to have labels that conform to the action rather than generic labels like OK. I feel that the original design of alert(), confirm() and prompt() is very Windows-centric, and really Windows-circa-late-90s-centric. You could enhance the API to make these dialogs sufficiently more customizable. But then I am even more skeptical of the value over dialog. Good point about feature testing. I'd be OK with async{Alert,Confirm,Prompt} or whatever name variant we prefer. You don't see much value in the simplicity of having these methods be provided by the platform? It seems like dialog requires much more code to setup. I think there's almost 0 times that it is correct to pop up an OK/Cancel dialog. If you incorporate customizing the button labels, I don't think dialog is materially more complicated. Regards, Maciej
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mon, Apr 16, 2012 at 1:39 PM, Oliver Hunt oli...@apple.com wrote: On Apr 16, 2012, at 1:12 PM, Darin Fisher da...@chromium.org wrote: Glenn summarizes my concerns exactly. Deferred rendering is indeed the more precise issue. On Mon, Apr 16, 2012 at 12:18 PM, Oliver Hunt oli...@apple.com wrote: Could someone construct a demonstration of where the read back of the imagedata takes longer than a runloop cycle? I bet this would be fairly easy to demonstrate. Then by all means do :D Here's an example. Take http://ie.microsoft.com/testdrive/Performance/FishIETank/, and apply the following diff (changing the draw function): BEGIN DIFF --- fishie.htm.orig 2012-04-16 14:23:29.224864338 -0700 +++ fishie.htm 2012-04-16 14:21:38.115489276 -0700 @@ -177,10 +177,17 @@ // Draw each fish for (var fishie in fish) { fish[fishie].swim(); } + +if (window.read_back) { +var data = ctx.getImageData(0, 0, WIDTH, HEIGHT).data; +var x = data[0]; // force readback +} + + //draw fpsometer with the current number of fish fpsMeter.Draw(fish.length); } function Fish() { END DIFF Running on a Mac Pro, with Chrome 19 (WebKit @r111385), with 1000 fish, I get 60 FPS. Setting read_back to true (using dev tools), drops it down to 30 FPS. Using about:tracing (a tool built into Chrome), I can see that the read pixels call is taking ~15 milliseconds to complete. The implied GL flush takes ~11 milliseconds. The page was sized to 1400 x 1000 pixels. -Darin You're asking for significant additional complexity for content authors, with a regression in general case performance, it would be good to see if it's possible to create an example, even if it's not something any sensible author would do, where their is a performance improvement. Remember, the application is only marginally better when it's not painting due to waiting for a runloop cycle than it is when blocked waiting on a graphics flush. You can do a lot of other things during this time. For example, you can prepare the next animation frame. You can run JavaScript garbage collection. Also, it is common for a browser thread to handle animations for multiple windows. If you have animations going in both windows, it would be nice for those animations to update in parallel instead of being serialized. None of which changes the fact that your actual developer now needs more complicated code, and has slower performance. If I'm doing purely imagedata based code then there isn't anything to defer, and so all you're doing is adding runloop latency. The other examples you give don't really apply either. Most imagedata both code i've seen is not GC heavy, if you're performing animations using css animations, etc then I believe that the browser is already able to hoist them onto another thread. If you have animations in multiple windows then chrome doesn't have a problem because those windows are a separate process, and if you're not, then all you're doing is allowing one runloop of work (which may or may not be enough to get a paint done) before you start processing your ImageData. I'm really not sure what it is that you're doing with your ImageData such that it takes so much less time than the canvas work, but it seems remarkable that there's some operation you can perform in JS over all the data returned that takes less time that the latency introduced by an async API. --Oliver -Darin Also, if the argument is wrt deferred rendering rather than GPU copyback, can we drop GPU related arguments from this thread? --Oliver On Apr 16, 2012, at 12:10 PM, Glenn Maynard gl...@zewt.org wrote: On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt oli...@apple.com wrote: I don't understand why adding a runloop cycle to any read seems like something that would introduce a much more noticable delay than a memcopy. The use case is deferred rendering. Canvas drawing calls don't need to complete synchronously (before the drawing call returns); they can be queued, so API calls return immediately and the actual draws can happen in a thread or on the GPU. This is exactly like OpenGL's pipelining model (and might well be implemented using it, on some platforms). The problem is that if you have a bunch of that work pipelined, and you perform a synchronous readback, you have to flush the queue. In OpenGL terms, you have to call glFinish(). That might take long enough to cause a visible UI hitch. By making the readback asynchronous, you can defer the actual operation until the operations before it have been completed, so you avoid any such blocking in the UI thread. I also don't understand what makes reading from the GPU so expensive that adding a runloop cycle is necessary for good perf, but it's unnecessary for a write. It has nothing
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mon, Apr 16, 2012 at 2:06 PM, Maciej Stachowiak m...@apple.com wrote: On Apr 16, 2012, at 12:10 PM, Glenn Maynard wrote: On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt oli...@apple.com wrote: I don't understand why adding a runloop cycle to any read seems like something that would introduce a much more noticable delay than a memcopy. The use case is deferred rendering. Canvas drawing calls don't need to complete synchronously (before the drawing call returns); they can be queued, so API calls return immediately and the actual draws can happen in a thread or on the GPU. This is exactly like OpenGL's pipelining model (and might well be implemented using it, on some platforms). The problem is that if you have a bunch of that work pipelined, and you perform a synchronous readback, you have to flush the queue. In OpenGL terms, you have to call glFinish(). That might take long enough to cause a visible UI hitch. By making the readback asynchronous, you can defer the actual operation until the operations before it have been completed, so you avoid any such blocking in the UI thread. I also don't understand what makes reading from the GPU so expensive that adding a runloop cycle is necessary for good perf, but it's unnecessary for a write. It has nothing to do with how expensive the GPU read is, and everything to do with the need to flush the pipeline. Writes don't need to do this; they simply queue, like any other drawing operation. Would the async version still require a flush and immediate readback if you do any drawing after the get call but before the data is returned? I think it would not need to. It would just return a snapshot of the state of the canvas up to the point where the asyncGetImageData call was made. This makes sense if you consider both draw calls and asyncGetImageData calls being put on the same work queue (without any change in their respective order). -Darin
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Apr 16, 2012, at 2:34 PM, Darin Fisher da...@chromium.org wrote: On Mon, Apr 16, 2012 at 1:39 PM, Oliver Hunt oli...@apple.com wrote: On Apr 16, 2012, at 1:12 PM, Darin Fisher da...@chromium.org wrote: Glenn summarizes my concerns exactly. Deferred rendering is indeed the more precise issue. On Mon, Apr 16, 2012 at 12:18 PM, Oliver Hunt oli...@apple.com wrote: Could someone construct a demonstration of where the read back of the imagedata takes longer than a runloop cycle? I bet this would be fairly easy to demonstrate. Then by all means do :D Here's an example. Take http://ie.microsoft.com/testdrive/Performance/FishIETank/, and apply the following diff (changing the draw function): BEGIN DIFF --- fishie.htm.orig 2012-04-16 14:23:29.224864338 -0700 +++ fishie.htm 2012-04-16 14:21:38.115489276 -0700 @@ -177,10 +177,17 @@ // Draw each fish for (var fishie in fish) { fish[fishie].swim(); } + +if (window.read_back) { +var data = ctx.getImageData(0, 0, WIDTH, HEIGHT).data; +var x = data[0]; // force readback +} + + //draw fpsometer with the current number of fish fpsMeter.Draw(fish.length); } function Fish() { END DIFF Running on a Mac Pro, with Chrome 19 (WebKit @r111385), with 1000 fish, I get 60 FPS. Setting read_back to true (using dev tools), drops it down to 30 FPS. Using about:tracing (a tool built into Chrome), I can see that the read pixels call is taking ~15 milliseconds to complete. The implied GL flush takes ~11 milliseconds. The page was sized to 1400 x 1000 pixels. How does that compare to going through the runloop -- how long does it take to get from that point to a timeout being called if you do var start = new Date; setTimeout(function() {console.log(new Date - start);}, 0); ? This also ignores that possibility that in requesting the data, i probably also want to do some processing on the data, so for the sake of simplicity how long does it take to subsequently iterate through every pixel and set it to 0? Remember the goal of making this asynchronous is to improve performance, so the 11ms of drawing does have to occur at some point, you're just hoping that by making things asynchronous you can mask that. But I doubt you would see an actual improvement in wall clock performance. I also realised something else that I had not previously considered -- if you're doing bitblit based sprite movement the complexity goes way up if this is asynchronous. --Oliver
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mon, Apr 16, 2012 at 2:18 PM, Oliver Hunt oli...@apple.com wrote: Could someone construct a demonstration of where the read back of the imagedata takes longer than a runloop cycle? Runloop doesn't mean anything to me (nor to Google [1], nor to the HTML specification). If you're talking about WebKit-specific limitations, please explain what you're talking about (most of us aren't WebKit developers). If you make an asynchronous call, the call should execute as soon as possible after returning to the event loop; if there are no other jobs on that task queue or other drawing operations pending, then it should happen with a near-zero delay. Where this doesn't happen in practice, it's something that should be fixed. (That would cause problems with many other async APIs. For example, if you perform an asynchronous File API read, and that read has an additional 2ms delay, then sequentially reading a file 64k at a time would cap out at 32MB/sec. It should only artificially delay event queue tasks if it's actually necessary for UI responsiveness.) [1] https://www.google.com/#sclient=psy-abhl=enq=site:w3.org+%22runloop%22 On Mon, Apr 16, 2012 at 3:45 PM, Oliver Hunt oli...@apple.com wrote: The IO case has a best case of hundreds of milliseconds, whereas that is likely to be close to the worst case on the graphics side. (Actually, the best case should be almost instantaneous, if you're using XHR to read from an object URL that points to a Blob stored or cached in RAM, or for network requests that can be served out of network cache. You're correct in the more common cases, of course, though I'd say the best case for network requests is in the tens of milliseconds, not hundreds.) On Mon, Apr 16, 2012 at 4:06 PM, Maciej Stachowiak m...@apple.com wrote: Would the async version still require a flush and immediate readback if you do any drawing after the get call but before the data is returned? So long as the implementation handles all drawing calls asynchronously, no. The later drawing operations will simply be queued to happen after the completion of the readback. If the implementation can do some things async and some not, then it may still have to block. That's just QoA, of course: this is meant to allow implementations to queue as much as possible, not to require that they do. -- Glenn Maynard
Re: [whatwg] [canvas] request for {create, get, put}ImageDataHD and ctx.backingStorePixelRatio
On Mon, Apr 16, 2012 at 2:57 PM, Oliver Hunt oli...@apple.com wrote: On Apr 16, 2012, at 2:34 PM, Darin Fisher da...@chromium.org wrote: On Mon, Apr 16, 2012 at 1:39 PM, Oliver Hunt oli...@apple.com wrote: On Apr 16, 2012, at 1:12 PM, Darin Fisher da...@chromium.org wrote: Glenn summarizes my concerns exactly. Deferred rendering is indeed the more precise issue. On Mon, Apr 16, 2012 at 12:18 PM, Oliver Hunt oli...@apple.com wrote: Could someone construct a demonstration of where the read back of the imagedata takes longer than a runloop cycle? I bet this would be fairly easy to demonstrate. Then by all means do :D Here's an example. Take http://ie.microsoft.com/testdrive/Performance/FishIETank/, and apply the following diff (changing the draw function): BEGIN DIFF --- fishie.htm.orig 2012-04-16 14:23:29.224864338 -0700 +++ fishie.htm 2012-04-16 14:21:38.115489276 -0700 @@ -177,10 +177,17 @@ // Draw each fish for (var fishie in fish) { fish[fishie].swim(); } + +if (window.read_back) { +var data = ctx.getImageData(0, 0, WIDTH, HEIGHT).data; +var x = data[0]; // force readback +} + + //draw fpsometer with the current number of fish fpsMeter.Draw(fish.length); } function Fish() { END DIFF Running on a Mac Pro, with Chrome 19 (WebKit @r111385), with 1000 fish, I get 60 FPS. Setting read_back to true (using dev tools), drops it down to 30 FPS. Using about:tracing (a tool built into Chrome), I can see that the read pixels call is taking ~15 milliseconds to complete. The implied GL flush takes ~11 milliseconds. The page was sized to 1400 x 1000 pixels. How does that compare to going through the runloop -- how long does it take to get from that point to a timeout being called if you do var start = new Date; setTimeout(function() {console.log(new Date - start);}, 0); ? The answer is ~0 milliseconds. I know this because without the getImageData call, the frame rate is 60 FPS. The page calls the draw() function from an interval timer that has a period of 16.7 milliseconds. The trace indicates that nearly all of that budget is used up prior to the getImageData() call that I inserted. This also ignores that possibility that in requesting the data, i probably also want to do some processing on the data, so for the sake of simplicity how long does it take to subsequently iterate through every pixel and set it to 0? That adds about 44 milliseconds. I would hope that developers would either perform this work in chunks or pass ImageData.data off to a web worker for processing. Remember the goal of making this asynchronous is to improve performance, so the 11ms of drawing does have to occur at some point, you're just hoping that by making things asynchronous you can mask that. But I doubt you would see an actual improvement in wall clock performance. The 11 ms of drawing occurs on a background thread. Yes, that latency exists, but it doesn't have to block the main thread. Let me reiterate the point I made before. There can be multiple web pages sharing the same main thread. (Even in Chrome this can be true!) Blocking one web page has the effect of blocking all web pages that share the same main thread. It is not nice for one web page to jank up the browser's main thread and as a result make other web pages unresponsive. I also realised something else that I had not previously considered -- if you're doing bitblit based sprite movement the complexity goes way up if this is asynchronous. I don't follow. Can you clarify? Thanks, -Darin
Re: [whatwg] Proposal for non-modal versions of modal prompts
On Mon, Apr 16, 2012 at 2:03 PM, Tab Atkins Jr. jackalm...@gmail.comwrote: On Mon, Apr 16, 2012 at 1:52 PM, Darin Fisher da...@chromium.org wrote: On Mon, Apr 16, 2012 at 1:18 PM, Maciej Stachowiak m...@apple.com wrote: Con: Encourages poor HI design (since these stock dialogs should almost never be used). That being said, I find in-page UI less objectionable than a pop-up alert, but in that case I'm not sure it makes sense to overload the existing API. It would be better to make new methods so feature testing is possible. Even given all that, I'm not confident of the value add over dialog. It seems like poor HI design is rather subjective. Some might prefer the OS-native look-and-feel of these simple dialogs. I think you'll have a hard time finding people who prefer that. ^_^ Good point about feature testing. I'd be OK with async{Alert,Confirm,Prompt} or whatever name variant we prefer. You don't see much value in the simplicity of having these methods be provided by the platform? It seems like dialog requires much more code to setup. Hixie provided (in another thread) an example of the code required for dialog that was feature-equivalent to popping a prompt. The difference is minimal. ~TJ Oh, indeed he did. Using form and input inside a dialog to create simple dialogs is a nice idea. I suppose the UA stylesheet could have some extra rules to make that have a decent default rendering. Hmm... I'm starting to care a bit less about async{Alert,Confirm,Prompt}. Although, it still bugs me that the path of least resistance for simple dialogs will remain good old thread-blocking modal alert/confirm/prompt :-( -Darin
Re: [whatwg] keepalive attribute on iframe
Can you hide this behind adoptNode just as we did for magic iframe? The nice thing about adoptNode is that the browser gets told both the source and destination parent nodes. This way there is never a disconnected state. So long as we unload when moving between documents, we should be pretty safe as far as the issues which plagued magic iframe are concerned. -Darin On Thu, Apr 12, 2012 at 12:35 PM, Ojan Vafai o...@chromium.org wrote: We should add a keepalive attribute to iframes that prevents iframes from being unloaded/reloaded when removed from or appended to a document. Similarly, a disconnected iframe with keepalive should load. If the keepalive attribute is removed from a disconnected iframe, then it should unload. I'm not terribly happy with the name 'keepalive', but I can't think of anything better at the moment. As iframes increasingly become the standard way of achieving certain tasks (e.g. sandboxing), it's increasingly important to be able to move them around in the DOM. Right now, to achieve this sort of keepalive behavior, you have to keep the iframe always appended to the document and position it absolutely as the document changes. Ojan
Re: [whatwg] keepalive attribute on iframe
FWIW, IE used to not reload iframes when they were moved around in the tree. They changed this behavior in IE9 so maybe there was some compat issues? erik On Mon, Apr 16, 2012 at 16:51, Darin Fisher da...@chromium.org wrote: Can you hide this behind adoptNode just as we did for magic iframe? The nice thing about adoptNode is that the browser gets told both the source and destination parent nodes. This way there is never a disconnected state. So long as we unload when moving between documents, we should be pretty safe as far as the issues which plagued magic iframe are concerned. -Darin On Thu, Apr 12, 2012 at 12:35 PM, Ojan Vafai o...@chromium.org wrote: We should add a keepalive attribute to iframes that prevents iframes from being unloaded/reloaded when removed from or appended to a document. Similarly, a disconnected iframe with keepalive should load. If the keepalive attribute is removed from a disconnected iframe, then it should unload. I'm not terribly happy with the name 'keepalive', but I can't think of anything better at the moment. As iframes increasingly become the standard way of achieving certain tasks (e.g. sandboxing), it's increasingly important to be able to move them around in the DOM. Right now, to achieve this sort of keepalive behavior, you have to keep the iframe always appended to the document and position it absolutely as the document changes. Ojan
Re: [whatwg] CSP sandbox directive integration with HTML
On Mon, 5 Dec 2011, Adam Barth wrote: I wrote some somewhat goofy text in the CSP spec trying to integrate the sandbox directive with HTML's iframe sandbox machinery. Hixie and I chatted in #whatwg about how best to do the integration. I think Hixie is going to refactor the machinery in the spec to be a bit more generic and to call out to the CSP spec to get the sandbox flags from the CSP policy. This is done now. -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'