Re: [whatwg] Proposal: navigator.cores
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 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 wrote: >> >> >> >> >> On Tue, May 6, 2014 at 8:51 AM, Joe Gregorio >> wrote: >>> >>> On Tue, May 6, 2014 at 7:57 AM, João Eiras 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
On Tue, May 6, 2014 at 7:57 AM, João Eiras 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] Canvas Path.addPath SVGMatrix not optimal?
On Wed, Mar 19, 2014 at 4:46 PM, Dirk Schulze 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] addPath and CanvasPathMethods
On Fri, Mar 21, 2014 at 12:17 AM, Rik Cabanier wrote: > On Thu, Mar 20, 2014 at 4:24 PM, Robert O'Callahan >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] new constructor method for Path2D
On Mon, Mar 10, 2014 at 2:02 PM, Rik Cabanier 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
On Mon, Jan 27, 2014 at 9:28 PM, Rik Cabanier wrote: > > On Mon, Jan 27, 2014 at 3:15 PM, Joe Gregorio wrote: >> >> 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
On Mon, Jan 27, 2014 at 1:26 PM, Rik Cabanier wrote: > > > > On Fri, Jan 24, 2014 at 12:08 PM, Joe Gregorio wrote: > >> 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 do
[whatwg] Drawing shapes on canvas
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 re
