Canvas globalAlpha not applied to pattern fills

RESOLVED WORKSFORME

Status

()

Core
Canvas: 2D
P1
normal
RESOLVED WORKSFORME
10 years ago
5 years ago

People

(Reporter: Philip Taylor, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(2 attachments)

(Reporter)

Description

10 years ago
User-Agent:       Opera/9.24 (X11; Linux i686; U; en)
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007103004 Minefield/3.0a9pre

Canvas pattern fills are not affected by globalAlpha.

Reproducible: Always

Steps to Reproduce:
1. fillStyle = createPattern(...)
2. globalAlpha != 1
3. fill()

Actual Results:  
globalAlpha is ignored, and the pattern is drawn as if globalAlpha=1.

Expected Results:  
globalAlpha should affect the pattern.

Same results on Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a9pre) Gecko/2007103004 Minefield/3.0a9pre

Comment 1

10 years ago
Created attachment 290728 [details] [diff] [review]
Makes canvas globalAlpha apply to pattern fill and stroke.

Comment 2

10 years ago
Created attachment 290794 [details]
Testcase for fillRect(), strokeRect(), fill() and stroke()

Updated

10 years ago
Attachment #290728 - Flags: review?
Ilmari: you'll need to request review from a specific person if you don't want the review request to be lost. See http://developer.mozilla.org/en/docs/Getting_your_patch_in_the_tree . I recommend vladimir@pobox.
Status: UNCONFIRMED → NEW
Ever confirmed: true

Updated

10 years ago
Attachment #290728 - Flags: review? → review?(vladimir)

Comment 4

10 years ago
Gavin: Aahh, thanks! So that's what the requestee field is for (I thought it'd go to the module maintainer if left blank.) Fixed.
Comment on attachment 290728 [details] [diff] [review]
Makes canvas globalAlpha apply to pattern fill and stroke.

Oy, sorry I haven't seen this yet!  Patch looks fine, though I don't understand < 0.999 -- why not just < 1.0 ?  Is the worry that we'll get a computed alpha value within epsilon of 1.0 that should really be treated as 1.0 for speed?
Attachment #290728 - Flags: review?(vladimir) → review+

Comment 6

9 years ago
Yes, speed^H^H^H^H^H premature optimization. Though I guess it should be < 1.0 - (1.0 / (1 << ALPHA_BIT_DEPTH)) instead.
Priority: -- → P1
This seems to be fixed.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.