Bug 3615 – canvas transform matrix does not apply to patterns

• Component: Layout and Rendering
• Status: RESOLVED FIXED

[Randy Reddig]

CanvasPattern usage is more interesting when it can be transformed by the
canvas' current transform matrix. Scaling/rotation of bitmaps make interesting
effects.

The WHATWG spec on the subject is ambiguous on the subject:

http://www.whatwg.org/specs/web-apps/current-work/#canvaspattern0

In addition, it specifies the origin of the pattern to be centered on the center
of the canvas, which makes the output pixels of a rendering operation dependent
on the size of the viewport, not orthagonal as all other raster ops.

[Ian 'Hixie' Hickson]

What's ambiguous?

[Randy Reddig]

Whether patterns (or gradients) are subject to transformation. The document does
not specify.

[Ian 'Hixie' Hickson]

"The transformation matrix is applied to all drawing operations prior to their
being rendered."

[Randy Reddig]

Okay, so you agree that Safari's behavior is incorrect then?

[Ian 'Hixie' Hickson]

I've no idea what Safari does, but if it ignores the transformation matrix when
painting patterns, then I'd say yes.

[Joost de Valk (AlthA)]

Then i'll say yes too :)

[John Sullivan]

This is also in Radar as <rdar://problem/4161599>

[Anders Carlsson]

Created attachment 2930 [details]
Create patterns lazily

Here's a patch that changes the behavior so that fill and stroke patterns are
created in the respective fill and stroke functions using the current CTM.

[Eric Seidel (no email)]

It might be interesting to compare this with how I did the (incomplete) pattern code for KCanvas.  The 
same fixes might be applicable there.

The file in question is
WebCore/kcanvas/device/quartz/KRenderingPaintServerQuartz.mm

[Dave Hyatt]

Comment on attachment 2930 [details]
Create patterns lazily

r=me

[Justin Garcia]

Landed this patch