[Webkit-unassigned] [Bug 48516] GraphicsContext: Remove "current path" and have strokePath, fillPath and clipPath take a Path argument

[bugzilla-daemon at webkit.org]

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





--- Comment #22 from Dirk Schulze <krit at webkit.org>  2010-10-29 04:18:14 PST ---
(In reply to comment #20)
> (In reply to comment #19)
> > (In reply to comment #17)
> > > (In reply to comment #16)
> > > > (In reply to comment #15)
> > > > > I'm not talking about GraphicsContext::addPath. In cg Path wraps a CGPath object, and CGContextAddPath just takes a CGPathRef (handle to the CGPath). That is _not_ a copy.
> > > > 
> > > > And I was more thinking about Cairo. And we do a lot of cairo_copy_path there.
> > > 
> > > I wanted to move the discussion towards _our_ API, and how we can avoid copying Path, and making the GraphicsContext API nicer. I'd like to reach consensus about that first, then look at the individual graphic libraries.
> > 
> > haha. Before we can work on a "nicer" API for GraphicsContext we _have to_ discuss how we can implement it efficiently on platforms, not after we implemented it.
> Would you please read more carefully, to not spread more confusion than needed?
> I said we should _discuss_ how we like to have the API, I never said "implement it".
> 
> We should reach consensus on how the API _should_ look like. Then we can look how _and if_ the new API can be implemented efficiently, then reevaluate the desired design if needed.
> 
> > But I'm really fine with the new headline of this bug. We really don't want current path on Cairo. And I guess Martin and Alex agree to me. I'd like to have at least one comment of the Skia guys.
> > 
> > The work on WebKit does not really rely on this patch. So we should take the time now, instead of redesigning a few times.
> 
> *sigh* Dirk, please read more carefully, before replying. To restate: I never said, I want to implement the new design, but rather _think_ of a new design. If everybody agress the new design would be best, then let's see whether it can be implemented efficiently. If not, refine the design.

Great! So we agree to each other, fine. And I just wrote that from the Cairo point of few it is better to get rid of the current path concept, and therefor use to fillPath(Path&)/strokePath(Path&) is good. No need to be aggressive or irritated :-)

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.