Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Fri, Mar 12, 2010 at 10:07 PM, Maciej Stachowiak m...@apple.com wrote: On Mar 12, 2010, at 6:20 PM, Jonas Sicking wrote: Oh, another thing to keep in mind is that if/when we add fromBlob to the main-thread canvas, it has to be asynchronous in order to avoid main thread synchronous IO. This isn't a big deal, but I figured I should mention it while we're on the subject. This is part of why I think Blob is the wrong tool for the job - we really want to use a data type here that can promise synchronous access to the data. When you copy the canvas backing store to a new in-memory representation, it seems silly to put that behind an interface that's the same as data to which you can only promise async access, such as part of a file on disk. There's nothing about copying bits from one canvas to another that needs to be async. (Also it's not clear to me why a Blob would be faster to copy from, copy to, or copy cross-thread than ImageData; I thought the motivation for adding it was to have a binary container that can be uploaded to a server via XHR.) There is a use case, which I suspect is quite common, for using canvas to manipulate files on the users file system. For example when creating a photo uploader which does client side scaling before uploading the images, or for creating a web based GIMP like application. In this case we'll start out with a File object that needs to be read in to a canvas. One solution could be to read the File into memory in a ByteArray (or similar) and add a synchronous canvas2dcontext.fromByteArray function. This has the advantage of being more generic, but the downside of forcing both the encoded and decoded image to be read into memory. This is why I suggested adding a asynchronous fromBlob function. For extracting image data from a canvas I agree that a toBlob function has little advantage over a toByteArray function (with the possible exception that ByteArray so far is still vapor ware). In general I wonder if we should add API to convert directly between Blob and ImageData. Or at least Blob-ImageData and ImageData-ByteArray. That could avoid overhead of going through a canvas context. That is probably a win no matter which thread we are on. We could even add APIs to rotate and scale ImageData objects directly. If those are asynchronous the implementation could easily implement them using a background thread. I'm less sure that this is worth it though given that you can implement this yourself using workers if we add the other stuff we've talked about. Scaling and rotation can be done with just pixels if you code it by hand, but you can get native code to do it for you if you can manipulate actually offscreen buffers - you just establish the appropriate transform before painting the ImageData. REally the question is, how much slower is a scaling or rotating image paint than an image paint with the identity transform? Is it more than twice as expensive? That's the only way copying image data to a background thread will give you a responsiveness win. I'd like to see some data to establish that this is the case, if scales and rotates are the only concrete use cases we have in mind. I agree that data would be great. Though for scaling I suspect that it's complicated enough that it's worth exposing *some* built in API for doing it. Especially considering that you want to use anti aliasing and ideally things like gamma correction. Be that through what we already have on 2d context, or on ImageData directly. / Jonas
Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Mar 13, 2010, at 9:10 AM, Jonas Sicking wrote: There is a use case, which I suspect is quite common, for using canvas to manipulate files on the users file system. For example when creating a photo uploader which does client side scaling before uploading the images, or for creating a web based GIMP like application. In this case we'll start out with a File object that needs to be read in to a canvas. One solution could be to read the File into memory in a ByteArray (or similar) and add a synchronous canvas2dcontext.fromByteArray function. This has the advantage of being more generic, but the downside of forcing both the encoded and decoded image to be read into memory. Honestly i think nice and consistent way for this work work would simply be to support someImage.src = someFileObject Which would be asynchronous, and support all the image formats the browser already supports. This is why I suggested adding a asynchronous fromBlob function. For extracting image data from a canvas I agree that a toBlob function has little advantage over a toByteArray function (with the possible exception that ByteArray so far is still vapor ware). CanvasPixelArray is a ByteArray to all intents and purposes, and webkit and i _think_ opera implement it as such. It would of course be good just to get all the native array types into ES, and then make WebLG + Canvas make use of those directly, and i doubt that is something we'll need to wait too long for. --Oliver
Re: [whatwg] Offscreen canvas (or canvas for web workers).
On Sat, Mar 13, 2010 at 12:09 PM, Oliver Hunt oli...@apple.com wrote: On Mar 13, 2010, at 9:10 AM, Jonas Sicking wrote: There is a use case, which I suspect is quite common, for using canvas to manipulate files on the users file system. For example when creating a photo uploader which does client side scaling before uploading the images, or for creating a web based GIMP like application. In this case we'll start out with a File object that needs to be read in to a canvas. One solution could be to read the File into memory in a ByteArray (or similar) and add a synchronous canvas2dcontext.fromByteArray function. This has the advantage of being more generic, but the downside of forcing both the encoded and decoded image to be read into memory. Honestly i think nice and consistent way for this work work would simply be to support someImage.src = someFileObject Which would be asynchronous, and support all the image formats the browser already supports. That is already possible: someImage.src = someFileObject.urn; However this brings us back to the very long list of steps I listed earlier in this thread. / Jonas
Re: [whatwg] Lifting cross-origin XMLHttpRequest restrictions?
On 3/12/2010 3:41 PM, Anne van Kesteren wrote: On Fri, 12 Mar 2010 08:35:48 +0100, Brett Zamir bret...@yahoo.com wrote: My apologies if this has been covered before, or if my asking this is a bit dense, but I don't understand why there are restrictions on obtaining data via XMLHttpRequest from other domains, if the request could be sandboxed to avoid passing along sensitive user data like cookies (or if the user could be asked for permission, as when installing browser extensions that offer similar privileges). Did you see http://dev.w3.org/2006/webapi/XMLHttpRequest-2/ http://dev.w3.org/2006/waf/access-control/ ? I have now, thanks. :) Though I regrettably don't have a lot of time now to study it as deeply as I'd like (nor Michal Zalewski's reference to UMP), and I can't speak to the technical challenges of browsers (and their plug-ins) implementing the type of sandboxing that would be necessary for this if they don't already, I was just hoping I could articulate interest in finding a way to overcome if possible, and question whether the security challenges could be worked around at least in a subset of cases. While I can appreciate such goals as trying to prevent dictionary-based, distributed, brute-force attacks that try to get login accounts to 3^rd party servers mentioned in the CORS spec and preventing spam or opening accounts on behalf of users and the like, I would think that at least GET/HEAD/OPTIONS requests should not be quite as important an issue. As far as the issue Michal brought up about the client's IP being sent, I might think this problem could be mitigated by a client header being added to indicate the domain of origin behind the request. It's hard to lay the blame on the client for a DoS if it is known which server was initiating. (Maybe this raises some privacy issues, as the system would make known who was visiting the initiating site, but I'd think A) this info could be forged anyways, and B) any site could publish its visitors anyways.) I'll admit this might make things more interesting legally though, e.g., whether the client shared some or all responsibility, for DoS or copyright violations, especially if interface interaction controlled the number of requests. But as far the burden on the user, if the user is annoyed that their browser is being slowed as a result of requests made on their behalf (though I'm not sure how much work it would save given that the server still has to maintain a connection), they can close the tab/window, or maybe the browser could offer to selectively disable such requests or request permission. I would think that the ability for clients to help a server crawl the internet might even potentially be a feature rather than a bug, allowing a different kind of proxy opportunity for server hosts which are in countries with blocked access. Besides this kind of reverse proxy (to alter the phrase), I wouldn't think it would be that compelling for sites to outsource their crawling (except maybe as a very insecure and unpredictably accessible backup or caching service!), since they'd have to retrieve the information anyways, but again I can't see what harm there would really be in it, except that addressing DoS plans would need to address an additional header. I apologize for not being able to research this more carefully, but I was just hoping to see if there might be some way to allow at least a safer subset of requests like GET and HEAD by default. Akin to the rationales behind my proposal for browser support of client-side XQuery, including as a content type (at http://brett-zamir.me/webmets/index.php?title=DrumbeatDescription ), it seems to me that users could really benefit from such capacity in client-side JavaScript, not only for the sake of greater developer options, but also for encouraging greater experimentation of mash-ups, as the mash-up server is not taxed with having to obtain the data sources (nor tempted to store stale copies of the source data nor perhaps be as concerned with the need to obtain republishing permissions). Servers are already free to obtain and mix in content from other sites, so why can't client-side HTML JavaScript be similarly empowered? Because you would also have access to e.g. IP-authenticated servers. As suggested above, could a header be required on compliant browsers to send a header along with their request indicating the originating server's domain? best wishes, Brett
Re: [whatwg] Lifting cross-origin XMLHttpRequest restrictions?
As suggested above, could a header be required on compliant browsers to send a header along with their request indicating the originating server's domain? Yes, but it's generally a bad practice to release new features that undermine the security of existing systems, and requiring everybody to change their code to account for the newly introduced vectors. Theoretically, GET or OPTIONS should have no side effects, so DoS potential aside, they could be permitted with no special security checks. In practice, much of the Internet uses GET for state-changing actions; or nominally uses POSTs, but does not differentiate between the two in any specific way; plus, the problem of IP auth / Intranet probing remains. Bottom line is, opt-in is offered in several other places; and opt-out solution seems unlikely at this point, I would think? /mz
