drawImage clips the image instead of positioning it on the correct x and y coordinates

RESOLVED FIXED

Status

()

Core
Canvas: 2D
RESOLVED FIXED
12 years ago
12 years ago

People

(Reporter: Kamiel Martinet, Assigned: vlad)

Tracking

({fixed1.8})

Trunk
x86
Windows XP
fixed1.8
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(4 attachments)

(Reporter)

Description

12 years ago
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050901 Firefox/1.6a1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050901 Firefox/1.6a1

when I try to place an image on the canvas using de drawImage method, instead of
positioning the image on the correct x and y coordinates, the image gets clipped
x pixels from the left and y pixels from the top.

Reproducible: Always

Steps to Reproduce:
1.see attachment
2 [review].
3.

Actual Results:  
The image gets clipped 30 pixels from the left and 30 from the top

Expected Results:  
Image should be placed 30 pixels from the left and 30 from the top
(Reporter)

Comment 1

12 years ago
Created attachment 194571 [details]
Testcase
(Reporter)

Updated

12 years ago
Flags: blocking1.8b5?
(Reporter)

Comment 2

12 years ago
Created attachment 194579 [details]
Testcase result

The result I get when I run the testcase

Comment 3

12 years ago
Using an 09/01 branch Windows build, I see no clipping on the image. It is
properly offset 30 pixels by 30 pixels. 

You reported this bug using a 1.6a1 build. Please see if these problems are on
branch builds before marking them as branch blockers. 

Triage team: This nomination should be removed, I belive this is trunk only.

Comment 4

12 years ago
I get what I would believe to be the expected results with Deer Park alpha 2 rv:
1.8b4 build 20050901 under XP Pro SP2 here. WFM 

Screenshot coming.

Comment 5

12 years ago
Created attachment 194633 [details]
Expected results?

Screenshot (top left corner only) when using Deer Park alpha 2 rv: 1.8b4 build
20050901 under XP Pro SP2.

Comment 6

12 years ago
> You reported this bug using a 1.6a1 build. Please see if these problems are on
> branch builds before marking them as branch blockers. 

Kamiel, you can not request a blocking flag on the branch if you can not see or
have someone reproduce the layout problem on the branch to begin with.

As far as I can see and say, the image is rendered accordingly, as expected in
1.8b4 build 20050901.
I'm pretty sure this is being caused by the new way the CTM is handled for
pattern sources by cairo.  It's trunk-only; the cairo used on the branch still
does things the "old way".  I'll take care of it on the trunk in a little bit;
canvas will get rewritten to use thebes, and i'll just do it as part of that.
Assignee: nobody → vladimir
Status: UNCONFIRMED → NEW
Ever confirmed: true
Flags: blocking1.8b5?
Depends on: 306801
(Reporter)

Comment 8

12 years ago
It seems the branch builds now also suffer from this same bug. Tested with
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b5) Gecko/20051007
Firefox/1.4.1. 

Vladimir, Are the branch builds now also using the 'new way' of drawing images?
Created attachment 198953 [details] [diff] [review]
canvas-image-offset-fix.patch

Fallout from upgrading the version of cairo; handling of the CTM and surface
sources changed.  This should fix it; patch is for trunk and for branch.
Attachment #198953 - Flags: review?(tor)

Updated

12 years ago
Attachment #198953 - Flags: review?(tor) → review+
Comment on attachment 198953 [details] [diff] [review]
canvas-image-offset-fix.patch

Requesting 1.8rc1 approval; canvas bug fix, fixes drawing of images with the
recent cairo 1.0 update.  Low risk and straightforward patch; anything that it
might break is canvas-related.
Attachment #198953 - Flags: approval1.8rc1?

Updated

12 years ago
Attachment #198953 - Flags: approval1.8rc1? → approval1.8rc1+
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Keywords: fixed1.8
Resolution: --- → FIXED
No longer depends on: 306801

Comment 11

12 years ago
This issue is also seen in Firefox 1.5 beta 2. Will it be fixed in the next milestone release of Firefox 1.5?
You need to log in before you can comment on or make changes to this bug.