Remove nsISVGGlyphFragmentLeaf

RESOLVED FIXED in mozilla6

Status

()

Core
SVG
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: Robert Longson, Assigned: Robert Longson)

Tracking

(Blocks: 1 bug)

Trunk
mozilla6
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Assignee)

Description

6 years ago
nsISVGGlyphFragment leaf is only implemented by nsSVGGlyphFrame. We can remove it and make lots of methods non-virtual.
(Assignee)

Comment 1

6 years ago
Created attachment 530848 [details] [diff] [review]
patch
Assignee: nobody → longsonr
Attachment #530848 - Flags: review?(dholbert)
Attachment #530848 - Attachment is patch: true
Looks like nsISVGGlyphFragment.h has a documentation comment above the decls for GetEffecitve[XY|DxDy|Rotate].  We should probably preserve those, copying them over to nsSVGGlyphFrame.h, right?
Version: unspecified → Trunk
(Assignee)

Comment 3

6 years ago
Sure, and I should include the removal of nsISVGGlyphFragmentLeaf in the patch too!
(Assignee)

Comment 4

6 years ago
Created attachment 530854 [details] [diff] [review]
updated patch

Copied the comments into nsSVGGlyphFrame.h
Attachment #530848 - Attachment is obsolete: true
Attachment #530848 - Flags: review?(dholbert)
Attachment #530854 - Flags: review?(dholbert)
Comment on attachment 530848 [details] [diff] [review]
patch

>diff --git a/layout/svg/base/src/nsSVGGlyphFrame.h b/layout/svg/base/src/nsSVGGlyphFrame.h
>   // nsSVGGeometryFrame methods
>   gfxMatrix GetCanvasTM();
> 
>-  // nsISVGGlyphFragmentLeaf interface:
[...]
>+  nsresult GetStartPositionOfChar(PRUint32 charnum, nsIDOMSVGPoint **_retval);
>+  nsresult GetEndPositionOfChar(PRUint32 charnum, nsIDOMSVGPoint **_retval);
>+  nsresult GetExtentOfChar(PRUint32 charnum, nsIDOMSVGRect **_retval);
>+  nsresult GetRotationOfChar(PRUint32 charnum, float *_retval);

Probably best to add something in place of "// nsISVGGlyphFragmentLeaf interface" there, or else everything below it implicitly falls under the heading of "// nsSVGGeometryFrame methods".

e.g. // My own methods, or // nsSVGGlyphFrame methods, or something.

>   // nsISVGGlyphFragmentNode interface:
>   // These do not use the global transform if NS_STATE_NONDISPLAY_CHILD

For logical organization, these inherited methods' declarations should probably move up top now, right?  So that we've got
 // methods from one iface
 ...
 // methods from another iface
 ...
 // my own methods

If that makes sense, maybe that move could happen in a second patch here that only moves these declarations without actually changing anything.

>+nsSVGTextContainerFrame::GetGlyphFrameAtCharNum(nsISVGGlyphFragmentNode* node,
>+                                                PRUint32 charnum,
>+                                                PRUint32 *offset)
> {
>-  nsISVGGlyphFragmentLeaf *fragment = node->GetFirstGlyphFragment();
>+  nsSVGGlyphFrame *fragment = node->GetFirstGlyphFrame();

Nit: in most places, your patch does s/fragment/frame/ on the naming of variables, but it looks like you might have missed this spot.
Comment on attachment 530854 [details] [diff] [review]
updated patch

>@@ -450,10 +450,10 @@ nsSVGTextContainerFrame::BuildPositionLi
>-    } else if (leaf) {
>+    } else if (mContent->IsNodeOfType(nsINode::eTEXT)) {
>+      nsSVGGlyphFrame *leaf = static_cast<nsSVGGlyphFrame*>(kid);

Are we absolutely sure that there couldn't be any other eText type nodes here?

If so, add a NS_ABORT_IF_FALSE(kid->GetType() == nsGkAtoms::svgGlyphFrame
(and if not, maybe use GetType() in place of IsNodeOfType.)
(In reply to comment #6)
> Are we absolutely sure that there couldn't be any other eText type nodes
> here?

(or rather, any other frames for eTEXT-type nodes)

I'm guessing we're sure, but just want to double-check (and get your feeling on how future-proof this assumption is), since you know this text code better than I do.
(Assignee)

Comment 8

6 years ago
Created attachment 530857 [details] [diff] [review]
updated patch
Attachment #530854 - Attachment is obsolete: true
Attachment #530854 - Flags: review?(dholbert)
Attachment #530857 - Flags: review?(dholbert)
(Assignee)

Comment 9

6 years ago
(In reply to comment #7)
> (In reply to comment #6)
> > Are we absolutely sure that there couldn't be any other eText type nodes
> > here?

Yes, with the code as it is at the moment. Even so there's no harm changing to check the frame directly so that's what I've done.
Comment on attachment 530857 [details] [diff] [review]
updated patch

Looks great!
Attachment #530857 - Flags: review?(dholbert) → review+
Blocks: 105431
(Assignee)

Updated

6 years ago
Keywords: checkin-needed
http://hg.mozilla.org/mozilla-central/rev/23430875e861
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Keywords: checkin-needed
Resolution: --- → FIXED
Target Milestone: --- → mozilla6
You need to log in before you can comment on or make changes to this bug.