Last Comment Bug 690643 - Canvas transformations after beginPath() is not applied to 2nd call of stroke()s or fill()s.
: Canvas transformations after beginPath() is not applied to 2nd call of stroke...
Status: RESOLVED FIXED
: regression
Product: Core
Classification: Components
Component: Canvas: 2D (show other bugs)
: Trunk
: x86_64 Windows 7
: -- normal (vote)
: mozilla15
Assigned To: Bas Schouten (:bas.schouten)
:
Mentors:
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2011-09-29 20:20 PDT by Hiroyuki Ushito
Modified: 2015-10-07 18:52 PDT (History)
7 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
affected
-


Attachments
canvas.png (1.15 KB, image/png)
2011-09-29 20:20 PDT, Hiroyuki Ushito
no flags Details
Properly mark transform dealt with once a device space path builder is created (961 bytes, patch)
2012-05-22 20:11 PDT, Bas Schouten (:bas.schouten)
roc: review+
Details | Diff | Splinter Review
Add a reftest for repeated drawing after changing transforms (2.00 KB, patch)
2012-05-22 20:26 PDT, Bas Schouten (:bas.schouten)
roc: review+
Details | Diff | Splinter Review

Description Hiroyuki Ushito 2011-09-29 20:20:18 PDT
Created attachment 563641 [details]
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.beginPath();
				context.moveTo(0, 50);
				context.lineTo(50, 50);

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

				context.stroke();
				context.fill();
				
			});

		</script>

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


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.
Comment 1 Jay 2011-10-07 02:40:27 PDT
+1

We have the same problem in FF 7.0.1

Example:
http://jsfiddle.net/stRpr/4/

Both fill and stroke should be in the same place.
Works in FF6 not in FF7.
Comment 2 Bas Schouten (:bas.schouten) 2012-03-28 14:36:23 PDT
Hrm, I just ran accross this issue
Comment 3 Bas Schouten (:bas.schouten) 2012-03-28 14:36:58 PDT
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.
Comment 4 Enoch Lau 2012-05-20 08:06:52 PDT
This is still happening on Firefox 12 on the Mac (but not Windows): http://www.nointrigue.com/mapsapi/ff-canvas-mac.html
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?
Comment 5 Vladimir Vukicevic [:vlad] [:vladv] 2012-05-20 09:21:17 PDT
I only had Firefox 4 and 15 handy to test; definitely a regression though.
Comment 6 Alex Keybl [:akeybl] 2012-05-21 16:04:41 PDT
From the bug description, this is not a recent regression. No need to track for release.
Comment 7 Bas Schouten (:bas.schouten) 2012-05-22 20:11:01 PDT
Created attachment 626301 [details] [diff] [review]
Properly mark transform dealt with once a device space path builder is created

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.
Comment 8 Bas Schouten (:bas.schouten) 2012-05-22 20:26:56 PDT
Created attachment 626304 [details] [diff] [review]
Add a reftest for repeated drawing after changing transforms
Comment 9 Robert O'Callahan (:roc) (Exited; email my personal email if necessary) 2012-05-22 20:35:00 PDT
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.
Comment 10 Ed Morley [:emorley] 2012-05-24 11:01:58 PDT
https://hg.mozilla.org/mozilla-central/rev/ed6b4debfa1c
https://hg.mozilla.org/mozilla-central/rev/99db41088385

(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)
Comment 11 Enoch Lau 2012-05-24 21:12:58 PDT
Thanks for looking at this issue so quickly - much appreciated.

Note You need to log in before you can comment on or make changes to this bug.