I don’t know the amount.
I do know it will probably depend greatly on a whole bunch of factors including:
- line width
- join styles
- cap styles (especially if dashing is enabled)
- number of line intersections
- number of segments inside the path(s)
- blending modes
In general, to speed things up:
- once you set path data to a path, try to never change the data. Use matrix transformations whenever possible instead.
- turn the blending to SRC instead of SRC_OVR (default) if you’re not using any alpha.
- turning off anti-aliasing may help (at the cost of visual quality)
- turn off cap styles to BUTT and join styles to BEVEL (though some implementations might be faster with ROUND - experiment)
- thinner lines cover less pixels == faster.
- Do not submit massive paths for drawing (e.g. 400 line segments in a single path). The more segments there are in a path, the more complicated the intersection tests are which prevent overdraw. These intersection tests are done by the driver but can be quite expensive. It’s sometimes better to submit 40 paths containing 10 segments each than 1 path containing 400 segments (especially for stroke paths).
- in general solid color is faster than linear color is faster than radial color. Texturing falls somewhere in between depending on hardware.
- don’t draw lines which to not appear on the screen. It still needs processing.
- Lines are faster than Quads, Quads faster than Cubics.
- Check to see if your path data simplifies any. Input geometry is, more often than not, sub-optimal.