Closed Bug 499628 Opened 11 years ago Closed 9 years ago

Potential canvas bug with strokeText() and clip()

Categories

(Core :: Canvas: 2D, defect, minor)

x86
macOS
defect
Not set
minor

Tracking

()

RESOLVED FIXED
mozilla2.0b8

People

(Reporter: dion, Assigned: bzbarsky)

References

Details

Attachments

(1 file)

While implementing a canvas animation we started to see that the clipping region was being drawn when using strokeText.

The attached test case shows just this. At first you will just see the text, and quickly after you will see the clipping region box drawn. It happens as soon as a second call to re-paint the area happens.

This doesn't happen if you change the stroke to a fill. E.g.

change: 
ctx.strokeStyle = "white";
ctx.strokeText(message, x, y);

to:
ctx.fillStyle = "red";
ctx.fillText(message, x, y);
Component: General → Layout: Canvas
Product: Firefox → Core
QA Contact: general → layout.canvas
Version: 3.5 Branch → unspecified
A simple work around was adding a ctx.beginPath(); before the strokeStyle call (thanks Vlad).

Still could be a bug.... WebKit doesn't require this for example, but maybe it is their bug :)
Problems with Firefox 3.5+, 4b.
(OK with Chrome.)

After a strokeText() the stokeStyle used to render the text will be also used by the last displayed shape built with a beginPath.

1/ ctx.strokeStyle = "white";
2/ ctx.strokeText ("test",x,y);
3/ ctx.strokeStyle = "green";
4/ ctx.beginPath() ... ctx.arc (...) .... ctx.endPath(); ctx.stroke(); // circle 1 => ok green
5/ ctx.strokeStyle = "blue";
6/ ctx.beginPath() ... ctx.arc (...) .... ctx.endPath(); ctx.stroke(); // circle 2 => nok white

I can add a more complete example if needed.
A first workaround is to display an empty circle (size 0) at the end of the rendering or to display the text only at the end. It's not clean at all.

Regards

Matthias
In fact the problem occurs even if strokeText() is called at the end but the sequence
beginPath -> stokeText -> endPath works.

Affects firefox 4.0b6 (Snow Leopard)
Duplicate of this bug: 608633
> A simple work around was adding a ctx.beginPath(); before the
> strokeStyle call (thanks Vlad).

> Still could be a bug.... WebKit doesn't require this for example, but maybe it
> is their bug :)</blockquote>

It is a bug. See the Canvas spec at
http://www.whatwg.org/specs/web-apps/current-work/multipage/the-canvas-element.html#text-0
, it says:
> Text is painted without affecting the current path, and is subject
> to shadow effects, global alpha, the clipping region, and global composition
> operators.

So calling beginPath, etc shoudl not affect text operations at all.
Just adding that this bug was also encountered on Windows 7 and Windows XP and is not limited to Mac OS X. I also believe it's importance should be escalated to normal, because it will break lots of applications using Canvas, possibly making them unusable. If applications using Canvas where more common already I'd even think about escalating it further, but for now I believe it should be on normal.
Depends on: 478445
Fixed by checkin for bug 478445.
Assignee: nobody → bzbarsky
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Backed out the patch for being in the range of bug 615736
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [need landing]
Whiteboard: [need landing]
Status: REOPENED → RESOLVED
Closed: 9 years ago9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b8
You need to log in before you can comment on or make changes to this bug.