W3C home > Mailing lists > Public > public-canvas-api@w3.org > April to June 2014

Re: Bug https://www.w3.org/Bugs/Public/show_bug.cgi?id=13277

From: Rik Cabanier <cabanier@gmail.com>
Date: Mon, 23 Jun 2014 11:19:32 -0700
Message-ID: <CAGN7qDAatt0+2XXa92hshu=t_JngmiiBSp7xvkaDh3LvuK9UJQ@mail.gmail.com>
To: Justin Novosad <junov@google.com>
Cc: Jay Munro <jaymunro@microsoft.com>, "public-canvas-api@w3.org" <public-canvas-api@w3.org>
On Mon, Jun 23, 2014 at 10:03 AM, Justin Novosad <junov@google.com> wrote:

> I don't think there should be any implementation issues. If there are
> graphics APIs that do not expose the current point directly, then it would
> be trivial to cache the point in CanvasRenderingContext2D/Path2D
> Also, the caching behavior would be very easy to implement in script on
> top of the existing API by overloading the path methods, so it is not clear
> that there is a strong necessity to add this behavior. It's really just a
> convenience thing.
>

I agree that this could be emulated easily so it doesn't need to be in the
spec.



>
> On Fri, Jun 20, 2014 at 6:30 PM, Jay Munro <jaymunro@microsoft.com> wrote:
>
>> I've been looking at old Level 2 bugs, and this one sounded interesting.
>> The idea of a getter to get the current "from" point when using moveTo,
>> lineTo, or arcTo. From an implementation standpoint, how difficult would it
>> be to cache the current path's x/y location?
>>
>> I could see this several ways:
>>
>> //  System current path point
>> readonly attribute double  context2d.currentPointX;
>> readonly attribute double  context2d.currentPointY;
>>
>> // Path2D current point
>> readonly attribute double  Path2D.currentPointX;
>> readonly attribute double  Path2D.currentPointY;
>>
>> Thoughts?
>>
>>
>> Jay Munro  Content Developer 2 Internet Explorer     85/2275
>> 425-703-2242
>>
>>
>>
>>
>
Received on Monday, 23 June 2014 18:20:00 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 20:31:57 UTC