On Sun, Jun 1, 2014 at 8:58 AM, Glenn Maynard gl...@zewt.org wrote:
But again, image decoding *can't* be done efficiently in script:
platform-independent code with performance competitive with native SIMD
assembly is a thing of myth. (People have been trying unsuccessfully to do
that since
On Sat, May 31, 2014 at 8:44 AM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sat, May 31, 2014 at 3:44 AM, Justin Novosad ju...@google.com wrote:
My point is, we need a proper litmus test for the just do it in script
argument because, let's be honnest, a lot of new features being added
On Sat, May 31, 2014 at 1:46 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, May 30, 2014 at 1:25 PM, Justin Novosad ju...@google.com wrote:
I think this proposal falls short of enshrining. The cost of adding this
feature is minuscule.
I don't think the cost is ever really miniscule.
On Mon, Jun 2, 2014 at 10:05 AM, Justin Novosad ju...@google.com wrote:
On Sat, May 31, 2014 at 8:44 AM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Sat, May 31, 2014 at 3:44 AM, Justin Novosad ju...@google.com
wrote:
My point is, we need a proper litmus test for the just do it in
On Mon, Jun 2, 2014 at 10:16 AM, Justin Novosad ju...@google.com wrote:
On Sat, May 31, 2014 at 1:46 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, May 30, 2014 at 1:25 PM, Justin Novosad ju...@google.com
wrote:
I think this proposal falls short of enshrining. The cost of adding this
On Mon, Jun 2, 2014 at 12:49 PM, Rik Cabanier caban...@gmail.com wrote:
That's implementation cost to you :-)
Now we need to convince the other vendors. Do they want it, want more, want
it in a different way?
Then it needs to be documented. How can authors discover that this is
supported?
On Sat, May 31, 2014 at 3:44 AM, Justin Novosad ju...@google.com wrote:
My point is, we need a proper litmus test for the just do it in script
argument because, let's be honnest, a lot of new features being added to
the Web platform could be scripted efficiently, and that does not
necessarily
On Fri, May 30, 2014 at 1:25 PM, Justin Novosad ju...@google.com wrote:
I think this proposal falls short of enshrining. The cost of adding this
feature is minuscule.
I don't think the cost is ever really miniscule.
True, you'd never want to use toDataURL with a compression operation
On Sat, May 31, 2014 at 10:46 AM, Glenn Maynard gl...@zewt.org wrote:
On Fri, May 30, 2014 at 1:25 PM, Justin Novosad ju...@google.com wrote:
I think this proposal falls short of enshrining. The cost of adding this
feature is minuscule.
I don't think the cost is ever really miniscule.
On Sat, May 31, 2014 at 4:00 PM, Rik Cabanier caban...@gmail.com wrote:
roc was asking which NEW feature is being added that can be done in
script.
He asked which new features have already been added that can be done
efficiently in script. Element.closest() was added less than a week ago.
On Sat, May 31, 2014 at 4:06 PM, andreas@gmail.com wrote:
Does SIMD support in JS change this equation?
Glenn is asking how much more compression there is to gain from this extra
parameter and how much extra processing it requires.
He's not asking how long it would take to do it in
Backtracking here.
The just do it in script argument saddens me quite a bit. :-(
I don't agree that it is okay to be in a state where web apps have to
depend on script libraries that duplicate the functionality of existing Web
APIs. I mean, we put a lot of effort into avoiding introducing
On Fri, May 30, 2014 at 8:44 AM, Justin Novosad ju...@google.com wrote:
Backtracking here.
The just do it in script argument saddens me quite a bit. :-(
I don't agree that it is okay to be in a state where web apps have to
depend on script libraries that duplicate the functionality of
On Fri, May 30, 2014 at 5:44 PM, Justin Novosad ju...@google.com wrote:
The just do it in script argument saddens me quite a bit. :-(
Agreed, however for this particular case, I'm not sure it makes much
sense to further enshrine a synchronous API for serializing an image.
--
On Fri, May 30, 2014 at 12:46 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Fri, May 30, 2014 at 5:44 PM, Justin Novosad ju...@google.com wrote:
The just do it in script argument saddens me quite a bit. :-(
Agreed, however for this particular case, I'm not sure it makes much
sense to
On Fri, May 30, 2014 at 1:59 PM, Glenn Maynard gl...@zewt.org wrote:
On Fri, May 30, 2014 at 12:46 PM, Anne van Kesteren ann...@annevk.nl
wrote:
On Fri, May 30, 2014 at 5:44 PM, Justin Novosad ju...@google.com wrote:
The just do it in script argument saddens me quite a bit. :-(
Agreed,
On Wed, May 28, 2014 at 10:36 PM, Noel Gordon noel.gor...@gmail.com wrote:
canvas.toDataURL supports an optional quality argument for the
“image/jpeg” mime type to control image compression. Developers have no
control over “image/png” compression.
“image/png” is a lossless image compression
On Thu, May 29, 2014 at 1:32 AM, Rik Cabanier caban...@gmail.com wrote:
This has been requested before. ie
http://lists.whatwg.org/pipermail/help-whatwg.org/2013-May/001209.html
The conclusion was that this can be accomplished using JavaScript. There
are JS libraries that can compress images
On Thu, May 29, 2014 at 9:59 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, May 29, 2014 at 1:32 AM, Rik Cabanier caban...@gmail.com wrote:
This has been requested before. ie
http://lists.whatwg.org/pipermail/help-whatwg.org/2013-May/001209.html
The conclusion was that this can be
On Thu, May 29, 2014 at 7:45 AM, Justin Novosad ju...@google.com wrote:
On Thu, May 29, 2014 at 9:59 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, May 29, 2014 at 1:32 AM, Rik Cabanier caban...@gmail.com wrote:
This has been requested before. ie
On Thu, May 29, 2014 at 6:59 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, May 29, 2014 at 1:32 AM, Rik Cabanier caban...@gmail.com wrote:
This has been requested before. ie
http://lists.whatwg.org/pipermail/help-whatwg.org/2013-May/001209.html
The conclusion was that this can be
On Thu, May 29, 2014 at 11:21 AM, Rik Cabanier caban...@gmail.com wrote:
On Thu, May 29, 2014 at 7:45 AM, Justin Novosad ju...@google.com wrote:
On Thu, May 29, 2014 at 9:59 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, May 29, 2014 at 1:32 AM, Rik Cabanier caban...@gmail.com
wrote:
On Thu, May 29, 2014 at 8:50 AM, Justin Novosad ju...@google.com wrote:
On Thu, May 29, 2014 at 11:21 AM, Rik Cabanier caban...@gmail.com wrote:
On Thu, May 29, 2014 at 7:45 AM, Justin Novosad ju...@google.com wrote:
On Thu, May 29, 2014 at 9:59 AM, Glenn Maynard gl...@zewt.org wrote:
On Thu, May 29, 2014 at 10:29 AM, Rik Cabanier caban...@gmail.com
javascript:_e(%7B%7D,'cvml','caban...@gmail.com'); wrote:
If performance is good, why would this not be acceptable?
I don't know why we'd provide an API to compress PNGs, then tell people to
use a script reimplementation if
On Thu, May 29, 2014 at 12:17 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, May 29, 2014 at 10:29 AM, Rik Cabanier caban...@gmail.com wrote:
If performance is good, why would this not be acceptable?
I don't know why we'd provide an API to compress PNGs, then tell people
to use a script
On Thu, May 29, 2014 at 1:33 PM, Rik Cabanier caban...@gmail.com wrote:
On Thu, May 29, 2014 at 12:17 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, May 29, 2014 at 10:29 AM, Rik Cabanier caban...@gmail.com
wrote:
If performance is good, why would this not be acceptable?
I don't
On Thu, May 29, 2014 at 3:33 PM, Rik Cabanier caban...@gmail.com wrote:
MMX, SSE is being addressed using asm.js.
Assembly language is inherently incompatible with the Web.
We already have an API for compressing images, and compression level is
an ordinary input to image compressors, yet
On 5/29/14, 5:13 PM, Glenn Maynard wrote:
Assembly language is inherently incompatible with the Web.
A SIMD API, however is not. Under the hood, it can be implemented in
terms of MMX, SSE, NEON, or just by forgetting about the SIMD bit and
pretending like you have separate operations. In
On Thu, May 29, 2014 at 4:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/29/14, 5:13 PM, Glenn Maynard wrote:
Assembly language is inherently incompatible with the Web.
A SIMD API, however is not. Under the hood, it can be implemented in
terms of MMX, SSE, NEON, or just by forgetting
On Thu, May 29, 2014 at 2:28 PM, Glenn Maynard gl...@zewt.org wrote:
On Thu, May 29, 2014 at 4:21 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 5/29/14, 5:13 PM, Glenn Maynard wrote:
Assembly language is inherently incompatible with the Web.
A SIMD API, however is not. Under the
On Thu, May 29, 2014 at 4:50 PM, Rik Cabanier caban...@gmail.com wrote:
You don't need to hope for it. The future is already here:
http://www.j15r.com/blog/2014/05/23/Box2d_2014_Update
asm.js will be fast on all modern browsers before this feature would ship.
As an author, I'd certainly
Glenn Maynard gl...@zewt.org writes:
We have an API for compression already. It already supports a
compression level argument for JPEG. Having an equivalent argument
for PNG is a no-brainer. The only difference to JPEG is that it
should be described as the compression level rather than
On 29.05.2014, at 23:19, Glenn Maynard gl...@zewt.org wrote:
Anyway, this has derailed the thread. We have an API for compression
already. It already supports a compression level argument for JPEG.
Having an equivalent argument for PNG is a no-brainer. The only
difference to JPEG is that
On Thu, May 29, 2014 at 5:34 PM, Nils Dagsson Moskopp
n...@dieweltistgarnichtso.net wrote:
and time it takes to compress.
What benefit does it give then if the result is the same perceptually?
Time it takes to compress. There's a big difference between waiting one
second for a quick save
canvas.toDataURL supports an optional quality argument for the
“image/jpeg” mime type to control image compression. Developers have no
control over “image/png” compression.
“image/png” is a lossless image compression format and the proposal is to
allow developers some control over the compression
35 matches
Mail list logo
