tor Assignee
	Description • 18 years ago

Start of the switch of SVG code to thebes...

	tor Assignee
	Comment 2 • 18 years ago

Start of the move over to thebes entirely in the SVG code.  This only removes the remains of the renderer layer (nsSVGRendererCanvas) - later bugs/patches will continue to remove the direct cairo usage.

I'll post to .builds announcing that SVG will soon switch to depend on cairo gfx.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 4 • 18 years ago

Do you want me to review this now? You can't land it yet, I assume.

	tor Assignee
	Comment 5 • 18 years ago

(In reply to comment #4)
> Do you want me to review this now? You can't land it yet, I assume.

Yes, I would like it reviewed now.

Why couldn't I land it?  I just need to coordinate with the tinderboxes to have svg turned off on OS-X for now.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 8 • 18 years ago

+  nsSVGOuterSVGFrame* outerSVGFrame = nsSVGUtils::GetOuterSVGFrame(this);
+  if (!outerSVGFrame)
+    return NS_ERROR_FAILURE;
+
+  nsCOMPtr<nsIRenderingContext> ctx = outerSVGFrame->GetRenderingContext();

Why are we getting nsIRenderingContext from the outerSVGFrame? Can't we just create a temporary nsIRenderingContext that wraps aContext?

	tor Assignee
	Comment 9 • 18 years ago

(In reply to comment #8)
> +  nsSVGOuterSVGFrame* outerSVGFrame = nsSVGUtils::GetOuterSVGFrame(this);
> +  if (!outerSVGFrame)
> +    return NS_ERROR_FAILURE;
> +
> +  nsCOMPtr<nsIRenderingContext> ctx = outerSVGFrame->GetRenderingContext();
> 
> Why are we getting nsIRenderingContext from the outerSVGFrame? Can't we just
> create a temporary nsIRenderingContext that wraps aContext?

Partly because I didn't think of it, partly because doing that seems to require having a nsIDeviceContext which isn't available.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 10 • 18 years ago

+  nsresult SetupCairoFill(gfxContext *aContext,
                           cairo_t *aCtx,
                           void **aClosure);

Why do we need to pass both aContext and aCtx here? Can't we just pass aContext and use aContext->GetCairo as needed?

+  nsresult GetGlobalTransform(cairo_t *ctx, gfxContext *aContext);

Same question

+  nsRefPtr<gfxContext> ctx =
+    (gfxContext *)aRenderingContext.GetNativeGraphicData(nsIRenderingContext::NATIVE_THEBES_CONTEXT);

Why do you need a strong ref here? Also, use NS_STATIC_CAST.

+already_AddRefed<nsIRenderingContext>
+nsSVGOuterSVGFrame::GetRenderingContext()

And why does this need to add a ref?

+nsSVGPathGeometryFrame::GeneratePath(cairo_t *ctx, gfxContext* aContext)

It's not really clear why we need two context parameters here. Is it because we don't have a gfxContext when we're hit testing, but we need the aContext to get its matrix when drawing? Could we create a temporary aContext for hit-testing?

+  nsRefPtr<gfxUnknownSurface> tmpSurface =
+    new gfxUnknownSurface(patternSurface);
+  if (!tmpSurface)
+    return NS_ERROR_FAILURE;

Could we stack-allocate this? If we can't, it would be nice to change things so we can allocate temporary wrappers (like you did with gfxContext earlier). Check with vlad/pav?

I'm not really comfortable with the global render-mode. Should we perhaps define some sort of nsSVGRenderState struct containing the render mode, the gfxContext, and possibly other things, and use that as the parameter to PaintSVG? It seems to me that the current code would at least need to save and restore the render mode when it changes the render mode, e.g. in nsSVGClipPathFrame.cpp. If we had nsSVGRenderState we could put the nsIRenderingContext* in there too, so we wouldn't need the cache-it-in-nsSVGOuterFrame hack.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 12 • 18 years ago

Comment on attachment 244245 [details] [diff] [review]
update per review comments

+  cairo_t *aCtx = aContext->GetCairo();

Take the plunge and rename to "ctx", please :-)

+  nsCOMPtr<nsIRenderingContext> mRenderingContext;

We don't need this in nsSVGOuterSVGFrame any more, right?

This is nice. One more thing we could do. nsSVGRenderState doesn't need an nsTArray stack. Instead we could have a helper class ... nsAutoSVGRenderMode say ... whose constructor saves the current render mode and sets the new mode, and whose destructor restores the old render mode.

	Robert O'Callahan (:roc) (email my personal email if necessary)
	Comment 14 • 18 years ago

Comment on attachment 244320 [details] [diff] [review]
all stack, all the time :)

Move nsAutoSVGRenderMode to nsSVGUtils.h next to nsSVGRenderState.

	tor Assignee
	Comment 15 • 18 years ago

Version for checkin, once I've reminded people that svg will need to be disabled on non-cairo builds and had the tinderbox configurations prepared.

	tor Assignee
	Comment 18 • 18 years ago

Checked in.  Needed to disable SVG on Camino until they switch to cairo gfx (bug 358390).