Closed Bug 347458 Opened 18 years ago Closed 16 years ago

drawImage and clip() cause more bad clipping

Categories

(Core :: Graphics: Canvas2D, defect)

x86
Windows 2000
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: philip, Unassigned)

Details

(Keywords: testcase)

Attachments

(1 file)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1b1) Gecko/20060804 BonEcho/2.0b1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1b1) Gecko/20060804 BonEcho/2.0b1

In 1.8.1: When drawing an image, and then creating a path which is not an integer-aligned rectangle and then setting it as the clipping path, it actually ends up with the clipping path being (as far as I can tell) the intersection of that path and the image's destination rectangle. (The image shouldn't affect the clipping path.)

This has regressed somewhere between "Gecko/20060728 Firefox/1.5.0.6" and "Gecko/20060710 Firefox/2.0b1". It still fails in the latest 1.8 branch (with the checkin from bug 346421). It does work in "Gecko/20060804 Minefield/3.0a1" (from just before that checkin).

(This is affecting the canvas-using program I'm working on, and I can't think of any particularly nice workaround. I'm actually clipping to a non-rectangular polygon, so I can't just round it to integer coordinates. I suppose I could draw a zero-sized rectangle before the clip path and after the image, which does seem to fix it but doesn't seem like an entirely elegant solution...)

Reproducible: Always

Steps to Reproduce:
1. See test case.

Actual Results:  
There is a black canvas, with a gradient image in the top left corner, and a green rectangle in the bottom right corner of that image (not extending into the black region).

Expected Results:  
The green rectangle should be extending outside the image, and should appear centred on the canvas.
Attached file test case
Keywords: testcase
Ugh.  I'll try to fix, but the underlying bug is a pain.. maybe i'll just turn on the workaround on the branch as well.

A non-obvious js-level workaround is to put:

ctx.beginPath();
ctx.rect(0,0,0,0);
ctx.fill();

after the drawImage() call.  I'll see if I can make this unnecessary.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This WFM on trunk, and I assume we're not going to be making any branch changes.
Status: NEW → RESOLVED
Closed: 16 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: