Canvas issue when drawing arc lines
Categories
(Core :: Graphics: Canvas2D, defect)
Tracking
()
People
(Reporter: robdayse, Assigned: lsalzman)
References
(Regression)
Details
(Keywords: regression)
Attachments
(11 files)
|
544 bytes,
text/html
|
Details | |
|
54.98 KB,
image/png
|
Details | |
|
71.49 KB,
image/png
|
Details | |
|
142.20 KB,
image/png
|
Details | |
|
63.72 KB,
image/png
|
Details | |
|
58.50 KB,
text/plain
|
Details | |
|
41.66 KB,
text/plain
|
Details | |
|
260.14 KB,
image/png
|
Details | |
|
263.76 KB,
image/png
|
Details | |
|
261.96 KB,
image/png
|
Details | |
|
48 bytes,
text/x-phabricator-request
|
Details | Review |
Chrome-working.png
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:109.0) Gecko/20100101 Firefox/115.0
Steps to reproduce:
Go to:
https://www.w3schools.com/jsref/tryit.asp?filename=tryhtml5_canvas_arc
and use the code:
<!DOCTYPE html>
<html>
<body>
<h1>HTML5 Canvas</h1>
<h2>The arc() Method</h2>
<canvas id="myCanvas" width="600" height="600" style="border:1px solid grey"></canvas>
<script>
const c = document.getElementById("myCanvas");
const ctx = c.getContext("2d");
ctx.translate(250, 250);
ctx.beginPath();
ctx.arc(-190, 0, 200, 0, 1.5707963267948966);
ctx.stroke();
ctx.beginPath();
ctx.arc(-200, 0, 200, 0, 1.5707963267948966);
ctx.stroke();
ctx.beginPath();
ctx.arc(-210, 0, 200, 0, 1.5707963267948966);
ctx.stroke();
</script>
</body>
</html>
Or see the attached file
Actual results:
line: ctx.arc(-200, 0, 200, 0, 1.5707963267948966); was not rendered correctly
line: ctx.arc(-200.01, 0, 200, 0, 1.5707963267948966); does render correctly
Expected results:
The top of the line should end between the other two.
Seems like when the x co-ordinate is exactly the negative value of the radius, the line doesn't draw.
|
||
Updated•11 months ago
|
|
||
Comment 1•11 months ago
|
||
I am getting the same output on Nightly and Chrome.
Can you :
- Attach a screenshot of what you see on your machine
- Attach the content of about:support to this bug
- Open about:config, set "gfx.canvas.accelerated = False", restart Firefox and then retry the testcase.
Thanks.
Hi,
Sure. I can reproduce on two machines on two completely different versions of Linux also. Here is the above information in the order I collected it.
Question 1. - I am unable to reproduce on the latest Chrome (Sorry for having to do that) (Chrome-working.png)
- I am able to reproduce on this version of Firefox (115.0.2) (Firefox-notWorking.png)
Question 3. - I set gfx.canvas.accelerated to false (gfx-canvas-accelerated-false1.png)
- I tested again (gfx-canvas-accelerated-false2.png)
Question 2. I have attached the required text File
Hope this helps.
--
Rob Day
It it helps also, here are the screen shot of the Real Life Machine/Operating system, Firefox version and code which led me to finding the bug.
I was creating a racing track builder for a game I like to play in JavaScript (Still in early development). bug-tb.png shows the issue
highlight.png highlights the bug
bug-tb2.png shows how the track piece renders correctly on a different part of the canvas
This bug was then reproduced on my Linux Mint clean testing environment as per the previous screen shots.
--
Rob Day
|
Reporter | |
Comment 10•11 months ago
|
||
|
|
||
Comment 11•11 months ago
|
||
Regressed by :
Bug 691187 - Prune zero-length segments for canvas strokes. r=lsalzman
Differential Revision: https://phabricator.services.mozilla.com/D179462
Fixed by :
Bug 1839470 - Pass arcs through to the PathBuilder. r=lsalzman
Differential Revision: https://phabricator.services.mozilla.com/D181542
@Rob Day : Thanks for the detailed info. This bug is fixed on the latest Firefox Nightly. This should be part of an upcoming release (dont know the exact version but either V116 or V117).
|
|
Reporter | |
Comment 12•11 months ago
|
||
|
|
Reporter | |
Comment 13•11 months ago
|
||
|
|
||
Comment 14•11 months ago
|
||
Hi Lee,
Can you change the status of this bug and track it for an appropriate release.
Thanks!
|
||
Comment 15•11 months ago
|
||
Set release status flags based on info from the regressing bug 691187
|
|
||
Comment 16•11 months ago
|
||
[Tracking Requested - why for this release]: Canvas issue when drawing arc lines in 115esr
I can reproduce this on 115 and 115esr. but I cannot reproduce on 116RC and 117a1.
Regression window:
https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=d414a9ced12fcb3e84853fed4d4ed94b4339ef23&tochange=e6e098584f0a9dce25653b8b5edd930231ebf6b3
Regressed by Bug 691187.
Fixed by Bug 1839470 on 116 and later.
|
|
||
Updated•11 months ago
|
|
|
Reporter | |
Comment 17•11 months ago
|
||
Hi
Awesome stuff! Thanks for the help!
--
Rob Day
|
Assignee | |
Comment 18•11 months ago
|
||
The Canvas2D specification says that if a path has no active sub-paths, and a
primitive is drawn, that the first point of that primitive becomes the start of
the newly created sub-path that will be created for it.
So if we prune a point when a path has no active sub-paths, and then a new
primitive comes in that does not start with that same point, we risk not
installing the pruned point as the start of that new sub-path.
To solve this, we need to detect if a path has no active sub-paths while
we are building it. This adds PathBuilder::IsActive() to help with that.
Then before we go to add a primitive, we check if there is a pruned point
on a path that is not active yet, and if so, install the correct start
point with a MoveTo.
This also makes IsActive and IsEmpty required so to ensure all our path
implementations behave consistently rather than having any surprising
unimplemented behavior.
|
||
Updated•11 months ago
|
|
|
Assignee | |
Comment 19•11 months ago
|
||
Bug 1839470 does not actually fix it at all. It just covers up the underlying bug. This patch should really fix it.
|
||
Comment 20•11 months ago
|
||
Pushed by lsalzman@mozilla.com: https://hg.mozilla.org/integration/autoland/rev/1a460d5ffdaa Ensure pruned point begins first sub-path if necessary. r=aosmond
|
||
Updated•11 months ago
|
|
||
Comment 21•11 months ago
|
||
| bugherder | ||
|
||
Updated•11 months ago
|
|
||
Comment 22•11 months ago
|
||
I was able to reproduce the issue on Ubuntu 20.04 using FF build 115.0.2
Verified as fixed on Ubuntu 20.04/Win10x64/Mac 12.6 using FF builds 117.0b2(20230801180159) and 118.0a1(20230803094549).
|
|
Assignee | |
Comment 23•11 months ago
|
||
Comment on attachment 9346391 [details]
Bug 1846079 - Ensure pruned point begins first sub-path if necessary. r?aosmond
Beta/Release Uplift Approval Request
- User impact if declined: Canvas2D fails to render paths properly under some use-cases. This behavior was a bug unfortunately introduced in 115 by 691187.
- Is this code covered by automated tests?: Yes
- Has the fix been verified in Nightly?: Yes
- Needs manual test from QE?: No
- If yes, steps to reproduce:
- List of other uplifts needed: None
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky):
- String changes made/needed:
- Is Android affected?: Yes
ESR Uplift Approval Request
- If this is not a sec:{high,crit} bug, please state case for ESR consideration:
- User impact if declined:
- Fix Landed on Version: 117
- Risk to taking this patch: Low
- Why is the change risky/not risky? (and alternatives if risky):
|
||
Comment 24•11 months ago
|
||
:lsalzman this is already in beta(fx117). Did you mean to nominate this for a 116 dot release?
|
|
Assignee | |
Comment 25•11 months ago
|
||
On reflection, it looks like this patch can't actually be uplifted without a few other tagalongs, so I am going to address this for 115 in a different way, rather than uplift this bug.
|
|
Assignee | |
Updated•11 months ago
|
|
|
||
Comment 26•11 months ago
|
||
Fixed for 115.2esr by reverting the regressing change.
Description
•