Re: graphics future (was: Re: color_radio_property implementation)

[Shai Ayal]

On 4/26/07, Michael Goffioul <address@hidden> wrote:
> The other main possibilities are octplot, yapso and oplot-gl (my code; maybe
> less advanced at user-level, but I think I have a solid more advanced
> core base).
> Deciding on the way to go is unfortunately a never-ending debate. OTOH, these
> 3 solutions are all based on OpenGL. So, beside the fact they use different
> languages or toolkit, the core of the problem, which is rendering, can
> be largely
> shared: maybe not at code-level, but at least at idea-level. For instance, the
> way I setup the view transformation in order to fit the window can be re-used
> in octplot or yapso. Or I could also re-use the octplot's algorithm to compute
> nice autoscale in my java code (there's none at the moment). Moreover, the
> complete user-level m-code part can probably be shared. In this context, even
> having 3 backends doesn't seem such a waste of resources.
BTW, I am very not happy with OpenGL. I chose it for octplot so that
in the future 3D capabilities could be added, but for 2D plots it's
really nothing to write home about.
line beveling is awful, it does all computations in floats, not
doubles which limits it's accuracy in drawing and I had to implement
layering by doing mock-3D -- all objects have a z-coordinate which is
assigned according to their order in the axes.children list. I have no
idea how this will integrate with 3D objects. Also, while gl2ps is
very nice, the postscript output is not very professional looking,
again with line beveling problems.

Does anyone know of an alternative 3D library?

If I had to do 2D graphics only, I would go with libcairo -- it looks
great, and has magnificent screen, postscript, pdf and bitmap outputs
which all match each other.