Re: [whatwg] Proposal: navigator.cores

[Joe Gregorio]

Maybe we can also return their RAM, but limit it to a maximum of 640K,
since no one will need more than that :-)

I think in a few years the limit to 8 cores will look just as silly.

On Thu, May 8, 2014 at 10:02 PM, Rik Cabanier caban...@gmail.com wrote:
 FYI
 From the WebKit side, people are leaning towards returning the logical CPU
 count but limit the maximum value to 8 [1].
 This should cover the vast majority of systems and use cases for this
 property and still not expose users that are on high value devices..

 1: https://bugs.webkit.org/show_bug.cgi?id=132588


 On Tue, May 6, 2014 at 2:30 PM, Rik Cabanier caban...@gmail.com wrote:




 On Tue, May 6, 2014 at 8:51 AM, Joe Gregorio jcgrego...@google.com
 wrote:

 On Tue, May 6, 2014 at 7:57 AM, João Eiras jo...@opera.com wrote:
 ...
 
  I guess everyone that is reading this thread understands the use cases
  well
  and agrees with them.
 
  The disagreement is what kind of API you need. Many people, rightly so,
  have
  stated that a core count gives little information that can be useful.
 
  It's better to have an API that determines the optimal number of
  parallel
  tasks that can run, because who knows what else runs in a different
  process
  (the webpage the worker is in, the browser UI, plugins, other webpages,
  iframes, etc) with what load. Renaming 'cores' to 'parallelTaskCount'
  would
  be a start.
 

 +1

 The solution proposed should actually be a solution to the problem as
 stated, which,
 from the abstract read:

The intended use for the API is to help developers make informed
 decisions regarding
the size of their worker threadpools to perform parallel algorithms.

 So the solution should be some information about the maximum number of
 parallel
 workers that a page can expect to run, which may have no relation to
 the number of
 cores, physical or virtual. The browser should be allowed to determine
 what that number
 is based on all the factors it has visibility to, such as load, cores,
 and policy.

 Returning the number is actually important, for example, physics
 engines for WebGL
 games, how you shard the work may depend on knowing how many parallel
 workers
 you should schedule.


 It seems everyone is in agreement that this API should return the number
 of useful parallel tasks.

 So far, people have proposed several names:
 - cores - this seems confusing since the returned number might be lower
 - concurrency - there can be more concurrent tasks than there are logical
 cores
 - hardwareConcurrency
 - parallelTaskCount

 Leaving the question of fingerprinting aside for now, what name would
 people prefer?

Re: [whatwg] Proposal: navigator.cores

[Joe Gregorio]

On Tue, May 6, 2014 at 7:57 AM, João Eiras jo...@opera.com wrote:
...

 I guess everyone that is reading this thread understands the use cases well
 and agrees with them.

 The disagreement is what kind of API you need. Many people, rightly so, have
 stated that a core count gives little information that can be useful.

 It's better to have an API that determines the optimal number of parallel
 tasks that can run, because who knows what else runs in a different process
 (the webpage the worker is in, the browser UI, plugins, other webpages,
 iframes, etc) with what load. Renaming 'cores' to 'parallelTaskCount' would
 be a start.


+1

The solution proposed should actually be a solution to the problem as
stated, which,
from the abstract read:

   The intended use for the API is to help developers make informed
decisions regarding
   the size of their worker threadpools to perform parallel algorithms.

So the solution should be some information about the maximum number of parallel
workers that a page can expect to run, which may have no relation to
the number of
cores, physical or virtual. The browser should be allowed to determine
what that number
is based on all the factors it has visibility to, such as load, cores,
and policy.

Returning the number is actually important, for example, physics
engines for WebGL
games, how you shard the work may depend on knowing how many parallel workers
you should schedule.

   --joe

Re: [whatwg] addPath and CanvasPathMethods

[Joe Gregorio]

On Fri, Mar 21, 2014 at 12:17 AM, Rik Cabanier caban...@gmail.com wrote:

 On Thu, Mar 20, 2014 at 4:24 PM, Robert O'Callahan rob...@ocallahan.org
 wrote:
  An implementation can turn #2 into #1 if the paths obviously don't
  overlap. If they might overlap, the author probably shouldn't be doing
 the
  latter!
 

 For this reason I don't particularly like the addPath API. It tricks
 authors into thinking that they will get a union of the paths.


  TBH I don't see why authors would choose the latter approach.
 

 I agree.
 'addPath' will always cause the generation of a new path so if an author
 chooses this strange approach, the retessellation will have to happen again
 anyway.


