Trying to optimize graphic display in my plugin.
I have a bunch of almost vertical 1 pixel width bars, stucked together, same colour.
fillRectList is very fast on CoreGraphics. But using it in a OpenGL grahic context is dramatically slow - even the Software Renderer is faster.
It looks the cluster is cut into thousands of quad-vertex (sorry no GL Expert) via the EdgeTable?, but in a very inefficient way.
Is there a way to draw these Rectangles, straightforward, without this weird EdgeTable- Transformation, directly as gl-quads, like it is done in the CoreGraphics renderer?
Yes, that’s true. The renderer will always use horizontal lines which can result in thousands of vertices. Still, OpenGL should have no problem rendering thousands of vertices - however, calculating the edge table can take some time. A few tips:
as the boundaries of the edge tables are calculated on the CPU, turning on compiler optimizations will really speed this up
can you somehow cache the graphics to an image? JUCE’s opengl renderer is very fast at drawing images.
No, its definitely not fast enough for my purpose. And it wastes the whole potential of OpenGL.
I already use rendering on a background thread (isolated from the message thread). I think there is an enormous potential for optimizing which should be used.
(Especially drawing Waveforms!)
If i render the same lines horizontally -> its 100x faster, i think it should be not to complicated to modify the renderer that at least plain colored rectangles or horizontal lines will be rendered with less vertices. Especially this is important for people which using openGL for android, which still using pure CPU rendering.
BTW: Jules already mentioned rectangle rendering: “which is optimised to use a minimal number of triangles”, but it seems not true (maybe its just a bug/unintended?)
Just spoke to Jules and he re-iterated what he wrote in that post. It should not being going down the EdgeTable path if your rects have integer coordinates and there is no clip-region. Can you step through the code (or provide simple code for us to reproduce) and see why the slow path is being taken?