The Khronos Group - a non-profit industry consortium to develop, publish and promote open standard, royalty-free media authoring and acceleration standards for desktop and handheld devices, combined with conformance qualification programs for platform and device interoperability.

If this is your first visit, be sure to
check out the FAQ by clicking the
link above. You may have to register
before you can post: click the register link above to proceed. To start viewing messages,
select the forum that you want to visit from the selection below.

CPU Usage

I am working with IMX 35 board and I am drawing around 400 lines on it. What should be the range of CPU usage in the best and worst case scenario using an OPEN VG implementation. And are there any optimizations I can perform to reduce the same.

Re: CPU Usage

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
- anti-aliasing
etc.

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.