octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Fixing fltk printing


From: Konstantinos Poulios
Subject: Re: Fixing fltk printing
Date: Wed, 23 Jan 2013 11:16:48 +0100

I am not so negative about gl2ps myself. It is also used by GMSH and
ParaView and my impression is that it is quite reliable there. Of
course it is a bit overkill to use gl2ps for 2D, but normally 2D plots
will not cause as much performance issues as 3D plots.

One may consider using off-screen mesa in order to overcome the
display server requirement and limitations:
http://www.mesa3d.org/osmesa.html
Maybe osmesa could even be compiled with double-precision support but
I have no idea if performance of osmesa (even without doubles) is
acceptable.

Concerning the slow performance of printing with fltk+gl2ps are we
sure that gl2ps is the bottleneck?

Concerning the race condition, I have the impression that the
remaining issue is more fltk related than a problem with gs processes:
https://mailman.cae.wisc.edu/pipermail/octave-maintainers/2012-June/028580.html

In general I agree that fixing/improving printing in Octave, with or
without gl2ps, is an important aspect.

Kostas

On Fri, Jan 18, 2013 at 7:57 PM, Michael Goffioul
<address@hidden> wrote:
> On Fri, Jan 18, 2013 at 1:38 PM, Jordi Gutiérrez Hermoso
> <address@hidden> wrote:
>>
>> On 15 January 2013 11:47, Michael Goffioul <address@hidden>
>> wrote:
>> > I think that OpenGL is just not made to produce vector graphics.
>>
>> Is your proposal to completely drop gl2ps, then?
>
>
> Once we have a valid alternate solution, we may have indeed to re-assess the
> usefulness of using gl2ps instead of simply dumping a bitmap image. But
> we're not there yet.
>
>>
>> I'm excited about the
>> possibility of doing it with cairo, if it really is as flexible and
>> feasible as you say it is.
>
>
> I don't have much time at the moment and I'm already busy with the classdef
> stuff. So it may take a while before I give that a shot.
>
> Michael.
>


reply via email to

[Prev in Thread] Current Thread [Next in Thread]