Re: [FileAPI] createObjectURL isReusable proposal
On 28.1.2012 7:10, Darin Fisher wrote: On Wed, Dec 14, 2011 at 4:40 PM, Ian Hickson i...@hixie.ch mailto:i...@hixie.ch wrote: On Wed, 14 Dec 2011, Adrian Bateman wrote: [...] the first dereference of the URL revokes it. This means that you can do something like: imgElement.src = URL.createObjectURL(blob,false) and not worry about having to call URL.revokeObjectURL to release the Blob. I think it's dangerous to assume that the URL will only be dereferenced once. For example, it would mean that the above image would break if the user toggled images off and back on in a browser that discarded image data when the user toggles images off. It would mean that you couldn't clone the element and get the image data in the clone. It would mean that you couldn't read the image's .src URL and have anything useful. I share your concerns. This is enough reason to make me not want to support the one-shot flag. That said, I'm greatly bothered by how easily createObjectURL makes it to create web apps that accumulate mass amounts of unreleased and unused memory. Most examples gloss over revokeObjectURL entirely. The idea of just letting these blobs accumulate until the document is destroyed is really unsatisfying. A growing number of apps have very long-lived main documents. What if createObjectURL were somehow scoped to an Element in the DOM (not just the Document itself)? For AJAX apps that are creating and tearing down DOM snippets frequently, if the blob URLs needed for a particular view were bound to elements in that view, then perhaps there would be a more natural cleansing of the blob URL registry. I'm not sure what a concrete proposal would look like. Maybe Element.URL.createObjectURL or just Element.createObjectURL? -Darin I think the better solution is to have implementations make keeping object URLs defined be very cheap, so that nobody needs to ever release them. Those concerns would make sense if this was the only solution, but one can always stick with create/revoke approach, if you know, you do not (and most likely will not) need URL, just one-time method, if you know you would need it, or it is highly possible, use create/revoke. If you use one-time method but will try to reuse such URL, you've made programming error, this is not language/API fault. Brona
Re: Image.toBlob()
2012/1/28 Bronislav Klučka bronislav.klu...@bauglir.com Hello, would it be possible to have Image.toBlob() function? We are introducing Canvas.toBlob(), image (and maybe video, audio) would be nice addition Brona Proposing a more detailed spec would be a good place to start. Some example questions: 1. What does img.toBlob() do if the image failed to load? 2. Should img.toBlob() respect CORS? 3. Does img.toBlob() take a content type argument like the others? If so, what does img src=foo.jpg.toBlob(image/png) do? 4. Is img.toBlob() asynchronous like canvas.toBlob()? I think the idea of implementing img.toBlob() is fine, but we need to spec out the behavior first. - Kyle
Re: Image.toBlob()
On 28.1.2012 10:19, Kyle Huey wrote: 2012/1/28 Bronislav Klučka bronislav.klu...@bauglir.com mailto:bronislav.klu...@bauglir.com Hello, would it be possible to have Image.toBlob() function? We are introducing Canvas.toBlob(), image (and maybe video, audio) would be nice addition Brona Proposing a more detailed spec would be a good place to start. Some example questions: 1. What does img.toBlob() do if the image failed to load? 2. Should img.toBlob() respect CORS? 3. Does img.toBlob() take a content type argument like the others? If so, what does img src=foo.jpg.toBlob(image/png) do? 4. Is img.toBlob() asynchronous like canvas.toBlob()? I think the idea of implementing img.toBlob() is fine, but we need to spec out the behavior first. - Kyle Sure, sure just throwing the idea here. I think whatever can be followed according to existing should be (the same signature as Canvas.toBlob, respecting crossorigin attribute, CORS) If there is failure possible in Canvas.toBlob(), this method should follow it, if not, error should be thrown once called on error image img src=foo.jpg.toBlob(image/png) should return PNG Basically the idea is, that this should replace for creating canvas, painting image on such canvas and calling canvas.toBlob(). Brona
Re: [FileAPI] createObjectURL isReusable proposal
On Fri, Jan 27, 2012 at 6:14 PM, Glenn Maynard gl...@zewt.org wrote:
Something else that needs to be defined: does xhr.open('GET', url)
consume the URL, or does that only happen when xhr.send() is called? (I'm
not looking for the answer here, just giving an example of something that
needs to be clearly defined.)
Another case: whether loading a one-shot URL from a different origin, where
you aren't allowed to load the content, still causes the URL to be revoked.
(My first impression was that it shouldn't affect it at all, but my second
impression is that in practice that error mode would probably always result
in the URL never being revoked and ending up leaked, so it's probably best
to free it anyway.)
--
Glenn Maynard
Re: [xhr] responseType for sync requests in window context
2012/1/26 Mark Callow callow_m...@hicorp.co.jp I do not think you should be in the business of brute-forcing authors into converting their applications to use async XHRs. As far as I understand it, it is the application's UI that may be unresponsive during a sync XHR. In that case it should be the app. authors choice which to use. If it is the browser's UI, that is a bug in the browser. The point is to only affect XHR when new features are used, so the amount of affected existing code is small. Since this change principally affects WebGL app's it would have been nice of someone to have mentioned this change in the public-webgl mailing list while it was still at the proposal stage. There's nothing WebGL-specific about it, so there's no reason anyone would raise it on WebGL lists. For the record the change has broken all our WebGL applications. Forcing us to jump through the hoops of using async XHRs is going to have zero impact on the user experience in our case because the 3D itself is the UI. Until its loaded there is nothing the user can do. Of course it impacts the user's experience. You can't open context menus in most browsers; in Chrome you can't hit browser back; browser UI for the tab in general simply pauses. You can't do a lot of things while a sync XHR is taking place, because they require doing things that, both per spec and sane API design, can only take place during the event loop and not while JavaScript code is executing. If sync XHRs are so bad, why to they exist? Because they were added long ago, before browser developers figured out that sync APIs in the UI thread are bad. There's a reason no new APIs outside of workers have sync interfaces. -- Glenn Maynard
Re: [xhr] responseType for sync requests in window context
Please keep in mind that multiple web apps share the same main thread. While browser's can keep their own UI responsive in the face of synchronous XHRs, they cannot do the same for other web app, which may share their main thread with a web app that uses synchronous XHR. Unfortunately, the web platform is a cooperatively multi-tasking system :-( This applies even to browsers like Chrome that create multiple processes. There you can still end up with unrelated web apps in the same process, sharing the same main thread. Now, I have to admit that I'm quite sympathetic to your concerns. I think it is always bad form for a platform to give an API and then take it away. At least one nice thing about switching to async XHRs is that you can now display a progress meter to your users. There's no telling how long a network load may take afterall. Regards, -Darin On Thu, Jan 26, 2012 at 7:47 PM, Mark Callow callow_m...@hicorp.co.jpwrote: I do not think you should be in the business of brute-forcing authors into converting their applications to use async XHRs. As far as I understand it, it is the application's UI that may be unresponsive during a sync XHR. In that case it should be the app. authors choice which to use. If it is the browser's UI, that is a bug in the browser. Since this change principally affects WebGL app's it would have been nice of someone to have mentioned this change in the public-webgl mailing list while it was still at the proposal stage. For the record the change has broken all our WebGL applications. Forcing us to jump through the hoops of using async XHRs is going to have zero impact on the user experience in our case because the 3D itself is the UI. Until its loaded there is nothing the user can do. If sync XHRs are so bad, why to they exist? Regards -Mark
Re: [FileAPI] createObjectURL isReusable proposal
Why though? What stops UAs from accepting the relevant objects for .src properties? - Kyle On Sat, Jan 28, 2012 at 2:47 AM, Ian Hickson i...@hixie.ch wrote: On Sat, 28 Jan 2012, Kyle Huey wrote: On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher da...@chromium.org wrote: I'm not sure what a concrete proposal would look like. Maybe Element.URL.createObjectURL or just Element.createObjectURL? Wouldn't returning an object (which can be GCd) be a better solution? The whole point of the API is that we have an object but need a string (a URL). -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [FileAPI] createObjectURL isReusable proposal
It's reference issue img.src = URL.createObjectUrl(blob) means, that you cannot GC that blob, because URL is just text representation of reference. img.src = URL.createObjectUrl(blob, true) means, that you can GC that blob, because once URL is dereferenced, it will not be dereferenced again (BLOB data are used just here) and unless there is another reference to such blob, GC can get rid of it img.src = blob; tells nothing about possible access to underlying data using URL identifier Brona On 29.1.2012 4:31, Kyle Huey wrote: Why though? What stops UAs from accepting the relevant objects for .src properties? - Kyle On Sat, Jan 28, 2012 at 2:47 AM, Ian Hickson i...@hixie.ch mailto:i...@hixie.ch wrote: On Sat, 28 Jan 2012, Kyle Huey wrote: On Sat, Jan 28, 2012 at 7:10 AM, Darin Fisher da...@chromium.org mailto:da...@chromium.org wrote: I'm not sure what a concrete proposal would look like. Maybe Element.URL.createObjectURL or just Element.createObjectURL? Wouldn't returning an object (which can be GCd) be a better solution? The whole point of the API is that we have an object but need a string (a URL).
