Re: [whatwg] Java language bindings for HTML5
On Fri, May 21, 2010 at 9:09 PM, Boris Zbarsky wrote: > On 5/21/10 1:34 AM, Shiki Okasaka wrote: >> >> * backward binary compatibility: the application programs developed >> with the former SDKs should run with browsers as long as browsers >> retain the required features for ECMAScript. > > Gecko has this now for DOM interfaces, mostly. It's a noticeable > performance and memory penalty, especially as features need to be added, due > to the way it's implemented right now on top of C++ vtables. As Benjamin > mentioned, we will most likely stop doing this by default for the core DOM > interfaces. Someone could still provide a stable ABI in some form of C++ > binding, but it's not clear to me that we plan to do that ourselves. > Patches accepted, probably. Thanks for the comment, Boris. I guess a solution would be somewhere between the ABI like this one and NPAPI. Have you blogged about new ideas? If so, I would appreciate the pointers. - Shiki > -Boris >
Re: [whatwg] Image resize API proposal
I've improved the accuracy of the canvas (resize/copy/rotate) perf test: http://webkit.org/demos/canvas-perf/canvas.html Here are some results in a similar format to what Mike posted ( http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2010-March/025590.html): Firefox 3.7a4 (no D2D) Direct image copy: 39ms Indirect copy with (via ImageData): 160ms Copy with 2x scale: 646.5ms Copy with 0.5x scale: 42.5ms Copy with rotate: 358ms Firefox 3.7a4 (D2D) Direct image copy: 115ms Indirect copy with (via ImageData): 365.5ms Copy with 2x scale: 246ms Copy with 0.5x scale: 48.5ms Copy with rotate: 100.5ms Chrome 4.1.249.1064 (45376) Direct image copy: 32.5ms Indirect copy with (via ImageData): 207.5ms Copy with 2x scale: 378.5ms Copy with 0.5x scale: 27.5ms Copy with rotate: 367ms While the GPU does help in some scenarios, unfortunately it must still take some time to do its work, so it doesn't enable us to do sync apis that don't hang the UI. Feel free to run the test yourself and look at the code. Best wishes, Dave
Re: [whatwg] Installable web apps
This is what I had assumed. I love the idea. However, I think installation is a bad metaphor, given that users will have preconceived notions about what installation means, namely that installed apps live on their machine and are under their control (for the most part). On May 25, 2010, at 10:33 AM, Anne van Kesteren wrote: > On Tue, 25 May 2010 16:12:44 +0200, Simpson, Grant Leyton > wrote: >> One question I have off the top of my head is how updates are handled. I >> like the idea of better integration with the OS and the browser but I >> don't want to lose one of what I see as the best elements of web app >> development, namely the need to not have to update clients' copies of >> the app individually. > > Presumably the "installed" app would still be delivered over HTTP; > potentially with a lot of offline data through storage and a cache > manifest. "installed" seems to be just a bit on top of what we have > already that gives a few extra features. At least that's what I make out > of the rough summary. > > > -- > Anne van Kesteren > http://annevankesteren.nl/
Re: [whatwg] Installable web apps
On Tue, 25 May 2010 16:12:44 +0200, Simpson, Grant Leyton wrote: One question I have off the top of my head is how updates are handled. I like the idea of better integration with the OS and the browser but I don't want to lose one of what I see as the best elements of web app development, namely the need to not have to update clients' copies of the app individually. Presumably the "installed" app would still be delivered over HTTP; potentially with a lot of offline data through storage and a cache manifest. "installed" seems to be just a bit on top of what we have already that gives a few extra features. At least that's what I make out of the rough summary. -- Anne van Kesteren http://annevankesteren.nl/
Re: [whatwg] Installable web apps
One question I have off the top of my head is how updates are handled. I like the idea of better integration with the OS and the browser but I don't want to lose one of what I see as the best elements of web app development, namely the need to not have to update clients' copies of the app individually. On May 24, 2010, at 4:45 PM, Aaron Boodman wrote: > This has come up before, but since Google has officially announced the > project at IO, and Mozilla has voiced interest in the idea on their > blog, I felt like it might be a good to revisit. > > Google would like to make today's web apps "installable" in Chrome. >> From a user's point of view, installing a web app would: > > - Give it a permanent access point in the browser with a big juicy icon > - Allow the browser to treat a web app as a conceptual unit (eg give > it special presentation, show how much storage it uses) > - Add some light integration with the OS > - (optionally) Pre-grant some permissions that would otherwise have to > be requested one-at-a-time (eg geolocation, notifications) > - (optionally) Grant access to some APIs that would otherwise be > inaccessible (eg system clipboard, permanent storage) > > There is some more background on our thinking at these two URL: > > http://code.google.com/chrome/apps/ > http://code.google.com/chrome/apps/docs > > We have started implementing this using Chrome's current extension > system. However, we'd like it if installation could eventually work in > other browsers. Is there any interest from other vendors in > collaborating on the design of such a system? > > Thanks, > > - a
Re: [whatwg] Image resize API proposal
On May 25, 2010, at 3:58 AM, Kornel Lesinski wrote: > On 24 May 2010, at 22:09, David Levin wrote: > >>> that even if it was implemented everywhere, this solution involves readback >>> from the GPU which, as Chris mentioned, is generally evil and should be >>> avoided at all costs. >> >> This I'm not qualified to comment on, though. To the best of my >> knowledge, GPUs are magical boxes that make things go faster via pixie >> dust. ;) >> >> Thanks for your opinion. :) >> >> Chris is qualified so are other people whom I've spoken to who have said the >> same thing, so using the gpu is not pixie dust in this particular scenario >> even though folks would like to be believe it so. > > I think GPU readback is a red herring. It's an operation that takes > milliseconds. It's "slow" for realtime graphics, but it's not something that > user is going to notice when uploading images — users are not uploading > hundreds of images per second. It's not a red herring. Readback performance has nothing to do with how fast pixels can be read from the GPU. As it turns out reading from a GPU is somewhat slower than writing but you're right that it's only a few ms. The problem is that GPU's are heavily pipelined. You can add lots of commands to the input queue and have them executed much later, without you waiting around. As soon as a readback comes in, all those pipelined commands have to executed and during this time no other commands can be accepted. All users of the GPU (and there are many users other than you) sit and wait, including you. When all the commands are flushed, your readback is done, then all those waiting get their commands submitted and eventually executed. If you're doing this for several images, it's even worse. Your readbacks will get interleaved with all the other command submissions, so you'll be stalling the pipe several times (as opposed to doing all your readbacks together). The flushes make readback slower than just copying the pixels and it makes every operation slower for every GPU user. There are times when you have no choice but to do readback. But the API should be designed so that it can be avoided whenever possible. It's simply evil :-) - ~Chris cmar...@apple.com
Re: [whatwg] Image resize API proposal
On May 24, 2010, at 2:09 PM, David Levin wrote: > > > On Mon, May 24, 2010 at 1:40 PM, Aryeh Gregor > wrote: > On Mon, May 24, 2010 at 1:21 PM, David Levin wrote: > > We've discussed the leading alternate proposal optimized canvas (plus js to > > read the exif information) and then get the bits out of canvas, but there > > are several issues with this proposal including > > > > that not all browsers will have an implementation using the gpu that allows > > web sites to use this and not hang the UI > > This is a nonissue. There's no point in speccing one feature to work > around the fact that browsers haven't implemented another -- it makes > more sense to just get the browsers to implement the latter feature, > making the former moot. Browsers look like they're moving toward GPU > acceleration for everything now, and that has many more benefits, so > we should assume that by the time they'd implement this API, they'll > already be GPU-accelerated. > > > that even if it was implemented everywhere, this solution involves readback > > from the GPU which, as Chris mentioned, is generally evil and should be > > avoided at all costs. > > This I'm not qualified to comment on, though. To the best of my > knowledge, GPUs are magical boxes that make things go faster via pixie > dust. ;) > > Thanks for your opinion. :) > > Chris is qualified so are other people whom I've spoken to who have said the > same thing, so using the gpu is not pixie dust in this particular scenario > even though folks would like to be believe it so. I didn't mean to say that GPU's are in general evil, just readback. GPU's can do magical things as long as you keep the data there. If your API were to return some abstract wrapper around the resultant image (Like ImageData), it would allow the bits to stay on the GPU. Then you can use the abstract API to pass the image around, render with it, whatever. There might still be some platforms that have to read the pixels back to use them, but not always. For instance, WebGL has API to take an ImageData and load it as a texture. If we see the image from that object are already in the GPU, we can use it directly or copy it (GPU-GPU copies are very fast) to the texture memory. I'm not sure such a representation is appropriate for all the use cases here, but it would make image handler much faster in many cases. - ~Chris cmar...@apple.com
Re: [whatwg] Image resize API proposal
On 24 May 2010, at 22:09, David Levin wrote: > > that even if it was implemented everywhere, this solution involves readback > > from the GPU which, as Chris mentioned, is generally evil and should be > > avoided at all costs. > > This I'm not qualified to comment on, though. To the best of my > knowledge, GPUs are magical boxes that make things go faster via pixie > dust. ;) > > Thanks for your opinion. :) > > Chris is qualified so are other people whom I've spoken to who have said the > same thing, so using the gpu is not pixie dust in this particular scenario > even though folks would like to be believe it so. I think GPU readback is a red herring. It's an operation that takes milliseconds. It's "slow" for realtime graphics, but it's not something that user is going to notice when uploading images — users are not uploading hundreds of images per second. If UA can parallelize decoding, scaling, encoding and sending, the operation can be very fast and memory-efficient, even if scaling is done very slowly (it won't have noticeable impact as long as it's not slower than uploading). JPEG can be efficiently decoded at fraction of its size — without full decode and scale process. This process also needs only fraction of memory required for full scaling, which might matter on low-end mobile devices. Letting UA utilize this feature may give huge performance gains. Scaling isn't the only operation desirable — in some cases users might also want to crop the image (e.g., to upload only their face as an avatar), and cropping interface needs to be platform-specific — on touchscreen devices I'd rather use gestures than select-by-click'n'drag interface typical for desktop. I think scaling of images before upload might be left completely up to UA. From site's perspective it could look like user simply selected scaled-down file. It could even be done declaratively — site could define desired size and whether user should be asked to crop the image: Actually, I wish UAs offered scaling even for plain , because I don't expect every site with image upload to add extra code for resizing. -- regards, Kornel
