On Sat, 28 Feb 2009, JustFillBug wrote:
On 2006-04-26, Ian Hickson i...@hixie.ch wrote:
On Mon, 24 Apr 2006, Vladimir Vukicevic wrote:
Assuming nobody has any problem with:
boolean isPointInPath(in float x, in float y);
...then I'll add that to the spec when you reply to
Philip's demonstration of how to handle detection of pointing at the curve
is miserably wrong. His curve is not typographically correct (bounding
box!). The detection should be in based on of precomputed regions rather
than flattening. This all can be done in script library, of course, but the
On Mon, 2 Mar 2009, Kristof Zelechovski wrote:
[...]
I would like to remind everyone that communication on this list is
expected to be cordial, pleasant, and cooperative.
After multiple warnings, I've taken the rare step of banning Kristof's
e-mail address from the mailing list for a week.
On 2006-04-26, Ian Hickson i...@hixie.ch wrote:
On Mon, 24 Apr 2006, Vladimir Vukicevic wrote:
Assuming nobody has any problem with:
boolean isPointInPath(in float x, in float y);
...then I'll add that to the spec when you reply to this mail.
Sure, isPointInPath sounds fine.
On Sat, Feb 28, 2009 at 8:38 PM, JustFillBug mozbug...@yahoo.com.au wrote:
On 2006-04-26, Ian Hickson i...@hixie.ch wrote:
On Mon, 24 Apr 2006, Vladimir Vukicevic wrote:
We can always add isPointInStrokedPath if we ever want to bother with
that (which is where the ...Fill bit came from in my
On Fri, 19 May 2006 17:34:04 +0200, Ian Hickson [EMAIL PROTECTED] wrote:
One other problem I had with it was that the colors are restricted to 8
bit. That may potentially lead to data loss but I guess it's not a major
concern yet.
This is already the case in other aspects of the API, I think.
On Tue, 29 Aug 2006, Anne van Kesteren wrote:
On Fri, 19 May 2006 17:34:04 +0200, Ian Hickson [EMAIL PROTECTED] wrote:
One other problem I had with it was that the colors are restricted to 8
bit. That may potentially lead to data loss but I guess it's not a major
concern yet.
This
On Tue, 9 May 2006, Ric Hardacre wrote:
i absolutely agree that pixels should be treated as atomic units. if a
canvas pixel space is initialized as a 1x1 square then there is only one
(visible) coordinate you could possibly access: (0,0)
Canvas' coordinate space is not quantised. The
On 4/26/06, Ian Hickson [EMAIL PROTECTED] wrote:
ImageData getImageData(in float x, in float y, in float w, in float h);
void drawImageData(in float x, in float y, in ImageData d);
I'm about to implement this as suggested; however, I'd call the second
function here putImageData instead
Quoting Vladimir Vukicevic [EMAIL PROTECTED]:
I agree that they shouldn't be affected by the CTM, but I disagree that
they should be integers. e.g. in cases like:
HTML CSS
canvas height=1 width=1 canvas { height: 100%; width: 100%; }
/canvas
...where the JS
Quoting Ian Hickson [EMAIL PROTECTED]:
How about:
interface ImageData {
readonly attribute long int width;
readonly attribute long int height;
readonly attribute Array data;
}
I saw you added this API and noted that you haven't addressed security
yet. Basically the same
On Fri, 28 Apr 2006, Arve Bersvendsen wrote:
I would suggest that we do not use floats for the color values. While
the choice of floats versus integers hardly matters on the desktop, it
is a big deal on mobile devices, where you (often) may find that there
is no FPU, so any floating
On 4/28/06, Vladimir Vukicevic [EMAIL PROTECTED] wrote:
interface ImageData {
readonly attribute string format; /* only rgba is valid for now */
readonly attribute long int width;
readonly attribute long int height;
readonly attribute Array data;
}
Actually, let's step back a second;
On 4/26/06, Ian Hickson [EMAIL PROTECTED] wrote:
On Mon, 24 Apr 2006, Vladimir Vukicevic wrote:
The use case that I'm thinking of is essentially:
pixels = c.getPixels(x, y, width, height);
/* manipulate pixels here */
c.putPixels(pixels, x, y, width, height);
That is, direct pixel
On Mon, 24 Apr 2006, Vladimir Vukicevic wrote:
The use case that I'm thinking of is essentially:
pixels = c.getPixels(x, y, width, height);
/* manipulate pixels here */
c.putPixels(pixels, x, y, width, height);
That is, direct pixel manipulation, for performing some operation that
On Mon, 24 Apr 2006, Vladimir Vukicevic wrote:
Assuming nobody has any problem with:
boolean isPointInPath(in float x, in float y);
...then I'll add that to the spec when you reply to this mail.
Sure, isPointInPath sounds fine.
Added.
We can always add isPointInStrokedPath if
On Sat, 22 Apr 2006, Sjoerd Visscher wrote:
Ian Hickson wrote:
On Sat, 22 Apr 2006, Sjoerd Visscher wrote:
I understand what you are proposing. What I don't understand is what
colour should be returned when the many device pixels represented by the
given coordinate space pixel have
On Sun, 23 Apr 2006, Maciej Stachowiak wrote:
1) Add a call to allow copying a rect from one canvas to another. You
may want to be able to control the compositing mode for this. Then you
can use an offscreen canvas to store a bitmap for later drawing into
your visible canvas. If this
[ Ian Hickson ]
I don't understand how these are supposed to work when the underlying
bitmap's device pixel space does not map 1:1 to the coordinate space.
[ Vladimir Vukicevic ]
I'm not sure what you mean -- the coordinates here are explicit canvas
pixels, and they specifically ignore the
Arve's example is how I imagined putPixels working -- basically as a
potential optimization over a bunch of fillRect calls. Even in the
presence of a higher resolution backing store, this can provide for an
optimization -- load the putPixels data into a bitmap image that's
width*height pixels and
putPixels is just a cover for drawing a bunch of 1 x 1 rects. And in
general it won't be much more efficient than that, due to possible
device scaling. Is drawing a bunch of 1x1 rects a common enough use
case to be worth it? Seems like it would almost always be better
solved by drawing
Ian Hickson wrote:
On Sat, 22 Apr 2006, Sjoerd Visscher wrote:
I understand what you are proposing. What I don't understand is what
colour should be returned when the many device pixels represented by
the given coordinate space pixel have different colors.
The weighted average of the colors in
On Fri, 21 Apr 2006, Vladimir Vukicevic wrote:
boolean pointInPathFill(in float x, in float y);
This sounds fine to me (though it means you have to spin through creating
many paths for hit testing, instead of just hanging on to a particular
path and hit testing a list of paths, which
On 4/21/06, Ian Hickson [EMAIL PROTECTED] wrote:
On Fri, 21 Apr 2006, Vladimir Vukicevic wrote:
boolean pointInPathFill(in float x, in float y);
This sounds fine to me (though it means you have to spin through creating
many paths for hit testing, instead of just hanging on to a
On Fri, 21 Apr 2006, Vladimir Vukicevic wrote:
On 4/21/06, Ian Hickson [EMAIL PROTECTED] wrote:
On Fri, 21 Apr 2006, Vladimir Vukicevic wrote:
boolean pointInPathFill(in float x, in float y);
This sounds fine to me (though it means you have to spin through
creating many paths
I understand what you are proposing. What I don't understand is what
colour should be returned when the many device pixels represented by the
given coordinate space pixel have different colors.
The weighted average of the colors in the square the size of 1 by 1
canvas pixels.
--
Sjoerd
On Sat, 22 Apr 2006, Sjoerd Visscher wrote:
I understand what you are proposing. What I don't understand is what
colour should be returned when the many device pixels represented by
the given coordinate space pixel have different colors.
The weighted average of the colors in the
27 matches
Mail list logo
