1748592 - Using mousewheel in scichart.com demo is slow compared to Chrome

Status: NEW

(Core :: Graphics: CanvasWebGL, defect)

Description

[Kelsey Gilbert [:jgilbert]]

(from https://bugzilla.mozilla.org/show_bug.cgi?id=1602299#c40)

Hi all,

We're also experiencing this problem of getImageData / drawImage performance. Here is a demo to reproduce
https://demo.scichart.com/javascript-multi-pane-stock-charts

Try using the mouse wheel in this chart demo on Firefox vs. Chrome. The performance difference is HUGE!

What we're doing. We have one WebGL canvas which we draw to, and we use getImageData() / drawImage() to read back pixels from webgl and write into HTML5 canvas. This gets around the limitation of number of webgl canvases per browser.

The only workaround we have is to render directly to WebGL canvas but that limits the # of charts we can have on a screen.

Performance difference is massive between Firefox & Chrome. So much so we're recommending to our users they must use chrome.

Any help appreciated. Can also supply further info if requested.

(In reply to Lee Salzman [:lsalzman] from comment #41)

getImageData() should never be used where high performance is expected due to the cost of reading back pixels from an accelerated context. This, in principle, defeats most attempts at acceleration because you are forcing the GPU and CPU to synchronize to read back the pixel data and then trying to re-upload it to a GPU context again forces the synchronization back in the other direction.

True, but it performs perfectly well on Google chrome just nor Firefox

Do you have another suggestion for WebGL canvas sharing (e.g. one master WebGL canvas, multiple target canvases on page)? The only one I can think of is a single shared WebGL context and getImageData() / createImage

Comment 1

[Kelsey Gilbert [:jgilbert]]

Firefox lets you have 300 webgl contexts per principal (webgl.max-contexts-per-principal) and 1000 total before we context-lost the least-recently-used context.
Does that make things easier for you?

Comment 2

[aburnettthompson]

Hi there,

I may be wrong but as far as I'm aware the number of WebGL contexts varies from browser to browser, machine & hardware. We expect a minimum of 2 and max of 16 contexts allowable on a webpage.

Is it possible to query the number of webgl contexts in JavaScript? As we need to make multi-browser software & applications we could take advantage of Firefox's increased number of WebGL contexts but only if we can accurately determine the number of free contexts.

Comment 3

[Kelsey Gilbert [:jgilbert]]

It's always 300 and 1000 in Firefox these days. We of course can't expose to websites the exact number of used or free contexts they can expect, given other things going on in the browser.

We're (Firefox) betting that you will always have enough for anything reasonable, so our advice for use with Firefox is "just try it". :)

Chrome also shouldn't have a restrictive limit here. If they do have a low one, I'm not sure why! They virtualize contexts, so there's only one "real" GL context per page for them anyway. (Whereas in Firefox, each WebGL context is a different real GL context)

Comment 4

[Kenneth Russell]

Chrome does have a very low limit. For historical purposes, this was made configurable in this Chromium bug: https://crbug.com/771792 . It's 8 per domain on Android, 16 per domain on desktop, and 4 per dedicated worker. These low limits helped Chrome pass some of the more stressful WebGL tests which allocate a lot of contexts and make the associated canvases very large.

Submitter, you don't need to do getImageData() - that's the problem. Just drawImage() the WebGL-rendered canvas to your 2D canvas. If you do this, does it improve performance on Firefox by avoiding CPU readbacks?

Comment 5

[Kelsey Gilbert [:jgilbert]]

There is no avoiding readback from WebGL in Firefox here.
However, you should indeed probably use drawImage, certainly not both getImageData and drawImage together.
But in Firefox, you should just use more webgl contexts. That's the fastest thing you can do.

Comment 6

[aburnettthompson]

Thank for the info everyone, very helpful.

Can confirm Chrome, Edge, Safari (Mac) have 16 WebGL contexts whereas Firefox has 300.

However, this is a hard coded-variable which may change in future, and afaik no reliable way to detect number of free contexts left. So we have to be cautious with this approach.

Still it's good to know we can consume far more contexts. Instantiating WebGL canvases for each sub-chart improves performance in our demo marginally.