Agreed, the speed of Path2D comes from creating the object and then reusing
it multiple
times via fill, stroke or clip. Adding addPath to CRC2D would seem to
undermine
that and encourage non-optimal uses.

I've wondered at times about an API that made the const-ness of paths even
more explicit:

  var b = new Path2DBuilder();
  b.moveTo(...);
  b.ellipseTo(...);
  var path = b.getPath2D();

Where path has no attributes or methods.

But then I think that looks too much like Java

 -joe

Re: [whatwg] Canvas Path.addPath SVGMatrix not optimal?

[Joe Gregorio]

On Wed, Mar 19, 2014 at 4:46 PM, Dirk Schulze dschu...@adobe.com wrote:

 Hi,

 I just looked at the definition of Path.addPath[1]:

 void addPath(Path path, SVGMatrix? transformation);

 SVGMatrix is nullable but can not be omitted all together. Why isn’t it
 optional as well? I think it should be optional, especially because
 creating an SVGMatrix at the moment means writing:

 var matrix = document.createElementNS('http://www.w3.org/2000/svg
 ','svg').createSVGMatrix();


Agreed, that's painful, +1 for making it optional.

  -joe



 Greetings,
 Dirk

 [1]
 http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#path

Re: [whatwg] new constructor method for Path2D

[Joe Gregorio]

On Mon, Mar 10, 2014 at 2:02 PM, Rik Cabanier caban...@gmail.com wrote:


 What are you not sure about?

 The current Path2D interface might be unacceptably slow under certain
 circumstances and there's currently no way for authors to work around this.
 There has to be a hint. If not, I don't see a way that firefox will ship
 this.


What part is slow, the decoding and re-encoding, or is just always the
encoding step
that is slow?

I thought the speed of Path2D came from the reuse, that is, that the build
cost wasn't
a big concern because the speed came from reusing that same object over and
over
at up to 60fps?

Re: [whatwg] Drawing shapes on canvas

[Joe Gregorio]

On Mon, Jan 27, 2014 at 9:28 PM, Rik Cabanier caban...@gmail.com wrote:

 On Mon, Jan 27, 2014 at 3:15 PM, Joe Gregorio jcgrego...@google.comwrote:

 Agreed on the complexity and the interactions. Unfortunately dropping all
 of them but addPath does seem to leave
 Path with a hole in functionality since CanvasRenderingContext2D has both
 a fillText() and strokeText(). How about simplifying
 to just these two add* methods:

   void addPath(Path path, SVGMatrix? transformation);
   void addText(DOMString text, SVGMatrix? transformation, unrestricted
 double x, unrestricted double y, optional unrestricted double maxWidth);

 Note the removal of the CanvasDrawingStyles from addText.


 Unfortunately, that doesn't really help.
  For instance, let's say you request the path for the letter 'o'. It's
 represented by 2 closed paths.
 What winding rule should you use when you fill that path? Should the paths
 be oriented so you have to use a NZO fill or so you can use any winding
 rule?

 What happens if the path for a letter intersect with another path (or
 another letter)?


OK, I'm convinced that's going to be not very useful for filling if there
aren't some
guarantees about the winding of the resulting path, which is a hard problem.
So I'm fine with just sticking to addPath, which I think was your original
proposal ;-)

  void addPath(Path path, SVGMatrix? transformation);

Re: [whatwg] Drawing shapes on canvas

[Joe Gregorio]

On Mon, Jan 27, 2014 at 1:26 PM, Rik Cabanier caban...@gmail.com wrote:




 On Fri, Jan 24, 2014 at 12:08 PM, Joe Gregorio jcgrego...@google.comwrote:

 Rik,
   From the Skia perspective we have the following feedback on the
 proposal.


 Thanks for your feedback!



   While we can see how Shape2D can be implemented, it isn't clear that
 it's
   such a large performance benefit over what Path provides, so we aren't
   opposed to Shape2D, but don't believe implementing Path should be held
 up
   for the sake of Shape2D.  Path itself is a huge win for performance over
   having only a single current default path and has utility without the
 need
   for Shape2D.


 I agree.
 Maybe it's OK to have a staged approach where we introduce the concept of
 Path first and possible add shapes later.


   In general we would like to see a layered approach to drawing objects,
   starting with something primitive like Path, and at the most general a
   Display List[1] that contains the full set of capabilities of
   CanvasRenderingContext2D.  That layering could be done in two or three
   objects, either [Path, DisplayList] or [Path, Shape2D, DisplayList]. In
 all
   cases you can use the lower level objects to construct higher level
 objects,
   i.e. use one or more Paths to build a Shape2D, and use Paths and
 Shape2Ds
 to
   define a DisplayList.


 That is an interesting concept. Do you have a more detailed proposal or a
 prototype in the works?


