Hi All,
We've encountered a number of website compatibility issues in WebKit
due to our adherence to the new Canvas specifications -- a good
example of this is rect drawing at http://canvaspaint.org
The most obvious issues can be shown if you use the draw rect tool
and resize the rect
On 24/09/2007, at 10:45 PM, Robert O'Callahan wrote:
snip
For small files, synchronous reading is OK. Perhaps there should be
a separate whiz-bang asynchronous API ... it could support partial
reads too.
I would be concerned about this -- for many people async APIs seem
scary compared
On 25/09/2007, at 1:26 PM, Vladimir Vukicevic wrote:
Hi,
Oliver Hunt wrote:
Hi All,
We've encountered a number of website compatibility issues in
WebKit due to our adherence to the new Canvas specifications -- a
good example of this is rect drawing at http://canvaspaint.org
The most
On 25/09/2007, at 2:19 PM, Philip Taylor wrote:
On 25/09/2007, Oliver Hunt [EMAIL PROTECTED] wrote:
Firefox 2/3 and Safari 2 clear the context's path on strokeRect/
fillRect, this violates the spec -- but there are many websites that
now rely on such behaviour despite the behaviour defined
It's clear that most people here feel passionately that this is the
wrong thing to do. Perhaps it's best that we table this until
something like workerpools are in the spec.
Worker pools do not resolve the problem, even if you were to force
any synchronous IO to be performed on a worker
Maybe you should listen to the meta-argument, then.
I'm sick and tired of getting screwed by big companies (including
Apple), and I will *not* quietly accept it.
That's not unreasonable, but you have yet to give a solid technical
reason for reverting to the old text,
so far your only
On Jan 13, 2008, at 4:22 AM, Philip Taylor wrote:
What examples of information leakage is this change meant to prevent?
If you have an ImageData object then you can create a new object {
width: imgdata.width, height: imgdata.height, data: ...copy each array
element... } and then draw it,
Ah ha, i see i have misinterpreted that section, apologies for wasting
peoples time.
--Oliver
On Jan 13, 2008, at 5:33 AM, Philip Taylor wrote:
On 13/01/2008, Oliver Hunt [EMAIL PROTECTED] wrote:
I did wonder about why other origins could read anything myself, so
you're not
alone
I was just doing some putImageData tests last night, and found that
firefox does not allow putImageData to specify a target that extends
beyond the bounds of the canvas. Given that getImageData can request
bounds that extend beyond the canvas region (3.14.11.1.10) I would
expect to be
Yet more commentary:
I noticed that the behaviour is undefined if putImagedata is provided
an ImageData object on which the width, height, or data member is a
getter that throws an exception.
A quick check shows that FFX3 throws a type mismatch -- eg. acts as
though the field was invalid.
On 23/01/2008, at 5:44 AM, Philip Taylor wrote:
On 23/01/2008, Oliver Hunt [EMAIL PROTECTED] wrote:
It would be great if putImageData
could take a source region, in addition to the destination. One of
the primary reasons for using get/putImageData is to allow JS to
rapidly blit data
arguments on putImageData, i'm not sure about konqueror/
khtml).
If a dirty rect is not provided (eg. old content in a newer UA) the
entire block would be considered dirty, and so repaint as expected.
Any thoughts?
--Oliver
On Jan 23, 2008, at 11:28 AM, Oliver Hunt wrote:
On 23/01/2008
. Conceivably you could do this multiple times to
estimate the ratio, but it would be non-trivial.
--Oliver
On Jan 25, 2008, at 2:30 PM, Anne van Kesteren wrote:
On Fri, 25 Jan 2008 21:00:41 +0100, Oliver Hunt [EMAIL PROTECTED]
wrote:
[...]
I had a question as I still think ImageData should
On Jan 25, 2008, at 6:53 AM, Adam Roben wrote:
On Jan 25, 2008, at 6:56 AM, Oliver Hunt wrote:
With the current model for putImageData there is no way for them to
specify a dirty rect, which means their only option is to update
the entire display -- they have to copy the entire buffer
Am I crazy, or is there an opportunity to fix this before video
joins
blink? :O)
You're basically complaining about the codec choice -- but as has
been said before, the
choice of codec has not yet been made, and there are numerous complex
factors involved in
making that that decision --
Your original question (about control sizes, etc) was answered very
quickly -- the video element provides a block that displays video,
other css elements can be used to provide the controls -- there is no
requirement for the actual controls to be visually attached to the
video element
The video element doesn't appear solve the problem of how to
embed video
content in a player- and browser- agnostic fashion.
HTML 5 provides an opportunity to normalize how video embedding is
done for
most scenarios, making it as easy to embed video as it is an
image. But as
designed,
On 29/01/2008, at 6:17 PM, Charles wrote:
Maciej,
But I think the premise of the question misses the point of the
video element.
I may very well be completely missing the point.
I'll be satisfied if someone tells me that video is not intended
to be the
preferred way to embed video on
On 30/01/2008, at 12:54 PM, Charles wrote:
Thanks for the conversation, folks!
I was hoping that video would make Objecty http://wiltgen.net/
objecty/ redundant by making it easy for authors to embed video in
a very simple, normalized fashion across formats, browsers and
OSs. Now I
I'll try to look at the updated spec later tonight, and see if i can
see if there's anything for which it seems sensible to me for canvas
to throw (or not throw) left in the spec.
My current feeling is that for most operations it is sane to fail
silently for out of bounds numbers, inf, or
... lots of stuff that hixie has already responded to ...
* There's no fast way to edit the pixels on the canvas.
putImageData and getImageData are glacial, as is fillStyle= +
fillRect().
Byte arrays (well, if strings were bags of bytes, they'd work too)
or a
shader language, maybe? I
On Jan 31, 2008, at 10:38 PM, Ian Hickson wrote:
On Sun, 13 Jan 2008, Oliver Hunt wrote:
Section 3.14.11 ...
I overhauled this paragraph. It's now a separate, much more explicit,
section. Did I miss anything?
That looks excellent, thanks :D
--Oliver
--
Ian Hickson U
On Jan 31, 2008, at 9:35 PM, Ian Hickson wrote:
On Thu, 27 Sep 2007, Anne van Kesteren wrote:
Cool! I suppose that leaves the issue about revisiting throwing
exception for certain members? Are there any member where it does
make
to throw an exception? If we decide not to throw an exception
On Feb 3, 2008, at 2:38 AM, Anne van Kesteren wrote:
Why not give the object a constructor? I think that's cleaner. Also,
Opera already supports that :-)
The biggest problem is that you would have to define the behaviour in
a fairly counterintuitive way
new ImageData(400, 400) would not
On Feb 10, 2008, at 12:41 AM, Robert O'Callahan wrote:
On Jan 26, 2008 11:57 AM, Oliver Hunt [EMAIL PROTECTED] wrote:
Another thing that we need is some way to determine what the device
pixel-css pixel ratio is. Currently there's isn't even a real way to
tell that it's 1:1 -- you would have
On Feb 10, 2008, at 2:26 PM, Robert O'Callahan wrote:
On Feb 10, 2008 10:07 PM, Oliver Hunt [EMAIL PROTECTED] wrote:
That said, basically what you're saying is that canvas should not
support hidpi. At all. There is no need to request the dpi of a
canvas, but (and here's the critical bit
On Feb 10, 2008, at 2:53 PM, Robert O'Callahan wrote:
On Feb 11, 2008 11:37 AM, Oliver Hunt [EMAIL PROTECTED] wrote:
On Feb 10, 2008, at 2:26 PM, Robert O'Callahan wrote:
On Feb 10, 2008 10:07 PM, Oliver Hunt [EMAIL PROTECTED] wrote:
That said, basically what you're saying is that canvas
On Feb 10, 2008, at 3:08 PM, Robert O'Callahan wrote:
On Feb 11, 2008 11:49 AM, Ian Hickson [EMAIL PROTECTED] wrote:
If we have one API, high-res only:
People who use it correctly:
get good results both today and tomorrow.
People who use it wrongly:
get good results today.
If, 5 years from now, most Web developers have 200dpi screens so
browsers are using at least a 2:1 ratio for their canvas backing
stores, then putImageData and getImageData could be safely
introduced with the current spec, because an assumption that device
pixels are the same as canvas
On Feb 10, 2008, at 5:44 PM, Robert O'Callahan wrote:
On Feb 11, 2008 1:05 PM, Oliver Hunt [EMAIL PROTECTED] wrote:
i was thinking having a style property, say, canvas-dpi: auto|device
or something, where the default auto value automagically does the
evil downsampling the moment a data
:37 AM, Robert O'Callahan wrote:
On Feb 11, 2008 2:57 PM, Oliver Hunt [EMAIL PROTECTED] wrote:
Not really -- a developer would need to do work to handle browsers
that did not support the newer hidpi apis. The alternative (a css
property or whatever) would allow a developer to use
Hi All,
I have a few more ImageData related questions (as you may have guessed
from the subject)
The first is relatively simple, 3.14.11.1.10 states
If any of the arguments to createImageData() or getImageData() are
infinite or NaN, or if either the sw or sh arguments are zero, the
method
A couple of relatively minor issues, the first is fairly simple,
At the moment the spec merely states that
putImageData(getImageData(sx,sy,..),sx,sy) should not result in any
visible change to the canvas, however for those implementations that
use a premultiplied buffer there is a necessary
Hi all, while working on a bug in our canvas implementation I've
noticed that there's a difference in behaviour between Opera and
Firefox when handling path construction over save/restore
boundaries. Section 3.12.11.1.1 says that the canvas path is not
part of the state that is effected
On May 10, 2008, at 4:53 PM, Vladimir Vukicevic wrote:
Another approach would be to not try to solve this in canvas at all,
and instead specify that by default, all canvas elements are 96dpi,
and provide authors a way to explicitly override this -- then using
a combination of CSS Media
On May 13, 2008, at 1:53 PM, Vladimir Vukicevic wrote:
The first argument to the method must be an ImageData object
returned by createImageData(), getImageData(), or an object
constructed with the necessary properties by the user. If the
object was constructed by the user, its width and
That said I still don't believe custom objects should be allowed,
aside from the resolution (which may or may not be relevant) and
performance issues, a custom object with a generic JS array, rather
than an ImageData object will have different behaviour -- a proper
ImageData will clamp on
My experience implementing this in WebKit showed a pure byte array
backing store was significantly faster than using boxed values.
Faster for which operation, though? The put, or the actual
manipulation? It's a tradeoff, really; if you're doing limited
pixel manipulation, but lots of
On May 13, 2008, at 4:28 PM, Vladimir Vukicevic wrote:
On May 13, 2008, at 4:10 PM, Oliver Hunt wrote:
My experience implementing this in WebKit showed a pure byte
array backing store was significantly faster than using boxed
values.
Faster for which operation, though? The put
Um, could you actually give some kind of reasoning for these? I am
not aware of any significant performance issues in Canvas that cannot
be almost directly attributed to JavaScript itself rather than the
canvas.
--Oliver
On Jun 2, 2008, at 12:19 PM, Vladimir Vukicevic wrote:
I'd like
just once, and would prefer to do it at the
highest quality filtering available even if it's more expensive than
the default.
- Vlad
On Jun 2, 2008, at 12:25 PM, Oliver Hunt wrote:
Um, could you actually give some kind of reasoning for these? I am
not aware of any significant performance
On Jun 2, 2008, at 3:19 PM, Robert O'Callahan wrote:
On Tue, Jun 3, 2008 at 9:39 AM, Oliver Hunt [EMAIL PROTECTED] wrote:
That's exactly what i would be afraid of people doing. If I have a
fast system why should i have to experience low quality rendering?
It should be the job
On Jun 12, 2008, at 3:47 PM, Ian Hickson wrote:
On Fri, 7 Mar 2008, Oliver Hunt wrote:
Hi all, while working on a bug in our canvas implementation I've
noticed
that there's a difference in behaviour between Opera and Firefox when
...
Removing a vast rambing initial email from myself
On Jun 30, 2008, at 4:14 PM, Vladimir Vukicevic wrote:
On Jun 11, 2008, at 3:34 AM, Ian Hickson wrote:
On Mon, 2 Jun 2008, Vladimir Vukicevic wrote:
I'd like to propose adding an imageRenderingQuality property on the
canvas 2D context to allow authors to choose speed vs. quality when
So now we need to define levels of graphic burden? and at what level
of burden does the quality suffer? Seems just as hard to define.
Having the author explicit say this has to be as high quality as
possible or less can be low quality seems better and we have
examples of other specs
be.' This
is semantic information the browser has no way of inferring.
Cheers,
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Oliver Hunt
Sent: Tuesday, July 01, 2008 2:18 AM
To: Mark Finkle
Cc: Vladimir Vukicevic; Robert O'Callahan; WHATWG; David Hyatt
Question: What do people think about making audio more like
canvas as sketched above?
I don't believe it would be appropriate for the audio tag to take on
such an API. My reason is that canvas is very different from other
elements -- it doesn't actually support any form of image loading
On Jul 16, 2008, at 4:39 AM, Fabien Meghazi wrote:
On Wed, Jul 16, 2008 at 1:10 PM, Oliver Hunt [EMAIL PROTECTED] wrote:
Question: What do people think about making audio more like
canvas as
sketched above?
Well I guess it would be cool for writing canvas games, and necessary
if support
On Jul 16, 2008, at 5:00 AM, Fabien Meghazi wrote:
I should note that i am not necessarily against the idea of an audio
equivalent of the canvas element, i just don't believe such an API
should be
part of the audio element.
Do you mean adding audio facilities as described by Markus into
states should not draw
anything -- so that should act as an explicit mechanism for disabling
shadows should it not? It's possible i've missed something, but this
would appear to accomplish what you desire afaict.
-Eric Butler
--Oliver Hunt
On Jul 29, 2008, at 3:56 AM, Oliver Hunt wrote:
On Jul 27, 2008, at 12:06 PM, Eric Butler wrote:
It would seem Safari isn't quite following the spec here, since it
appears to never draw shadows when the shadow color is fully
transparent or something and doesn't encounter these issues
Cool -- I wonder though if it would be better if it were placed in a
different method, drawFrame or something (very much an up in the air
sort of question)
One other thing that I would consider would be requiring the frame# to
be specified explicitly as that would make things like chapter
On Aug 18, 2008, at 5:58 PM, Robert O'Callahan wrote:
On Tue, Aug 19, 2008 at 11:24 AM, Oliver Hunt [EMAIL PROTECTED]
wrote:
Cool -- I wonder though if it would be better if it were placed in a
different method, drawFrame or something (very much an up in the air
sort of question
I think the canvas api should get 2 new methods:
CanvasColor createRGBAColor(in float r, in float g, in float b, in
float a)
CanvasColor createHSLAColor(in float h, in float s, in float l, in
float a)
WebKit already has a non-standard function -- setFillColor(r, g, b, a)
-- that
On Oct 4, 2008, at 2:53 PM, Maciej Stachowiak wrote:
setFillColor avoid the need for allocation entirely in all cases.
We could also consider letting fillStyle take a number to be
interpreted as a 32-bit RGBA value, since modern JS engines can do
math and masking faster than string
Whoops, sorry -- Philipp Serafin did -- i misread my mail reply
indentation, sorry :D
On Oct 5, 2008, at 10:10 AM, Kristof Zelechovski wrote:
Correction: I did not write that.
Chris
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Oliver Hunt
Sent
So while playing around with some image filtering code using the
Canvas ImageData APIs I realised that the APIs as currently designed
make it difficult to do certain kinds of operation. The specific
issue is that there is no direct mechanism to get a working/scratch
ImageData object of
So I've been looking at importScripts (http://www.whatwg.org/specs/web-workers/current-work/#importing-scripts-and-libraries
) and found that the behaviour of Mozilla differs from the behaviour
defined in the spec. The spec behaviour is
(pseudo code, skipping url validation, etc)
function
On Mar 7, 2009, at 1:20 AM, ben turner wrote:
On Fri, Mar 6, 2009 at 8:40 PM, Oliver Hunt oli...@apple.com wrote:
In all honesty i'm not sure which is the better approach as the spec
approach requires developers to manually handle the potential for
partial
library execution, but the Mozilla
Yes, i realise it does more than _just_ a syntax check, but the user
observable effect is just the success or failure of syntax check :D
--Oliver
On Mar 7, 2009, at 12:51 PM, Boris Zbarsky wrote:
Oliver Hunt wrote:
If by compilation you mean you're (effectively) just doing a
syntax check
Why do you think it's important not to have side effects for syntax
errors but don't think it's important to not have side effects for
run-time errors? Given that we simply can't fix the latter, I don't
see any advantage to users to attempt to fix the former.
I really don't think optimizing for
On Mar 7, 2009, at 11:22 PM, ben turner wrote:
Just to clarify, if two scripts fail to load or compile then Mozilla
always throws the error encountered by the first of the failed
scripts. So, if I have a worker that does this:
importScripts(1.js, 2.js, 3.js);
and 1.js fails to load and 3.js
So I've been looking at the object cloning rules for postMessage and
have noticed a couple of things that seem less than ideal. The first
is that it fails to specify the behaviour of cloning for prototype
chains. While this is definitely an issue specific to JS rather than
binding
When discussing this standard we have to recognize that not all
browsers actually have a main thread. Time will tell if more or less
browsers of the future will have multi-threaded architectures, but the
trend has been for more I think.
Any aspects of the spec that asserts or assumes a main
I commented to the list on this issue some time ago (and a number of
the APIs were updated base don my comments); in general developers do
not expect graphics libraries to throw exceptions, especially for
values that are frequently computed. We've had numerous cases where
webkit has had
Why not make getPixel () and setPixel() a standard?
The ImageData APIs already provide the ability to do this and are
already supported by Firefox, Opera and Safari.
--Oliver
SVG images often don't have an intrinsic size. What's the intrinsic
size of
this image?
svg xmlns=http://www.w3.org/2000/svg;
linearGradient id=g x1=0 y1=0 x2=1 y2=0
stop stop-color=red offset=0/stop stop-color=lime
offset=1/
/linearGradient
rect x=0% y=0% width=100% height=100%
Worse yet, the current setup means that a script that tries
createImageData, fill in the pixels, and then paint it to the
canvas, needs to fill different numbers of pixels depending on the
output device. I fully expect script authors to get this very very
wrong, since it's such
I believe that this will be difficult to have such a limit as sites
may rely on GC to collect Workers that are no longer running (so
number of running threads is non-deterministic), and in the context of
mix source content (mash-ups) it will be difficult for any content
source to be sure
Pros:
- Pre-Compiled: By bundling known JS Libraries with the browser, the
browser could store a more efficient representation of the file.
For instance pre-compiled into Bytecode or something else browser
specific.
I think something needs to be clarified wrt to compile times and the
Have you checked for a byte order marker in the source document? (see http://unicode.org/faq/utf_bom.html#BOM
)
--Oliver
On Jun 23, 2009, at 6:42 PM, Kartikaya Gupta wrote:
There's a page (http://www.microsoft.com/windowsmobile/mobile/en-us/totalaccess/software/software/eula-sw-netflix.mspx
On Jul 6, 2009, at 6:08 PM, Ian Hickson wrote:
On Mon, 6 Jul 2009, Charles Pritchard wrote:
This is on the list of things to consider in a future version. At
this
point I don't really want to add new features yet because otherwise
we'll never get the browser vendors caught up to
I'd like to make a passionate plea that the spec say
implementations must
support negative widths and negative heights and draw the image
backward
effectively flipping the result.
We'd need to be fairly sure that such a change would not break
existing content -- this is a change that
On Jul 9, 2009, at 4:19 PM, Gregg Tavares wrote:
On Thu, Jul 9, 2009 at 4:11 PM, Oliver Hunt oli...@apple.com wrote:
I'd like to make a passionate plea that the spec say
implementations must
support negative widths and negative heights and draw the image
backward
effectively flipping
On Jul 9, 2009, at 9:09 PM, Brian Campbell wrote:
On Jul 9, 2009, at 9:25 PM, Oliver Hunt wrote:
I disagree. When I scale a rectangular opaque image I expect
rectangular opaque results. The Firefox implementation does not
do this.
If you believe that to be the case then you can always
On Jul 10, 2009, at 3:27 PM, James Graham wrote:
Quoting Kartikaya Gupta lists.wha...@stakface.com:
Really, it's not that much work to make sure the API can have
bindings in other languages. As long as you can write WebIDL for
it (and provide relevant DOM feature strings wherever
On Jul 10, 2009, at 6:38 PM, Gregg Tavares wrote:
On Thu, Jul 9, 2009 at 6:25 PM, Oliver Hunt oli...@apple.com wrote:
Inconsistency doesn't lead to no one depending on a behaviour, it
just means sites only work in one browser. Your suggesting would
result in sites being broken in all
While investigating a compatibility issue with http://www.blahbleh.com/clock.php
I found that the spec behaviour on CanvasRenderingContext2D.lineTo
conflicts with what Gecko implements.
The current spec language is
The lineTo(x, y) method must do nothing if the context has no
subpaths.
Just noticed while looking at the path modification functions that the
summary of bezierCurveTo (at the beginning of Section 4.8.11.1.8)
gives bezierCurveTo the signature bezierCurveTo(cpx, cpy, x, y)
which is the signature for quadraticCurveTo. The signature should be
bezierCurveTo(cp1x,
(..);lineTo(..);lineTo(..) will draw
nothing as the path never becomes non-empty so none of the calls can
ever have an effect, whereas this re-specification would result in
subsequent operations drawing something.
--Oliver
On Jul 11, 2009, at 3:41 PM, Oliver Hunt wrote:
While investigating
I've made the types list visible during all the events, but I'm
skeptical about making everything available. We'll probably revisit
this
in a few years when we have a test suite for this. (I probably need to
rewrite the way this section is written before making any more
significant
On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote:
Yeah, that seems likely, since none of you implemented the higher-DPI
ImageData in your first versions. :-(
WebKit's implementation has always worked with high dpi backing stores
and follows the spec accordingly.
--Oliver
On Sep 3, 2009, at 4:50 PM, Robert O'Callahan wrote:
On Fri, Sep 4, 2009 at 4:48 AM, Oliver Hunt oli...@apple.com wrote:
On Sep 3, 2009, at 4:54 AM, Ian Hickson wrote:
Yeah, that seems likely, since none of you implemented the higher-DPI
ImageData in your first versions. :-(
WebKit's
On Sep 10, 2009, at 12:55 PM, Darin Fisher wrote:
On Thu, Sep 10, 2009 at 12:32 PM, Maciej Stachowiak m...@apple.com
wrote:
On Sep 10, 2009, at 11:22 AM, Michael Nordman wrote:
On Wed, Sep 9, 2009 at 7:55 PM, Robert O'Callahan rob...@ocallahan.org
wrote:
On Thu, Sep 10, 2009 at 2:38
On Oct 16, 2009, at 8:10 PM, Robert O'Callahan wrote:
On Sat, Oct 17, 2009 at 4:01 AM, Philip Taylor excors+wha...@gmail.com
wrote:
Yes, mostly.
http://philip.html5.org/tests/canvas/suite/tests/index.2d.composite.uncovered.html
has relevant tests, matching what I believed the spec said - on
On Nov 26, 2009, at 11:45 AM, Jason Oster wrote:
Hello Group,
I've been using canvas to draw pixel art (NES/SNES game screens and sprites)
similar to what an emulator would do. Doing this kind of drawing requires
direct access to the pixel buffer.
My problem with the canvas spec (as
On Nov 29, 2009, at 10:59 AM, Kenneth Russell wrote:
On Sat, Nov 28, 2009 at 9:47 PM, Boris Zbarsky bzbar...@mit.edu wrote:
On 11/29/09 12:15 AM, Kenneth Russell wrote:
I assume you meant JS bitwise operators? Do we have any indication that
this would be faster than four array property
On Dec 3, 2009, at 4:06 AM, Bjorn Bringert wrote:
On Wed, Dec 2, 2009 at 10:20 PM, Jonas Sicking jo...@sicking.cc wrote:
On Wed, Dec 2, 2009 at 11:17 AM, Bjorn Bringert bring...@google.com wrote:
I agree that being able to capture and upload audio to a server would
be useful for a lot of
On Dec 6, 2009, at 10:18 PM, Sigbjorn Finne wrote:
On 12/5/2009 13:24, Franz Buchinger wrote:
Gears introduced the concept of an offscreen canvas that doesn't draw
anything in the browser window, but can be used to manipulate images in a
web worker.
I used this functionality to implement
Ideally if we were to have a graphics context in a worker we'd want it to be
the standard CanvasRenderingContext2D, the only real problem is that
CanvasRenderingContext2D references the parent canvas element which clearly
won't fly in a worker.
I've been thinking of creating something like a
On Dec 17, 2009, at 10:03 PM, Boris Zbarsky wrote:
On 12/17/09 12:48 AM, Boris Zbarsky wrote:
It seems very difficult to me to come up with a function cloning
solution that won't break in subtle ways when such functions are passed
to it...
I should clarify this. It seems to me eminently
On Feb 3, 2010, at 10:01 AM, Tim Hutt wrote:
On 3 February 2010 17:45, Boris Zbarsky bzbar...@mit.edu wrote:
On 2/3/10 12:22 PM, Tim Hutt wrote:
Yes it should be cleared and there should be a oncanvasresize() callback.
What uses cases does this cover that are not covered by a general
On Feb 3, 2010, at 11:54 AM, Tim Hutt wrote:
On 3 February 2010 19:23, Oliver Hunt oli...@apple.com wrote:
1. Support more length specifiers for the width and height of a
canvas(%, em, etc.).
This doesn't really make sense for the backing buffer as it is logically
defined in terms
On Feb 3, 2010, at 11:54 AM, Tim Hutt wrote:
On 3 February 2010 19:23, Oliver Hunt oli...@apple.com wrote:
1. Support more length specifiers for the width and height of a
canvas(%, em, etc.).
This doesn't really make sense for the backing buffer as it is logically
defined in terms
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 for
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
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
could
On Jun 4, 2010, at 10:05 AM, Rob Evans wrote:
Hi,
I wonder if this is the correct place to post this but I
cannot find any resources online as canvas is so new.
Canvas isn't new -- it's at least 4 or 5 years old, and has been in the html5
spec for at least 2 or 3 of those
All meesaging through postMessage uses the internal structured cloning
algorithm detailed at
http://www.w3.org/TR/2010/WD-html5-20100304/Overview.html#internal-structured-cloning-algorithm
It's basically a deep copy, but has a few restrictions on the types cloned, and
doesn't copy functions or
On Jul 14, 2010, at 5:29 PM, David Flanagan wrote:
Aryeh Gregor wrote:
On Wed, Jul 14, 2010 at 3:03 PM, David Flanagan da...@davidflanagan.com
wrote:
I'm confused by the term coordinate space units as applied to the canvas
spec. It does not seem to be defined.
It seems clear to me.
1 - 100 of 130 matches
Mail list logo
