On Sat, 28 Feb 2009, JustFillBug wrote:
> On 2006-04-26, Ian Hickson 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 yo
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.
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
l
On Sat, Feb 28, 2009 at 8:38 PM, JustFillBug wrote:
> On 2006-04-26, Ian Hickson 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 API, because the
>>> re
On 2006-04-26, Ian Hickson 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
On Tue, 29 Aug 2006 20:18:19 +0200, Ian Hickson <[EMAIL PROTECTED]> wrote:
This is already the case in other aspects of the API, I think.
As you pointed out some to me, not for percentage rgb color values.
I don't recall what this thread was about. Was there a change you wanted
made to the sp
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.
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, 16 May 2006, Arve Bersvendsen wrote:
>
> Again, and this goes back to what's already been said about the RGBA
> values in ImageData: Using floats for x,y,w,h will for all practical
> purposes exclude canvas from ever being possible to implement in a
> meaningful way on systems without h
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 ar
On Mon, 8 May 2006, Anne van Kesteren wrote:
>
> Quoting Ian Hickson <[EMAIL PROTECTED]>:
> > > > How about:
> > > >
> > > >interface ImageData {
> > > > readonly attribute long int width;
> > > > readonly attribute long int height;
> > > > readonly attribute Array data;
> > > >
On 5/16/06, Arve Bersvendsen <[EMAIL PROTECTED]> wrote:
Again, and this goes back to what's already been said about the RGBA
values in ImageData: Using floats for x,y,w,h will for all practical
purposes exclude canvas from ever being possible to implement in a
meaningful way on systems without ha
On Tue, 16 May 2006 10:25:01 +0200, Vladimir Vukicevic
<[EMAIL PROTECTED]> wrote:
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 imple
On 5/16/06, Vladimir Vukicevic <[EMAIL PROTECTED]> wrote:
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; how
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" instea
On 5/9/06, Anne van Kesteren <[EMAIL PROTECTED]> wrote:
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
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: 100%; width: 100%; }
...where the JS then uses the coordinate space
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: 100%; width: 100%; }
...where the JS then uses the coordinate space 0..1,0..1 the author might
want to grab the t
On 5/5/06, Ian Hickson <[EMAIL PROTECTED]> wrote:
On Fri, 28 Apr 2006, Vladimir Vukicevic wrote:
> ImageData createImageData(in string format, in string width, in string
> height, in Array data);
>
> for creating "ImageData" out of an arbitrary set of generated data (e.g.
> evaluating some functi
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 sam
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
Also... should the RGBA data be returned with premultiplied alpha or
not? Premultiplied tends to be better for the math, non-premultiplied
tends to be easier to understand. (That is, 50% opaque green is
(0,255,0,128) if non-premultiplied, or (0,128,0,128) if
premultiplied.)
- Vlad
On 5/4/06
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 pix
On Fri, 21 Apr 2006 21:10:11 +0200, Vladimir Vukicevic
<[EMAIL PROTECTED]> wrote:
Note: we could return the pixels as integers in the range of 0..255,
as 8-bit color is most likely what canvases will be dealing with.
However, using floats allow us to easily extend into a 16-bit
colorspace with
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 i
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 spa
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 isPointInS
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 tha
On Tue, 25 Apr 2006 00:17:36 +0200, Vladimir Vukicevic
<[EMAIL PROTECTED]> wrote:
Arve's example is how I imagined putPixels working -- basically as a
potential optimization over a bunch of fillRect calls.
Two further clarifications:
1) x and y values for both get/setPixel are both floats.
On 4/21/06, Ian Hickson <[EMAIL PROTECTED]> wrote:
> 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 sound
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
[ 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 cur
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 an
This mail showed up pointlessly out of order. I see Ian already
responded. :)
dave
On Apr 22, 2006, at 6:15 PM, David Hyatt wrote:
The getPixels proposal seems broken to me in that it does not take
into account high DPI, i.e., a situation where the canvas pixel
space has been scaled and a
The getPixels proposal seems broken to me in that it does not take
into account high DPI, i.e., a situation where the canvas pixel space
has been scaled and a more detailed image is possibly rendering
within a region of the canvas. In this situation, a "canvas pixel"
could actually be a bu
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 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 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
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 Vissc
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
> > creat
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 pa
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 see
Hi folks,
I'd like to suggest extending the HTML canvas 2d context with a few
additions. These are variations on some of the methods added to
Opera's "opera-2dgame" context. The methods are intended to give
content authors direct pixel access to the canvas, as well as provide
some basic point-in
44 matches
Mail list logo