My tentative plan for this quarter includes prototyping to inform a
proposal.


 At first blush, this seems more like streamlined SVG :-)

   What we'd like to see happen:
 1. Review the Path add* methods and possibly simplify them, see below.
 2. Keep the rest of the Path object and the Path related methods on
 the
CanvasRenderingContext2D.
 3. If Shape2D moves forward do it by adding different versions of
 fill,
clip, etc to CanvasRenderingContext2D, such as:

void fill(optional CanvasFillRule fillRule = nonzero);
void fill(Path path, optional CanvasFillRule fillRule = nonzero);
void fill(Shape2D shape);

 4. Possibly work on a DisplayList design, but only after some
experimentation.

   We have some particular feedback on the Shape2D design that is inline
 below:

 [1] http://en.wikipedia.org/wiki/Display_list

  All,
 
  around a year ago, I wrote a blog post [1] that introduced a new 'Shape'
  class that described a filled or stroked region or an area of text.
 Java2D
  has a similar concept that they call 'Area' [2].
 
  We've had some discussions but it doesn't look like there was any sort
 of
  conclusion. I'd like to pick it back up now that we have a partial
  implementation of the Path object and people are starting to look into
  extending it.
 
  I'll reiterate my proposal:
  1. remove all the addxxx methods from the Path2D object [3]
  Path object are just containers for segments. Aggregating segments will
  generally not give the desired results since the segments will interact
  (see [1]).
  AddPath *could* be kept if people see a strong use case.

 The add* methods could be simplified to:

   void addPath(Path path, SVGMatrix? transformation);
   void addPathByStrokingPath(Path path, CanvasDrawingStyles styles,
 SVGMatrix? transformation);
   void addText(DOMString text, CanvasDrawingStyles styles, SVGMatrix?
 transformation, unrestricted double x, unrestricted double y, optional
 unrestricted double maxWidth);
   void addTextAlongPath(DOMString text, CanvasDrawingStyles styles,
 SVGMatrix? transformation, Path path, optional unrestricted double
 maxWidth);

 The functionality of the addPathByStrokingText methods below can be done
 by
 applying the above methods.

   void addPathByStrokingText(DOMString text, CanvasDrawingStyles styles,
 SVGMatrix? transformation, unrestricted double x, unrestricted double y,
 optional unrestricted double maxWidth);
   void addPathByStrokingText(DOMString text, CanvasDrawingStyles styles,
 SVGMatrix? transformation, Path path, optional unrestricted double
 maxWidth);


 My issue with this add* methods is that they likely will not do what an
 author expects since the path segments will interact in unexpected ways.
 In addition, I think no browser follows the spec for tracing a path [1].
 Since paths will interact with the segments that that algorithm generates,
 we will get into interoperability issues.


Agreed on the complexity and the interactions. Unfortunately dropping all
of them but addPath does seem to leave
Path with a hole in functionality since CanvasRenderingContext2D has both a
fillText() and strokeText(). How about simplifying
to just these two add* methods:

  void addPath(Path path, SVGMatrix? transformation);
  void addText(DOMString text, SVGMatrix? transformation, unrestricted
double x, unrestricted double y, optional unrestricted double maxWidth);

Note the removal of the CanvasDrawingStyles from addText.




 
  2. introduce a new class

[whatwg] Drawing shapes on canvas

[Joe Gregorio]

Rik,
  From the Skia perspective we have the following feedback on the proposal.

  While we can see how Shape2D can be implemented, it isn't clear that it's
  such a large performance benefit over what Path provides, so we aren't
  opposed to Shape2D, but don't believe implementing Path should be held up
  for the sake of Shape2D.  Path itself is a huge win for performance over
  having only a single current default path and has utility without the need
  for Shape2D.

  In general we would like to see a layered approach to drawing objects,
  starting with something primitive like Path, and at the most general a
  Display List[1] that contains the full set of capabilities of
  CanvasRenderingContext2D.  That layering could be done in two or three
  objects, either [Path, DisplayList] or [Path, Shape2D, DisplayList]. In
all
  cases you can use the lower level objects to construct higher level
objects,
  i.e. use one or more Paths to build a Shape2D, and use Paths and Shape2Ds
to
  define a DisplayList.

  What we'd like to see happen:
1. Review the Path add* methods and possibly simplify them, see below.
2. Keep the rest of the Path object and the Path related methods on the
   CanvasRenderingContext2D.
