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: Justin Novosad <junov@google.com>
Date: Mon, 23 Jun 2014 13:03:55 -0400
Message-ID: <CABpaAqQCJgXxWgDuAtQx5s8QwUvYrecu1vzNkgWbiYjDdn-hAQ@mail.gmail.com>
To: Jay Munro <jaymunro@microsoft.com>
Cc: "public-canvas-api@w3.org" <public-canvas-api@w3.org>
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.


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 17:04:23 UTC

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