Closed Bug 690643 Opened 12 years ago Closed 11 years ago

Canvas transformations after beginPath() is not applied to 2nd call of stroke()s or fill()s.


(Core :: Graphics: Canvas2D, defect)

Windows 7
Not set



Tracking Status
firefox14 - affected
firefox15 - ---


(Reporter: iso2022jp, Assigned: bas.schouten)


(Keywords: regression)


(3 files)

Attached image canvas.png
User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20100101 Firefox/7.0
Build ID: 20110922153450

Steps to reproduce:

User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:7.0) Gecko/20100101 Firefox/7.0

Just run following code. (omit some HTML elements...)

		<script type="text/javascript">		

			window.addEventListener('load', function () {

				var canvas = document.getElementById('board-canvas');
				var context = canvas.getContext('2d');
				context.translate(200, 200);

				context.fillStyle = '#eeeeee';
				context.strokeStyle = '#000000';
				context.moveTo(0, 50);
				context.lineTo(50, 50);

				context.translate(100, 100);
				context.lineTo(50, 0);



<canvas width="400" height="400" id="board-canvas" style="border: 1px solid silver">

Actual results:

stroke() and fill() is not rendered same location.

It seems secondary or later call of stroke()s or fill()s are ignored transformations after the beginPath().

No ploblems with Firefox 6.

Expected results:

stroke() and fill() is rendered same location.

We have the same problem in FF 7.0.1


Both fill and stroke should be in the same place.
Works in FF6 not in FF7.
Hrm, I just ran accross this issue
Component: General → Canvas: 2D
Product: Firefox → Core
QA Contact: general → canvas.2d
Version: 7 Branch → Trunk
It seems this is still here, I missed it because of it not being in any of the graphics components sadly :(. I'll look into this.
Ever confirmed: true
This is still happening on Firefox 12 on the Mac (but not Windows):
Notice how the stroke and fill end up rendered in different places.

I'm on the Google Maps API team and we've recently run into this issue. Would I be able to ask if there has been any progress on this particular bug please?
I only had Firefox 4 and 15 handy to test; definitely a regression though.
Assignee: nobody → bas.schouten
From the bug description, this is not a recent regression. No need to track for release.
Sadly transform/path management for Azure is quite complex for Canvas. We were not correctly marking mPathTransformWillUpdate false when creating a device space pathbuilder. This means that although the first draw, because of code ordering where the device space path builder is considered after a present user space path, would work fine. The second one would consider a user space path and it would try to apply a transformation it thought still had to be processed. This patch fixes that issue. I will add a reftest as well.
Attachment #626301 - Flags: review?(roc)
Comment on attachment 626304 [details] [diff] [review]
Add a reftest for repeated drawing after changing transforms

Review of attachment 626304 [details] [diff] [review]:

r+ with that fixed

::: layout/reftests/bugs/690643-1.html
@@ +20,5 @@
> +}
> +  </script>
> + </head>
> +<body onload="draw()">
> + <canvas id="canvas" width="300" height="300"></canvas>

You can simplify these tests (and make them a fraction faster) by just putting your script after the <canvas> element in the DOM and running the code synchronously instead of waiting for the load event.
Attachment #626304 - Flags: review?(roc) → review+

(99db41088385 landed with bug 690743 in the commit message, I've popped a note over in that bug in case anyone is coming via hg annotate)
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla15
Thanks for looking at this issue so quickly - much appreciated.
You need to log in before you can comment on or make changes to this bug.