On Mon, Mar 15, 2010 at 3:05 AM, Maciej Stachowiak wrote:
> === Summary of Data ===
>
> 1) In all browsers tested, copying to an ImageData and then back to a canvas
> (two blits) is faster than a 2x scale.
> 2) In all browsers tested, twice the cost of a canvas-to-canvas blit is
> considerably les
On Mar 15, 2010, at 2:24 PM, Vladimir Vukicevic wrote:
> If we wanted to support this across workers (and I think it would be helpful
> to figure out how to do so), something like saying that if a canvas object
> was passed (somehow) between workers, it would be a copy -- and internally it
> co
On 3/15/2010 4:22 AM, Maciej Stachowiak wrote:
On Mar 15, 2010, at 3:46 AM, Philip Taylor wrote:
On Mon, Mar 15, 2010 at 7:05 AM, Maciej Stachowiak
wrote:
Copying from one canvas to another is much faster than copying to/from
ImageData. To make copying to a Worker worthwhile as a responsiven
On Mar 15, 2010, at 3:46 AM, Philip Taylor wrote:
On Mon, Mar 15, 2010 at 7:05 AM, Maciej Stachowiak
wrote:
Copying from one canvas to another is much faster than copying to/
from
ImageData. To make copying to a Worker worthwhile as a responsiveness
improvement for rotations or downscales,
On Mon, Mar 15, 2010 at 7:05 AM, Maciej Stachowiak wrote:
> Copying from one canvas to another is much faster than copying to/from
> ImageData. To make copying to a Worker worthwhile as a responsiveness
> improvement for rotations or downscales, in addition to the OffscreenCanvas
> proposal we wou
On Mar 15, 2010, at 12:28 AM, Jonas Sicking wrote:
=== Conclusions ===
1) For scaling an image up 2x, copying to an ImageData and back for
processing on a Worker would improve responsiveness, relative to
just doing
the scale on the main thread.
2) Copying from one canvas to another is much
>> I agree that the number of steps is not important for responsiveness
>> or performance (though it is for complexity). However several of those
>> steps seemed to involved non-trivial amount of CPU usage, that was the
>> concern expressed in my initial mail.
>>
>> At the very least I think we hav
On Mar 14, 2010, at 6:22 PM, Jonas Sicking wrote:
One way to do it would be to have an function somewhere, not
necessarily on the 2D context, which given a Blob, returns an
ImageData object. However this still results in the image being loaded
twice into memory, so would only really help if yo
On Sun, Mar 14, 2010 at 1:43 AM, Maciej Stachowiak wrote:
>
> On Mar 13, 2010, at 12:30 PM, Jonas Sicking wrote:
>
>> On Sat, Mar 13, 2010 at 12:09 PM, Oliver Hunt wrote:
>>>
>>> On Mar 13, 2010, at 9:10 AM, Jonas Sicking wrote:
There is a use case, which I suspect is quite common, for
On Mar 13, 2010, at 12:30 PM, Jonas Sicking wrote:
On Sat, Mar 13, 2010 at 12:09 PM, Oliver Hunt
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
to manipulate files on the users file system. For example
when creating
On Sat, Mar 13, 2010 at 12:09 PM, Oliver Hunt 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
>> to manipulate files on the users file system. For example
>> when creating a photo uploader which does client side scali
On Mar 13, 2010, at 9:10 AM, Jonas Sicking wrote:
> There is a use case, which I suspect is quite common, for using
> 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 base
On Fri, Mar 12, 2010 at 10:07 PM, Maciej Stachowiak 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
On Mar 12, 2010, at 6:20 PM, Jonas Sicking wrote:
On Fri, Mar 12, 2010 at 4:19 PM, Jonas Sicking
wrote:
On Fri, Mar 12, 2010 at 3:38 PM, David Levin
wrote:
On Fri, Mar 12, 2010 at 2:35 PM, Jonas Sicking
wrote:
On Fri, Mar 12, 2010 at 12:46 PM, Oliver Hunt
wrote:
On Mar 12, 201
On Fri, Mar 12, 2010 at 4:19 PM, Jonas Sicking wrote:
> On Fri, Mar 12, 2010 at 3:38 PM, David Levin wrote:
>>
>>
>> On Fri, Mar 12, 2010 at 2:35 PM, Jonas Sicking wrote:
>>>
>>> On Fri, Mar 12, 2010 at 12:46 PM, Oliver Hunt wrote:
>>> >
>>> > On Mar 12, 2010, at 12:16 PM, Jonas Sicking wrote:
On Mar 12, 2010, at 2:35 PM, Jonas Sicking wrote:
On Fri, Mar 12, 2010 at 12:46 PM, Oliver Hunt
wrote:
On Mar 12, 2010, at 12:16 PM, Jonas Sicking wrote:
I'm not saying that the proposed API is bad. It just doesn't seem to
solve the (seemingly most commonly requested) use case of
rotating/
On Fri, Mar 12, 2010 at 3:38 PM, David Levin wrote:
>
>
> On Fri, Mar 12, 2010 at 2:35 PM, Jonas Sicking wrote:
>>
>> On Fri, Mar 12, 2010 at 12:46 PM, Oliver Hunt wrote:
>> >
>> > On Mar 12, 2010, at 12:16 PM, Jonas Sicking wrote:
>> >> I'm not saying that the proposed API is bad. It just doesn
On Fri, Mar 12, 2010 at 2:35 PM, Jonas Sicking wrote:
> On Fri, Mar 12, 2010 at 12:46 PM, Oliver Hunt wrote:
> >
> > On Mar 12, 2010, at 12:16 PM, Jonas Sicking wrote:
> >> I'm not saying that the proposed API is bad. It just doesn't seem to
> >> solve the (seemingly most commonly requested) use
On Fri, Mar 12, 2010 at 12:46 PM, Oliver Hunt wrote:
>
> On Mar 12, 2010, at 12:16 PM, Jonas Sicking wrote:
>> I'm not saying that the proposed API is bad. It just doesn't seem to
>> solve the (seemingly most commonly requested) use case of
>> rotating/scaling images. So if we want to solve those
On Mar 12, 2010, at 12:16 PM, Jonas Sicking wrote:
> I'm not saying that the proposed API is bad. It just doesn't seem to
> solve the (seemingly most commonly requested) use case of
> rotating/scaling images. So if we want to solve those use cases we
> need to either come up with a separate API fo
On Fri, Mar 12, 2010 at 12:16 PM, Jonas Sicking wrote:
> On Fri, Mar 12, 2010 at 11:57 AM, David Levin wrote:
> > On Mon, Feb 22, 2010 at 3:10 PM, Jonas Sicking wrote:
> >>
> >> What is the use case for this? It seems like in most cases you'll want
> >> to display something on screen to the use
On Fri, Mar 12, 2010 at 11:57 AM, David Levin wrote:
> On Mon, Feb 22, 2010 at 3:10 PM, Jonas Sicking wrote:
>>
>> What is the use case for this? It seems like in most cases you'll want
>> to display something on screen to the user, and so the difference
>> comes down to shipping drawing commands
On Mon, Feb 22, 2010 at 11:57 AM, Drew Wilson wrote:
> Do we feel that text APIs are, in general, difficult to implement in a
> multi-thread safe manner?
>
On Mon, Feb 22, 2010 at 11:51 AM, Michael Nordman
wrote:
> The lack of support for text drawing in the worker context seems like a
> shor
On Wed, 24 Feb 2010 16:45:44 +0100, Andrew Grieve
wrote:
How would you do #2 efficiently? If you used toDataUr*l*(), then you
have to
encode a png on one side and then decode the png on the main thread. I
think
we might want to add some sort of API for blitting directly from an
offscreen ca
Regarding the three steps of offscreen rendering:
1. Draw stuff
2. Ship pixels to main thread
3. Draw them on the screen.
How would you do #2 efficiently? If you used toDataUr*l*(), then you have to
encode a png on one side and then decode the png on the main thread. I think
we might want to add
On Feb 24, 2010, at 1:35 AM, Jonas Sicking wrote:
On Wed, Feb 24, 2010 at 12:14 AM, Maciej Stachowiak
wrote:
On Feb 24, 2010, at 12:09 AM, Maciej Stachowiak wrote:
On Feb 23, 2010, at 10:04 PM, Jonas Sicking wrote:
On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak
wrote:
- Raytracin
On Wed, Feb 24, 2010 at 1:35 AM, Jonas Sicking wrote:
> On Wed, Feb 24, 2010 at 12:14 AM, Maciej Stachowiak wrote:
>>
>> On Feb 24, 2010, at 12:09 AM, Maciej Stachowiak wrote:
>>
>> On Feb 23, 2010, at 10:04 PM, Jonas Sicking wrote:
>>
>> On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak wrote:
On Wed, Feb 24, 2010 at 12:14 AM, Maciej Stachowiak wrote:
>
> On Feb 24, 2010, at 12:09 AM, Maciej Stachowiak wrote:
>
> On Feb 23, 2010, at 10:04 PM, Jonas Sicking wrote:
>
> On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak wrote:
>
> - Raytracing a complex scene at high resolution.
>
> - Dra
On Feb 24, 2010, at 12:09 AM, Maciej Stachowiak wrote:
On Feb 23, 2010, at 10:04 PM, Jonas Sicking wrote:
On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak
wrote:
- Raytracing a complex scene at high resolution.
- Drawing a highly zoomed in high resolution portion of the
Mandelbrot set
On Feb 23, 2010, at 10:04 PM, Jonas Sicking wrote:
On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak
wrote:
- Raytracing a complex scene at high resolution.
- Drawing a highly zoomed in high resolution portion of the
Mandelbrot set.
To be fair though, you could compute the pixels for th
On Tue, Feb 23, 2010 at 10:04 PM, Jonas Sicking wrote:
> On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak wrote:
>> - Raytracing a complex scene at high resolution.
>> - Drawing a highly zoomed in high resolution portion of the Mandelbrot set.
>>
>> To be fair though, you could compute the pixe
On Tue, Feb 23, 2010 at 9:57 PM, Maciej Stachowiak wrote:
> - Raytracing a complex scene at high resolution.
> - Drawing a highly zoomed in high resolution portion of the Mandelbrot set.
>
> To be fair though, you could compute the pixels for those with just math,
> there is no need to have a grap
On Feb 23, 2010, at 7:40 AM, Jeremy Orlow wrote:
Note that doing rendering in a worker and then displaying it on the
the main thread also gives you double buffering for no additional
cost. This is something our teams are excited about as well.
While I think the use cases presented for b
On Tue, Feb 23, 2010 at 11:31 AM, Jeremy Orlow wrote:
> On Tue, Feb 23, 2010 at 12:46 AM, Jonas Sicking wrote:
>
>> On Mon, Feb 22, 2010 at 4:34 PM, Jeremy Orlow
>> wrote:
>> > On Tue, Feb 23, 2010 at 12:05 AM, Jonas Sicking
>> wrote:
>> >>
>> >> On Mon, Feb 22, 2010 at 3:43 PM, Jeremy Orlow
On Mon, Feb 22, 2010 at 4:05 PM, Jonas Sicking wrote:
> On Mon, Feb 22, 2010 at 3:43 PM, Jeremy Orlow wrote:
> > On Mon, Feb 22, 2010 at 11:10 PM, Jonas Sicking
> wrote:
> >>
> >> On Mon, Feb 22, 2010 at 11:13 AM, David Levin wrote:
> >> > I've talked with some other folks on WebKit (Maciej an
On Tue, Feb 23, 2010 at 12:46 AM, Jonas Sicking wrote:
> On Mon, Feb 22, 2010 at 4:34 PM, Jeremy Orlow wrote:
> > On Tue, Feb 23, 2010 at 12:05 AM, Jonas Sicking
> wrote:
> >>
> >> On Mon, Feb 22, 2010 at 3:43 PM, Jeremy Orlow
> wrote:
> >> > On Mon, Feb 22, 2010 at 11:10 PM, Jonas Sicking
>
On Mon, Feb 22, 2010 at 4:34 PM, Jeremy Orlow wrote:
> On Tue, Feb 23, 2010 at 12:05 AM, Jonas Sicking wrote:
>>
>> On Mon, Feb 22, 2010 at 3:43 PM, Jeremy Orlow wrote:
>> > On Mon, Feb 22, 2010 at 11:10 PM, Jonas Sicking
>> > wrote:
>> >>
>> >> On Mon, Feb 22, 2010 at 11:13 AM, David Levin wr
On Tue, Feb 23, 2010 at 12:05 AM, Jonas Sicking wrote:
> On Mon, Feb 22, 2010 at 3:43 PM, Jeremy Orlow wrote:
> > On Mon, Feb 22, 2010 at 11:10 PM, Jonas Sicking
> wrote:
> >>
> >> On Mon, Feb 22, 2010 at 11:13 AM, David Levin wrote:
> >> > I've talked with some other folks on WebKit (Maciej a
On Mon, Feb 22, 2010 at 3:43 PM, Jeremy Orlow wrote:
> On Mon, Feb 22, 2010 at 11:10 PM, Jonas Sicking wrote:
>>
>> On Mon, Feb 22, 2010 at 11:13 AM, David Levin wrote:
>> > I've talked with some other folks on WebKit (Maciej and Oliver) about
>> > having
>> > a canvas that is available to worke
On Mon, Feb 22, 2010 at 3:36 PM, David Levin wrote:
>
>
> On Mon, Feb 22, 2010 at 3:10 PM, Jonas Sicking wrote:
>>
>> On Mon, Feb 22, 2010 at 11:13 AM, David Levin wrote:
>> > I've talked with some other folks on WebKit (Maciej and Oliver) about
>> > having
>> > a canvas that is available to wor
On Mon, Feb 22, 2010 at 11:10 PM, Jonas Sicking wrote:
> On Mon, Feb 22, 2010 at 11:13 AM, David Levin wrote:
> > I've talked with some other folks on WebKit (Maciej and Oliver) about
> having
> > a canvas that is available to workers. They suggested some nice
> > modifications to make it an off
On Mon, Feb 22, 2010 at 3:10 PM, Jonas Sicking wrote:
> On Mon, Feb 22, 2010 at 11:13 AM, David Levin wrote:
> > I've talked with some other folks on WebKit (Maciej and Oliver) about
> having
> > a canvas that is available to workers. They suggested some nice
> > modifications to make it an offs
On Mon, Feb 22, 2010 at 11:13 AM, David Levin wrote:
> I've talked with some other folks on WebKit (Maciej and Oliver) about having
> a canvas that is available to workers. They suggested some nice
> modifications to make it an offscreen canvas, which may be used in the
> Document or in a Worker.
On Feb 22, 2010, at 11:13 AM, David Levin wrote:
I've talked with some other folks on WebKit (Maciej and Oliver)
about having a canvas that is available to workers. They suggested
some nice modifications to make it an offscreen canvas, which may be
used in the Document or in a Worker.
Co
On Mon, Feb 22, 2010 at 7:57 PM, Drew Wilson wrote:
>
>
> On Mon, Feb 22, 2010 at 11:13 AM, David Levin wrote:
>
>> I've talked with some other folks on WebKit (Maciej and Oliver) about
>> having a canvas that is available to workers. They suggested some nice
>> modifications to make it an offsc
On Mon, Feb 22, 2010 at 11:13 AM, David Levin wrote:
> I've talked with some other folks on WebKit (Maciej and Oliver) about
> having a canvas that is available to workers. They suggested some nice
> modifications to make it an offscreen canvas, which may be used in the
> Document or in a Worker.
The lack of support for text drawing in the worker context seems like a
short sighted mistake. I understand there may be implementation issues in
some browsers, but lack of text support feels like a glaring omission spec
wise.
On Mon, Feb 22, 2010 at 11:13 AM, David Levin wrote:
> I've talked wi
I've talked with some other folks on WebKit (Maciej and Oliver) about having
a canvas that is available to workers. They suggested some nice
modifications to make it an offscreen canvas, which may be used in the
Document or in a Worker.
Proposal:
Introduce an OffscreenCanvas which may be created f
48 matches
Mail list logo
