Closed Bug 1937109 Opened 2 months ago Closed 26 days ago

drawImage should respect -moz-context-properties for a SVG image source

Categories

(Core :: Graphics: Canvas2D, enhancement)

enhancement

Tracking

()

RESOLVED FIXED
136 Branch
Tracking Status
firefox136 --- fixed

People

(Reporter: mossop, Assigned: mossop)

References

Details

Attachments

(1 file, 1 obsolete file)

In a chrome document you can have an image element containing an SVG image styled via -moz-context-properties. Using drawImage with this as the source ignores those properties.

Attachment #9444104 - Attachment description: WIP: Bug 1937109: Respect -moz-context-properties when using an SVG image as the source for drawImage → Bug 1937109: Respect -moz-context-properties when using an SVG image as the source for drawImage. r=jfkthame!

The following patch is waiting for review from a reviewer who resigned from the review:

ID Title Author Reviewer Status
D232369 Bug 1937109: Respect -moz-context-properties when using an SVG image as the source for drawImage. r=jfkthame! mossop jgilbert: Resigned from review

:mossop, could you please find another reviewer?

For more information, please visit BugBot documentation.

Flags: needinfo?(dtownsend)
Severity: -- → N/A
Type: defect → enhancement
Flags: needinfo?(dtownsend)

Hmm, this is an interesting case actually (IMO).... it raises the question of what the "context element" ought to be in such an example. (And the SVG2 spec doesn't seem to help, as it only deals with markers and <use> elements.)

The patch here makes context-fill and -stroke use the values from the <img> element's style, which is one possible interpretation of "context", but ISTM that it would possibly be more useful (and perhaps intuitive?) if "context" referred to the context in which the image is being used, i.e. the paint style of the <canvas> context when it's being drawn. So then you could have a single <img> that uses context-* paint values, and have it paint with different colors depending on the current paint style of the destination where you're drawing it.

This seems more analogous to the (SVG2-defined) case of painting a subtree via a <use> element, where "the context element is that ‘use’ element", i.e. the context colors are determined separately at each point of use, not constants defined at the source of the thing being (reusably) painted.

WDYT, does this seem worth considering as an alternative design? Or is it nonsensical or unuseful for some reason?

Also cc'ing Robert in case he has any thoughts on this from an SVG perspective (noting that this is outside of anything that's currently spec'd, AFAIK).

Flags: needinfo?(dtownsend)

(In reply to Jonathan Kew [:jfkthame] from comment #3)

Hmm, this is an interesting case actually (IMO).... it raises the question of what the "context element" ought to be in such an example. (And the SVG2 spec doesn't seem to help, as it only deals with markers and <use> elements.)

The patch here makes context-fill and -stroke use the values from the <img> element's style, which is one possible interpretation of "context", but ISTM that it would possibly be more useful (and perhaps intuitive?) if "context" referred to the context in which the image is being used, i.e. the paint style of the <canvas> context when it's being drawn. So then you could have a single <img> that uses context-* paint values, and have it paint with different colors depending on the current paint style of the destination where you're drawing it.

This seems more analogous to the (SVG2-defined) case of painting a subtree via a <use> element, where "the context element is that ‘use’ element", i.e. the context colors are determined separately at each point of use, not constants defined at the source of the thing being (reusably) painted.

I've put this up as an alternative patch. It turned out to be quite straightforward. I've retained needing to set -moz-context-properties (though on the canvas element now). See what you think.

Flags: needinfo?(dtownsend)

Are we restricting this to Chrome only or mozilla only? jwatt was very reluctant to extend context-fill/stroke outside of what the specification allows (markers and use) which is why everything else is mozilla only i.e. mozilla authored extensions or chrome.

(In reply to Robert Longson [:longsonr] from comment #6)

Are we restricting this to Chrome only or mozilla only? jwatt was very reluctant to extend context-fill/stroke outside of what the specification allows (markers and use) which is why everything else is mozilla only i.e. mozilla authored extensions or chrome.

I was only intending on doing it for chrome only as that is all I need it for.

Yes, I don't think any of this should be exposed to web content unless we first engage in an appropriate standards discussion. The use of -moz-context-properties would mean it'd be behind the svg.context-properties.content.enabled pref (which is disabled by default), but if we switch to a canvas2d attribute (per discussion in the second patch) I assume that'll be declared as chrome-only in the webidl.

Attachment #9459885 - Attachment description: Bug 1937109: Use canvas stroke and fill settings when drawing an SVG into a canvas. r=jfkthame! → Bug 1937109: Use canvas stroke and fill settings when drawing an SVG into a canvas. r=jfkthame!,emilio!
Pushed by dtownsend@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/21f1329b5670 Use canvas stroke and fill settings when drawing an SVG into a canvas. r=jfkthame,emilio
Attachment #9444104 - Attachment is obsolete: true
Status: NEW → RESOLVED
Closed: 26 days ago
Resolution: --- → FIXED
Target Milestone: --- → 136 Branch
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: