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.