On Mar 5, 2014, at 11:54 PM, Rik Cabanier <caban...@gmail.com> wrote:
> On Wed, Mar 5, 2014 at 2:43 PM, Ian Hickson <i...@hixie.ch> wrote: > >> On Wed, 5 Mar 2014, Jeff Muizelaar wrote: >>> On Mar 5, 2014, at 5:34 PM, Ian Hickson <i...@hixie.ch> wrote: >>>> On Wed, 5 Mar 2014, Rik Cabanier wrote: >>>>> >>>>> To work around this, we could add a couple of constructor methods to >>>>> the 2D context: >>>>> >>>>> Path2D createPath(); >>>>> >>>>> Creates a new empty Path object [...] >>>> >>>> This used to be how many Web APIs worked, but over the years we've >>>> received enormous volumes of feedback to the effect that >>>> constructor-based APIs are way better than factory-based APIs. Is >>>> there no way we could at least have all the canvases within a Document >>>> in Firefox use the same backend? It would be really unfortunate to >>>> have to use factories here to get around an implementation detail in >>>> one browser. >>> >>> The choice of backend depends on the size of the canvas. So it wouldn't >>> be easy to have all canvases within a document use the same backend. >> >> Ah, ok. >> >> This makes a factory method somewhat less useful, because what if the >> canvas changes size later? Do all the paths have to be "re-bound"? > > > for optimal performance, yes. > Rescaling a canvas is not that common of a scenario though. To switch the context of a created Path2d, you still need an abstraction of the path, don’t you? Some platforms are not able to return the created path. Many more are not able to return an unflattened path (which might not be an issue). So if you might need an abstraction anyway, is the performance problem that you need to do it on each drawing operation? There are clearly ways to work around such an issue. > > Maybe this hint would be useful for Chrome since they switch to software > under certain circumstances too I am unsure if it would. It is the same graphic library that manages the path object. Even if uses a different backend. Greetings, Dirk