3. If Shape2D moves forward do it by adding different versions of fill,
   clip, etc to CanvasRenderingContext2D, such as:

   void fill(optional CanvasFillRule fillRule = nonzero);
   void fill(Path path, optional CanvasFillRule fillRule = nonzero);
   void fill(Shape2D shape);

4. Possibly work on a DisplayList design, but only after some
   experimentation.

  We have some particular feedback on the Shape2D design that is inline
below:

[1] http://en.wikipedia.org/wiki/Display_list

 All,

 around a year ago, I wrote a blog post [1] that introduced a new 'Shape'
 class that described a filled or stroked region or an area of text. Java2D
 has a similar concept that they call 'Area' [2].

 We've had some discussions but it doesn't look like there was any sort of
 conclusion. I'd like to pick it back up now that we have a partial
 implementation of the Path object and people are starting to look into
 extending it.

 I'll reiterate my proposal:
 1. remove all the addxxx methods from the Path2D object [3]
 Path object are just containers for segments. Aggregating segments will
 generally not give the desired results since the segments will interact
 (see [1]).
 AddPath *could* be kept if people see a strong use case.

The add* methods could be simplified to:

  void addPath(Path path, SVGMatrix? transformation);
  void addPathByStrokingPath(Path path, CanvasDrawingStyles styles,
SVGMatrix? transformation);
  void addText(DOMString text, CanvasDrawingStyles styles, SVGMatrix?
transformation, unrestricted double x, unrestricted double y, optional
unrestricted double maxWidth);
  void addTextAlongPath(DOMString text, CanvasDrawingStyles styles,
SVGMatrix? transformation, Path path, optional unrestricted double
maxWidth);

The functionality of the addPathByStrokingText methods below can be done by
applying the above methods.

  void addPathByStrokingText(DOMString text, CanvasDrawingStyles styles,
SVGMatrix? transformation, unrestricted double x, unrestricted double y,
optional unrestricted double maxWidth);
  void addPathByStrokingText(DOMString text, CanvasDrawingStyles styles,
SVGMatrix? transformation, Path path, optional unrestricted double
maxWidth);


 2. introduce a new class 'Shape2D'
 Interface:

 [Constructor,
   Constructor(Path2D , CanvasWindingRule = nonzero),
   Constructor(Path2D , CanvasDrawingStyles, SVGMatrix?), // strokes a path
   Constructor(DomString text, CanvasDrawingStyles, SVGMatrix?,
unrestricted
 double, unrestricted double, boolean isStroked = false, optional
 unrestricted double)]
 interface Shape2D{
 Shape2D transform(matrix); // returns a transformed path

Why not do this as another constructor?

  Constructor(Shape2D, SVGMatrix)

 Shape2D add(Shape2D); // returns a path that is the union of the 2
paths

Just to clarify, add() means a union of the two shapes, with no side-effects
resulting from winding rules of the individual path?

Shape2D seems reasonable and useful just as an immutable capture of all
coverage aspects of geometry. If add() is hard for platforms to support,
or
is expensive and clients don't know that, perhaps we can leave it out of
this
version. If we really want to have add(), why not include the full
compliment
of Set operations  [ diff, xor, intersect ], which are no harder to
implement
(afaik) once you've implemented add().

 }

 This class will represent a painted area. Because it knows the winding and
 stroking rules, the browser will be able to do expensive math in advance.
 It can also cache the region on the GPU.
 constructors:
 a. default constructor that creates an empty region
 b. constructor that take a path and a winding rule. This represents a
 filled region
 c. constructor that takes a path, 

Re: [whatwg] Web Forms 2.0

[Joe Gregorio]

On Apr 5, 2005 6:50 PM, Ian Hickson [EMAIL PROTECTED] wrote:
 On Sat, 26 Mar 2005, Joe Gregorio wrote:
 
  In the Web Forms 2.0 Working Draft dated 16 March 2005
 
 5.6. Submitting the encoded form data set
 
  If the specified method is not one of get, post,
   put, or delete then it is treated as get in the tables below.
 
  It would be much better if just one word of that sentence was changed:
 
  If the specified method is not one of get, post,
   put, or delete then it is treated as *post* in the tables below.
 
 I agree. Sadly, doing this would break compatibility with existing
 implementations, which all treat unknown values as get.

Would that really 'break' anything? If that is the default behaviour today
then clients would expect not to be able to send a request body with a
method outside POST and PUT. Adding that capability won't break their
code, will it?

   Thanks,
-joe

-- 
Joe Gregoriohttp://bitworking.org