Open Bug 787679 Opened 12 years ago Updated 2 years ago

Poor canvas performance

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Version:
15 Branch
Platform:
x86_64
Windows 7
Type:
defect

Tracking

()

People

(Reporter: sfornengo, Unassigned)

Details

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:15.0) Gecko/20100101 Firefox/15.0 Build ID: 20120825192204 Steps to reproduce: I am drawing to canvas Actual results: execution is very slow and lagging, more than 10 times slower than in other browsers. Expected results: it should be smooth as in others browsers. see this test: http://jsfiddle.net/7dxDu/1/ under ubuntu 12.10/64 bits: Description de la carteNVIDIA Corporation -- GeForce GT 430/PCIe/SSE2ID du vendeurNVIDIA CorporationID du périphériqueGeForce GT 430/PCIe/SSE2Version du pilote4.2.0 NVIDIA 295.40Rendu WebGLNVIDIA Corporation -- GeForce GT 430/PCIe/SSE2 -- 4.2.0 NVIDIA 295.40Fenêtres avec accélération graphique0AzureBackendskia firefox 15 results: 3.180s for the "ctx.beginPath(); ctx.closePath();" loop 5.350s for the "ctx.stroke();" loop chromium 18 results: 0.351s for the "ctx.beginPath(); ctx.closePath();" loop 0.235s for the "ctx.stroke();" loop under windows seven it's even worse: Description de la carteIntel(R) HD GraphicsID du vendeur0x8086ID du périphérique0x0046RAM de la carteUnknownPilotes de la carteigdumd64 igd10umd64 igdumdx32 igd10umd32Version du pilote8.15.10.2372Date du pilote4-15-2011Description de la carte (GPU #2)NVIDIA GeForce GT 520M ID du vendeur (GPU #2)0x10deID du périphérique (GPU #2)0x1050RAM de la carte (GPU #2)1024Pilote de la carte (GPU #2)nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2umVersion du pilote (GPU #2)8.17.12.6800Date du pilote (GPU #2)3-31-2011Direct2D activétrueDirectWrite activétrue (6.1.7601.17789)Paramètres ClearTypeParamètres ClearType introuvablesRendu WebGLGoogle Inc. -- ANGLE (Intel(R) HD Graphics) -- OpenGL ES 2.0 (ANGLE 1.0.0.1041)Fenêtres avec accélération graphique1/1 Direct3D 10AzureBackenddirect2d firefox 14 results: 16.379s for the "ctx.beginPath(); ctx.closePath();" loop 32.459s for the "ctx.stroke();" loop chromium 23 results: 0.378s for the "ctx.beginPath(); ctx.closePath();" loop 0.305s for the "ctx.stroke();" loop
Component: Untriaged → Canvas: 2D
Product: Firefox → Core
Bug 561361 is for Linux, this is for Windows. Looks like Direct2D is enabled. Can you test with a nightly build of Firefox?
OS: Linux → Windows 7
In addition you should update your Nvidia drivers on Win 7, I have almost the same GPU (GeForce GT 550M instead of 520M) and there are new drivers. It's important for better rendering with hardware acceleration enabled.
Nvidia drivers updated, no change.
(In reply to sfornengo from comment #3) > Nvidia drivers updated, no change. What are the results with a Nightly build?
test under nighty build of firefox: linux firefox 18.a1 results: 3.484s for the "ctx.beginPath(); ctx.closePath();" loop 4.191s for the "ctx.stroke();" loop windows seven firefox 18.a1 results: 10.587s for the "ctx.beginPath(); ctx.closePath();" loop 29.103s for the "ctx.stroke();" loop always the same order of magnitude about speed...
Status: UNCONFIRMED → NEW
Ever confirmed: true
Can you put the testcase that actually draws triangles in here, please? Thanks.
here a more real testcase drawing triangles: http://jsfiddle.net/7dxDu/8/ under firefox the canvas dragging is lagging with only 200 triangles in the draw() loop... under chromium the same lagging comes with more than 100000 triangles !
Could be really slow D2D performance on small strokes...
I wrote a more simple testcase: http://jsfiddle.net/7dxDu/9/ firefox: test1: 0.403s test2: 1.711s test3: 3.752s chromium: test1: 0.003s test2: 0.005s test3: 0.008s we can notice that firefox don't scale linearly as we could expect... doubling from 1000 to 2000 the number of triangles take 4 times longer to render ! chromium is blazingly fast as compared and scale linearly as expected.
please, see this testcase: (adjust var n=3000 if test is too slow on your machine)... http://jsfiddle.net/7dxDu/11/ this is really weird and incomprehensible, putting the ctx.beginPath() and ctx.stroke() inside the for loop is 10 times FASTER ! so the firefox problem seems to be on accumulating a path before stroking.
(In reply to sfornengo from comment #10) > please, see this testcase: (adjust var n=3000 if test is too slow on your > machine)... > http://jsfiddle.net/7dxDu/11/ > this is really weird and incomprehensible, putting the ctx.beginPath() and > ctx.stroke() inside the for loop is 10 times FASTER ! > so the firefox problem seems to be on accumulating a path before stroking. That's what the canvas spec requires. After all, you might change the strokeStyle at any time before the final stroke() call.
I suspect this is entirely a graphics backend issue. Any backend that implements stroking by generating a path representing the stroke and then filling it, and doesn't do something sophisticated to handle repeated path segments, is likely to spend a lot of time doing intersection finding on the overlapping path segments. OTOH we know Skia draws narrow lines using some more direct approach that can probably avoid finding intersections and thus scale linearly with the number of line segments.
Component: Canvas: 2D → Graphics
In my real application I just want to draw a mesh of 250 different triangles, using narrow lines with the same strokeStyle, without filling or clipping region. just a simple loop over an array of triangles looking for a maximum performance. I expect just a direct approach, why spending time finding intersections in this case ? Anyway generating a ctx.beginPath() and ctx.stroke() for each triangles in the loop is 10 times faster than only one stroke() for the total path, but still executes 10 times slower under firefox than under chromium...
It seems that from firefox version 11 performance is more than 10 times lower than in previous versions of firefox: http://jsperf.com/batching-line-drawing-calls
I patiently tested performance of canvas line drawing of versions of firefox that parade but it is getting worse and worse since firefox 11... http://jsperf.com/batching-line-drawing-calls Before firefox 11 everything was ok but today we can say that it has reached a point where it is unusable for a non trivial application... this is a serious regression, from near 79 ops/s in firefox 10 to 4 ops/s in firefox 16 and then 3 ops/s in firefox 18...
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.