Closed Bug 988309 Opened 6 years ago Closed 6 years ago

Add a nsRenderingContext ctor that takes a Moz2D DrawTarget

Categories

(Core :: Graphics, defect)

defect
Not set

Tracking

()

VERIFIED FIXED
mozilla31
Tracking Status
firefox29 --- verified
firefox30 --- verified
firefox31 --- verified

People

(Reporter: jwatt, Assigned: mattwoodrow)

References

Details

(Whiteboard: [assume verified by bug 991767])

Attachments

(1 file)

As part of the conversion to Moz2D we really need an nsRenderingContext ctor that takes a Moz2D DrawTarget. For example, when converting the code that creates a gfxPattern for an SVG mask to work on a temporary DrawTarget we need to wrap that DrawTarget in an nsRenderingContext in order to pass it to the SVG drawing code that draws the mask content.

There would be one major issue with such an nsRenderingContext, and that would be what to do for nsRenderingContext::ThebesContext(). We need any changes made to the gfxContext to be reflected onto the DrawTarget, and we need the initial state of the gfxContext to reflect the current state of the DrawTarget. For that we need the gfxContext to wrap the DrawTarget, and we need to initially set the gfxContext's transform and clip stack to be the same as the DrawTarget's. gfxContext::ContextForDrawTarget() currently does the former and sets the transform, but it does nothing with the clip stack. In fact Moz2D doesn't even provide a way to access information about the clip stack of a DrawTarget.

Alternatively we could convert all of the callers of nsRenderingContext::ThebesContext() to check for and handle a DrawTarget first, but there are a lot of them, and likely we get into the same issue unless we convert all of them in one big bang commit.
Assignee: nobody → jwatt
Sorry, stealing this since I need it to fix bug 991767.
Assignee: jwatt → matt.woodrow
Attachment #8402420 - Flags: review?(roc)
Blocks: 991767
https://hg.mozilla.org/mozilla-central/rev/f5b3731b5212
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Anything QA needs to do here in terms of testing?
Flags: needinfo?(matt.woodrow)
Nope, verifying bug 991767 should be sufficient.
Flags: needinfo?(matt.woodrow)
(In reply to Matt Woodrow (:mattwoodrow) from comment #4)
> Nope, verifying bug 991767 should be sufficient.

Okay thanks, I'll flag this as such.
Keywords: verifyme
Whiteboard: [assume verified by bug 991767]
Comment on attachment 8402420 [details] [diff] [review]
Add new nsRenderingContext ctor

[Approval Request Comment]
Bug caused by (feature/regressing bug #): Not a regression, but a prereq for bug 991767
User impact if declined: Can't uplift 991767 
Testing completed (on m-c, etc.): Been on m-c for a week or so.
Risk to taking this patch (and alternatives if risky): Essentially zero risk, entirely unused code without bug 991767.
String or IDL/UUID changes made by this patch: None
Attachment #8402420 - Flags: approval-mozilla-beta?
Attachment #8402420 - Flags: approval-mozilla-aurora?
Attachment #8402420 - Flags: approval-mozilla-beta?
Attachment #8402420 - Flags: approval-mozilla-beta+
Attachment #8402420 - Flags: approval-mozilla-aurora?
Attachment #8402420 - Flags: approval-mozilla-aurora+
(In reply to Matt Woodrow (:mattwoodrow) from comment #4)
> Nope, verifying bug 991767 should be sufficient.
Verified fixed FF 31
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.