If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

Canvas behaves poorly with some transformations

VERIFIED WORKSFORME

Status

()

Core
Canvas: 2D
P2
major
VERIFIED WORKSFORME
11 years ago
6 years ago

People

(Reporter: Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com], Unassigned)

Tracking

Trunk
x86
All
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

Created attachment 266311 [details]
testcase

This non-reduced testcase eventually results in Firefox (2.0.0.3) / SeaMonkey (Gecko 1.8.1.2pre) eating up huge amounts of memory.  I suspect the cause is the ctx.scale() and/or ctx.translate() which are done repeatedly with no ctx.restore() between iterations.  Uncommenting ctx.restore() on line 158 makes the issue go away.

<biesi> your wormhole2 thing basically made X unusable
<biesi> I killed seamonkey from a console
<Hendikins> CTho: I had to do the same on here.

Steps to reproduce:
1. Open the testcase, let it run for a while (I'm guessing the scale/translate have to accumulate).

A reduced testcase might be as simple as one or two ridiculously large scale/translate calls with some drawing.
Component: General → Layout: Canvas
Still occurs on trunk on Mac.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows XP → All
Priority: -- → P2
Version: 1.8 Branch → Trunk
QA Contact: general → layout.canvas
There's nothing in the current canvas code that would cause eating of additional memory on lots of subsequent transforms as far as I can see.

I also cannot reproduce this issue in Nightly or Release. -> WFM

Please re-open if somebody is still seeing this.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Works for me on 7.0 on Windows and 6.0.1 on Linux.  Marking verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.