Closed
Bug 988309
Opened 10 years ago
Closed 10 years ago
Add a nsRenderingContext ctor that takes a Moz2D DrawTarget
Categories
(Core :: Graphics, defect)
Core
Graphics
Tracking
()
VERIFIED
FIXED
mozilla31
People
(Reporter: jwatt, Assigned: mattwoodrow)
References
Details
(Whiteboard: [assume verified by bug 991767])
Attachments
(1 file)
1.71 KB,
patch
|
roc
:
review+
Sylvestre
:
approval-mozilla-aurora+
Sylvestre
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•10 years ago
|
Assignee: nobody → jwatt
Assignee | ||
Comment 1•10 years ago
|
||
Sorry, stealing this since I need it to fix bug 991767.
Assignee: jwatt → matt.woodrow
Attachment #8402420 -
Flags: review?(roc)
Attachment #8402420 -
Flags: review?(roc) → review+
Comment 2•10 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/f5b3731b5212
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla31
Anything QA needs to do here in terms of testing?
Flags: needinfo?(matt.woodrow)
Assignee | ||
Comment 4•10 years ago
|
||
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.
Assignee | ||
Comment 6•10 years ago
|
||
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?
Updated•10 years ago
|
Attachment #8402420 -
Flags: approval-mozilla-beta?
Attachment #8402420 -
Flags: approval-mozilla-beta+
Attachment #8402420 -
Flags: approval-mozilla-aurora?
Attachment #8402420 -
Flags: approval-mozilla-aurora+
Comment 7•10 years ago
|
||
https://hg.mozilla.org/releases/mozilla-aurora/rev/65566909c15a https://hg.mozilla.org/releases/mozilla-beta/rev/843dc71f729b
status-firefox29:
--- → fixed
status-firefox30:
--- → fixed
Comment 8•10 years ago
|
||
(In reply to Matt Woodrow (:mattwoodrow) from comment #4) > Nope, verifying bug 991767 should be sufficient. Verified fixed FF 31
Status: RESOLVED → VERIFIED
Comment 9•10 years ago
|
||
Also verified FF 29, 30 in bug 991767.
You need to log in
before you can comment on or make changes to this bug.
Description
•