On 01/15/2013 10:41 AM, Jordi Gutiérrez Hermoso wrote:
The gl2ps method for plotting with fltk is very slow for moderately
complicated plots. How can we fix this? Fix gl2ps or use a completely
new method?
Additionally, I didn't realise this until recently, but it appears
that this method also spawns multiple gs processes? Isn't this the
source of our race conditions with fltk?
- Jordi G. H.
The gl2ps method seemed simplest at the time, but was never expected
to work all that well. It is slow and requires the plot to be visible. And,
you could be right that it causes the known race conditions. It was worse,
but various patches have made it better. I do hope that some graphics
expert can spend time on this to find a better method.
I think that OpenGL is just not made to produce vector graphics. Last time I tried (a few years ago), Matlab was not producing real vector graphics when the OpenGL renderer is active: it was dumping a bitmap image wrapped into a PostScript. This is of course much faster to produce. However the OpenGL renderer is not active by default and only activated when required (3D, transparency...). Otherwise Matlab uses their own renderer that can produce PS natively.
I think OpenGL is overkill for usual 2D plotting. It has problems with rounding errors and overlapping things in the same Z-plane (maybe these can be worked around, but I don't have the OpenGL expertise to do it). That's why I suggested a while back to also implement a Cairo-based renderer that could be used for simpler 2D plots, where advanced visual effects are not a concern. I proposed it as a GSoC project last year, but it wasn't picked up. A Cairo-based renderer would produce 2D plots with higher quality than we currently have with OpenGL.
If we focus on 2D plots, it shouldn't be that complicated to implement. Many things are already present in the OpenGL renderer and can be re-used. It would require to re-engineer the opengl_renderer class and factorise the common parts into an abstract interface, inherited by any concrete renderer.
Note that it doesn't have to be Cairo-based. It could also be QPainter-based.
Also do not confuse backend/toolkit and renderer. The backend/toolkit provides the windowing system, while the renderer do the actual drawing on the graphics context provided by the toolkit. In theory, the same toolkit could use multiple renderers and I actually designed QtHandles that way (as well as JHandles), though it only support the OpenGL renderer at the moment.
Michael.