Canvas updates lost: canvas layered over SVG




Layout: View Rendering
6 years ago
6 years ago


(Reporter: Stephen Bannasch, Unassigned)


Firefox Tracking Flags

(Not tracked)



(1 attachment)



6 years ago
User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_6_8) AppleWebKit/534.51.22 (KHTML, like Gecko) Version/5.1.1 Safari/534.51.22

Steps to reproduce:

Load this page:

Click the "go" button.

Source code here:

Actual results:

Model runs, canvas object layered on top of SVG graph, when gctx.stroke() completing the first line segment is executed the canvas rendering disappears. The red border on the canvas object is still visible and checking the dom shows the canvas object is still layered layered over the SVG content.

The canvas is visible until this statement is executed:

The canvas is created like this:

Expected results:

While the model is running a dynamic line graph should be updating in the graph canvas.

While it is true that the canvas object is layered over SVG content I have not made a simple test case to determine if this is indeed the cause of the bug.

The dynamic graphing while the model is running works fine in Chrome and Safari.

Comment 1

6 years ago
Created attachment 568575 [details]
a simple demonstration of an important aspect of the bug

Comment 2

6 years ago
You can also view the bug here:

Comment 3

6 years ago
This problem also occurs on Windows 7 using: FireFox 7.0.1 and IE v9.0.8112.16421
Component: General → Layout: View Rendering
Product: Firefox → Core
QA Contact: general → layout.view-rendering

Comment 4

6 years ago
This problem does not occur in Safari or Chrome on Mac OS X or Windows 7.

It also does not occur on iPads, iPhones or Android tablets.
Attachment #568575 - Attachment mime type: text/plain → text/html

Comment 5

6 years ago
A comment about why this is important to me (and perhaps others).

Using SVG to create interactive visualizations is a good match because it is graphically rich and it is easy to attach behavior to the SVG dom elements.

However using SVG to display moderately fast real-time data streams slows down considerably when the number of segments in the active visualization gets large (>5000).

Here are two simple benchmark that show that drawing a line consisting of 5000 separate segments is almost 40x slower in SVG than in Canvas:

  SVG Path Benchmark:
  Canvas Path Benchmark:

The line is rendered as 5000 separate and sequential updates because that tests the kind of update that would happen graphing a real-time data stream.

In order to get the best of both SVG and Canvas uses both techniques in the grapher.

I use the D3.js visualization framework ( which works well with SVG and when I am graphing a real-time data stream I overlay the D3.js graph with a Canvas object.

When plotting real-time data I move this canvas object above the SVG content and plot lines there until the data-collection stops. When stopped I move the canvas object behind the D3 SVG graph and draw the completed data set once with D3.

This hybrid approach works quite well and could become a common patten for this kind of application.

Comment 6

6 years ago
So far I have been unsuccessful making a simple version that shows the behavior where lines that are drawn do not appear.

FYI: here is my current attempt at revising the demo of the bug to include more elements of the app itself:
Referring to the "a simple demonstration of an important aspect of the bug" attachment, is this not the expected behaviour when drawing into a canvas with globalCompositeOperation = "destination-atop" ? I think destination-atop might not be supported well in webkit, which explains why Firefox would match IE on this testcase.

Comment 8

6 years ago
Thanks Timothy for looking at this issue.

I think you are correct.

I have updated the original application and the problem is gone on FF 7.0.1 and IE9.

Here are the changes that fixed the problem:

In addition the speed of running the model, visualization and graph has sped up 6x in FF -- from 385 to 2291 model-steps/s.

Now FF is only 4x slower than Chrome.

|_. Mac OS X 10.6.8 [2]               |_\2>. ave rate (model-steps/s) for 5000 steps |
|_. Browser                           |_=.                  |_=.  graph/canvas off   |
| Chrome 14.0.835.186                 |=.      9578         |=.          12594       |
| Safari v5.1.1 (6534.51.22)          |=.      3576         |=.           4840       |
| FireFox 7.0.1                       |=.      2291         |=.           3191       |

See readme here for more benchmarks:

Let me know whether it would be useful/helpful for me to create a performance issue with these current results.
Yes, please create a bug for Firefox being slower on this. Let me know which bug or cc me on it.

I'll mark this bug as invalid then if there are no further issues, you can reopen if there is something left here besides the performance issue.
Last Resolved: 6 years ago
Resolution: --- → INVALID

Comment 10

6 years ago
performance bug created here:
You need to log in before you can comment on or make changes to this bug.