Re: fltk printing

[Shai Ayal]

2010/7/20 Jordi Gutiérrez Hermoso <address@hidden>:
> On 20 July 2010 13:57, Shai Ayal <address@hidden> wrote:
>> On Tue, Jul 20, 2010 at 9:52 PM, bpabbott <address@hidden> wrote:
>>> On 20 Jul, 2010,at 02:00 PM, Michael D Godfrey <address@hidden>
>>> wrote:
>>> Are you thinking of producing all output from an eps file?
>>> (1) PS by embedding the EPS file in a single page PS file
>>> (2) PDF from PS (or from EPS depending upon what is desired).
>>> (3) Using GS to convert to the various bitmaps?
>>> I like the idea.
>
> I don't, if I understand what you guys are plotting (haha, geddit?).
>
> No, really, is the idea to produce an eps first for any kind of plot
> and then convert that to other formats?
>
> Try this:
>
>     backend("fltk");
>     x = linspace(0,2*pi,100);
>     [xx,yy] = meshgrid(x,x);
>     surf(xx,yy, sin(xx.*yy));
>     tic, print foo.eps, toc
>
> On my system, I got: "Elapsed time is 17.4619 seconds" and it eats CPU
> for that time. The resulting EPS is about 18 megs. I also tried it
> with "shading interp" before the print call, and it was taking an even
> longer amount of time, and my machine froze completely, forcing a hard
> reset. :-(
>
> Now, you may argue that the great number of plot elements here are to
> blame. I say it's not excessive for a surface. I get the feeling that
> most of the work has focussed more on 2d plotting for publication,
> which is why the idea of using eps for everything sounds reasonable,
> but I often want to get pngs even if they're not of the best quality.
>
> Indeed, one of the reasons I personally would like to move away from
> gnuplot is that a surface of this detail is unusuable on gnuplot (just
> rotating it eats CPU as well) while OpenGL doesn't even bat an eyelash
> at it.
>
> Can we do this instead?
>
>     http://www.opengl.org/resources/faq/technical/miscellaneous.htm#misc0050
>
> It would incur some image library dependencies, but I don't think it's
> unreasonable, as those libraries are probably needed anyways for
> gnuplot or the widely used image 'Forge package. I'm working right now
> on the things related to the recent 3d rotation patches, but I'd be
> quite happy to write patches to plot images this way.
>

This approach has the drawback that the image produced is exactly
pixel-per-pixel as the image on screen (since you are copying the
screen pixels to your buffer). That means it depends on the plot
window size (and your screen size). If you are willing to live with
this, than you'll indeed have a very fast bitmap image.

Shai