> On Sep 3, 2015, at 11:33 AM, Melvin Carvalho wrote:
>>
>
> Im not an expert here, but my understanding from reading some wikipedia
> articles was that a preimage attack on md5 was 2^123.
For a pre-image attack that’s true (or thereabouts), the real problem is that
you can compute content
On Dec 9, 2013, at 2:29 PM, Tingan Ho wrote:
>>
>> Tingan, would it be acceptable for you to do the resampling in JavaScript?
>
>
> First, writing it in Javascript is less performant. Since natively you can
> have access to the GPU. Second, it is abstract a layer for JS developers,
> since th
The current structured clone algorithm does not include support for the Map and
Set types, so a developer would need to manually implement the serialisation
and deserialisation. While this would not be impossible it does seem like it
is an unnecessary inconvenience for a core type in ES6.
The
On Feb 4, 2013, at 2:40 PM, Garrett Smith wrote:
>>> That's fair enough. Though not all exceptions are Errors -- DOMException
>>> currently isn't, though I think some people want it to somehow inherit
>>> from
>>> Error.
>>>
> Why not?
That's something lost in the mists of time, however just as
postMessage already has an ownership transfer list, we could always extend the
set of transferable types to include a canvas like thing (the context or some
such).
IIRC the last time I suggested having canvas (or at least canvas-like) APIs
available in workers it turned into a spec for rotating
The context is owned by the canvas element. If the canvas element is still
alive then by definition so is the context.
--Oliver
On Sep 4, 2012, at 12:31 PM, Jussi Kalliokoski
wrote:
> Hmm... Is it visible to the page outside getContext() ?
>
> On Tue, Sep 4, 2012 at 10:21 PM, Boris Zbarsky
On Apr 17, 2012, at 3:32 PM, Darin Fisher wrote:
>
>
> On Mon, Apr 16, 2012 at 4:05 PM, Darin Fisher wrote:
>
>
> On Mon, Apr 16, 2012 at 2:57 PM, Oliver Hunt wrote:
>
> On Apr 16, 2012, at 2:34 PM, Darin Fisher wrote:
>
> > On Mon, Apr 16, 20
On Apr 16, 2012, at 2:34 PM, Darin Fisher wrote:
> On Mon, Apr 16, 2012 at 1:39 PM, Oliver Hunt wrote:
>
>>
>> On Apr 16, 2012, at 1:12 PM, Darin Fisher wrote:
>>
>> Glenn summarizes my concerns exactly. Deferred rendering is indeed the
>> more precis
On Apr 16, 2012, at 2:00 PM, Darin Fisher wrote:
> I have learned that it is not commonly accepted that reading ImageData can be
> slow. I had assumed otherwise.
Yes, it's possible to make reading image data slow, but i can make _anything_
slow. I could make postMessage slow even though it's
On Apr 16, 2012, at 11:07 AM, Darin Fisher wrote:
>
> See synchronous XMLHttpRequest. I'm sure every browser vendor wishes that
> didn't exist. Note how we recently withdrew support for synchronous
> ArrayBuffer access on XHR? We did this precisely to discourage use of
> synchronous mode XHR.
On Apr 16, 2012, at 1:12 PM, Darin Fisher wrote:
> Glenn summarizes my concerns exactly. Deferred rendering is indeed the more
> precise issue.
>
> On Mon, Apr 16, 2012 at 12:18 PM, Oliver Hunt wrote:
> Could someone construct a demonstration of where the read back of the
&g
the argument is wrt deferred rendering rather than GPU copyback, can
we drop GPU related arguments from this thread?
--Oliver
On Apr 16, 2012, at 12:10 PM, Glenn Maynard wrote:
> On Mon, Apr 16, 2012 at 1:59 PM, Oliver Hunt wrote:
> I don't understand why adding a runlo
On Apr 16, 2012, at 11:38 AM, Darin Fisher wrote:
> On Mon, Apr 16, 2012 at 11:17 AM, Oliver Hunt wrote:
>
> On Apr 16, 2012, at 11:07 AM, Darin Fisher wrote:
>
> >
> > Carrots and Sticks.
> >
> > Aren't we missing an opportunity here? By giving we
On Apr 16, 2012, at 11:07 AM, Darin Fisher wrote:
>
> Carrots and Sticks.
>
> Aren't we missing an opportunity here? By giving web developers this easy
> migration path, you're also giving up the opportunity to encourage them to
> use a better API. Asynchronous APIs are harder to use, and th
Because there are a huge number of sites out there that check for the existence
of a feature by doing 'navigator.userAgent.indexOf("mozilla") != -1' or similar
(or they decide that the absence of the mozilla term means that you're IE6), so
not including the word "mozilla" in the user agent would
I don't think generating 16bit values is beneficial -- either 8bit values for
byte at a time processing or full [u]int32 makes more sense. I think the only
reason for 16bit to come up is ecmascript's notionally 16bit characters.
I would prefer polymorphism of some form, for example
any gimmeRa
I agree with this sentiment, the specification should simply state "the
returned values are guaranteed to be cryptographically secure", that's all that
needs to be said. There is no need to describe how this is implemented, if an
implementation provides predictable values then that implementati
On Feb 1, 2011, at 10:04 AM, Anne van Kesteren wrote:
> On Tue, 01 Feb 2011 18:36:19 +0100, Boris Zbarsky wrote:
>> On 2/1/11 5:19 AM, Simon Pieters wrote:
>>> While you're discussing efficient handoff of ArrayBuffer, do you also
>>> keep in mind efficient handoff of other objects (e.g. ImageDat
It _may_ be worth discussing (as I am not all knowing) but I cannot see a way
that these APIs could be added without opening up a user to privacy violations.
It is somewhat irksome to me that I have raised these exact issues in the past
in the context of implementing editors in canvas and you a
On Sep 8, 2010, at 11:00 AM, Boris Zbarsky wrote:
> On 9/8/10 12:45 PM, Oliver Hunt wrote:
>> I suggested this behaviour a long time ago after running into yet
>> another piece of code that hit this case in webkit (back when the
>> spec said to throw an exception) yet fire
On Sep 8, 2010, at 11:13 AM, Chris Marrin wrote:
> Web Sockets is certainly another candidate, but I meant Web Workers. There
> have been informal discussions on using ArrayBuffers as a way to safely share
> binary data between threads. I don't believe anything has been formalized
> here.
You
On Sep 8, 2010, at 10:20 AM, Eric Uhrhane wrote:
> On Wed, Sep 8, 2010 at 9:45 AM, Oliver Hunt wrote:
>> The problem with throwing an exception is that it's fairly common for code
>> to end up accidentally producing a NaN or Infinite value, and throwing an
>> e
The problem with throwing an exception is that it's fairly common for code to
end up accidentally producing a NaN or Infinite value, and throwing an
exception would prevent all subsequent drawing from occurring.
I suggested this behaviour a long time ago after running into yet another piece
of
On Aug 4, 2010, at 6:26 PM, Garrett Smith wrote:
> On 8/4/10, Oliver Hunt wrote:
>>
>> On Aug 4, 2010, at 3:32 PM, Garrett Smith wrote:
>>
>>> On 8/4/10, Garrett Smith wrote:
>>>
>>> [...]
>>>> "submitButton" in f
On Aug 4, 2010, at 3:32 PM, Garrett Smith wrote:
> On 8/4/10, Garrett Smith wrote:
>
> [...]
>> "submitButton" in form.elements
>>
>> Existing implementations vary on when they use catchalls. I'd like to
>> see standardization for this behavior and codification so that
>> implementations beha
On Aug 2, 2010, at 12:57 PM, Garrett Smith wrote:
> I also linked to the old "catchalls" proposal earlier in the thread.
> That is because the host objects mentioned here have a specialized
> "catchall" behavior that isn't yet defined by any specification, so
> when the code has property access wi
On Aug 2, 2010, at 12:25 PM, Garrett Smith wrote:
> On 8/2/10, Oliver Hunt wrote:
>>
>> On Aug 2, 2010, at 7:36 AM, And Clover wrote:
>>
>>> On 07/30/2010 06:43 AM, Oliver Hunt wrote:
>>>> all array functions defined in ES5 are "generic&quo
On Aug 2, 2010, at 7:36 AM, And Clover wrote:
> On 07/30/2010 06:43 AM, Oliver Hunt wrote:
>> all array functions defined in ES5 are "generic" in that they work
>> over any array-like object.
>
> They're guaranteed to work over any array-like nativ
On Jul 30, 2010, at 2:46 PM, Alex Russell wrote:
> On Fri, Jul 30, 2010 at 4:18 AM, Jonas Sicking wrote:
>> On Thu, Jul 29, 2010 at 5:45 PM, Ian Hickson wrote:
>>>
>>> The e-mails quoted below consist of the salient points of this thread:
>>>
>>> On Fri, 23 Apr 2010, David Bruant wrote:
On Jul 29, 2010, at 9:03 PM, Alex Russell wrote:
> On Mon, Apr 26, 2010 at 10:04 AM, David Flanagan
> wrote:
>> Erik Arvidsson wrote:
>
> for (var i = 0, length = collection.length; i < length; i++)
> // instead of:
> for (var i = 0; i < collection.length; i++)
>
Actua
On Jul 28, 2010, at 2:46 PM, Tab Atkins Jr. wrote:
> On Wed, Jul 28, 2010 at 2:43 PM, David Flanagan
> wrote:
>> Firefox and Chrome disagree about the implementation of the
>> destination-atop, source-in, destination-in, and source-out compositing
>> operators. Test code is attached.
>>
>> Chr
On Jul 14, 2010, at 10:58 PM, David Flanagan wrote:
> Here's another coordinate-space related question.
>
> I assume that the intended purpose of isPointInPath() is hit testing. You get
> a click event on a canvas element, extract the mouse coordinates from the
> event object, subtract the can
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
>> 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.
>
> Even if
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 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 tho
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 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 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 Feb 3, 2010, at 11:54 AM, Tim Hutt wrote:
> On 3 February 2010 19:23, Oliver Hunt 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 l
On Feb 3, 2010, at 11:54 AM, Tim Hutt wrote:
> On 3 February 2010 19:23, Oliver Hunt 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 l
On Feb 3, 2010, at 10:01 AM, Tim Hutt wrote:
> On 3 February 2010 17:45, Boris Zbarsky 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 resize
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 e
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 Wo
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 t
On Dec 3, 2009, at 4:06 AM, Bjorn Bringert wrote:
> On Wed, Dec 2, 2009 at 10:20 PM, Jonas Sicking wrote:
>> On Wed, Dec 2, 2009 at 11:17 AM, Bjorn Bringert wrote:
>>> I agree that being able to capture and upload audio to a server would
>>> be useful for a lot of applications, and it could be
On Nov 29, 2009, at 10:59 AM, Kenneth Russell wrote:
> On Sat, Nov 28, 2009 at 9:47 PM, Boris Zbarsky 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 sets
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 spe
On Oct 16, 2009, at 8:10 PM, Robert O'Callahan wrote:
On Sat, Oct 17, 2009 at 4:01 AM, Philip Taylor > 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
Windows, Opera 10 passes
On Sep 10, 2009, at 12:55 PM, Darin Fisher wrote:
On Thu, Sep 10, 2009 at 12:32 PM, Maciej Stachowiak
wrote:
On Sep 10, 2009, at 11:22 AM, Michael Nordman wrote:
On Wed, Sep 9, 2009 at 7:55 PM, Robert O'Callahan > wrote:
On Thu, Sep 10, 2009 at 2:38 PM, Michael Nordman
wrote:
If this
On Sep 3, 2009, at 4:50 PM, Robert O'Callahan wrote:
On Fri, Sep 4, 2009 at 4:48 AM, Oliver Hunt 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 implemen
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
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
changes
On Jul 21, 2009, at 1:02 PM, dar...@chaosreigns.com wrote:
On 07/21, Tab Atkins Jr. wrote:
HTML5 is not an SGML or XML language. It does not use a DOCTYPE in
I thought HTML5 conformed to XML?
HTML has never been xml -- the html5 spec does define an xml
serialisation though (which i imagin
ed into
subsequent calls, eg. lineTo(..);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
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(cp1
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. Oth
On Jul 10, 2009, at 6:38 PM, Gregg Tavares wrote:
On Thu, Jul 9, 2009 at 6:25 PM, Oliver Hunt 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 browsers -- the
On Jul 10, 2009, at 3:27 PM, James Graham wrote:
Quoting Kartikaya Gupta :
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 necessary),
you should get it
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
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 browsers -- the only options
from here on out are either nothing gets drawn (as in gecko and
presto), or the destination is
On Jul 9, 2009, at 4:19 PM, Gregg Tavares wrote:
On Thu, Jul 9, 2009 at 4:11 PM, Oliver Hunt 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
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 wou
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 implementi
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
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
like
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
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 non
SVG images often don't have an intrinsic size. What's the intrinsic
size of
this image?
http://www.w3.org/2000/svg";>
offset="1"/>
That hasn't got intrinsic sizes, so it cannot be rendered on a
canvas. This doesn't preclude the use of with intrinsic sizes,
that are given only
On May 4, 2009, at 6:38 AM, Anne van Kesteren wrote:
On Thu, 30 Apr 2009 21:15:04 +0200, Ian Hickson wrote:
As far as I can tell this doesn't require any changes to HTML5,
since the
same applies here as applies to a regular , right?
Maybe you misunderstood, but the request was not about
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
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 t
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 th
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 languag
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 a
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
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 d
On Mar 7, 2009, at 1:20 AM, ben turner wrote:
On Fri, Mar 6, 2009 at 8:40 PM, Oliver Hunt 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 app
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 im
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 the
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
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 operati
On Oct 4, 2008, at 3:28 AM, Anne van Kesteren wrote:
On Sat, 04 Oct 2008 12:19:03 +0200, Oliver Hunt <[EMAIL PROTECTED]>
wrote:
Ah, I was not meaning to in any way suggest that we change the type
of fillStyle/strokeStyle, merely to overload the assignment
behaviour to allow arrays
On Oct 4, 2008, at 3:07 AM, Anne van Kesteren wrote:
On Sat, 04 Oct 2008 01:37:53 +0200, Oliver Hunt <[EMAIL PROTECTED]>
wrote:
Just had a thought (no idea how original) -- how about if fillStyle
were able to accept a 3 or 4 number array? eg. fillStyle = [0, 0.3,
0.6, 1.0] ?
I did some basic testing, and it looks like a significant amount of
the difference is due to this (based on the frame rate that ToT webkit
could kick out, the timeout difference corresponds to around a 30% on
its own). However it's difficult to be entirely sure as VMWare (from
memory) thro
ect fills where each rect fill
has an colour parsing step.
--Oliver
On Sep 30, 2008, at 12:53 AM, Oliver Hunt wrote:
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, i
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 pro
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
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 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 th
which the spec 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 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 element.
Do you mean adding audio facilities as described by Markus into the
c
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 more like
as
sketched above?
Well I guess it would be cool for writing canvas games, and necessary
if suppo
Question: What do people think about making more like
as sketched above?
I don't believe it would be appropriate for the tag to take on
such an API. My reason is that is very different from other
elements -- it doesn't actually support any form of image loading
itself, all content mu
curately as can
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'
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
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
rende
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
...
...so Opera is wrong.
Yeah I ca
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 b
t;). Some apps might also
render to a canvas 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 fo
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 t
1 - 100 of 146 matches
Mail list logo
