Re: smooth shading & terminal specialities

[Ethan M. <merritt@u.washington.edu>]

On Sunday 07 May 2006 07:53 pm, Mojca Miklavec wrote:
> I need my own version of drawing "smooth_box" (the terminal supports
> vector graphic format, so drawing a whole lot of rectangles of single
> color is extremely inefficient). 

I don't quite understand what you mean by that. 
How does a "vector graphic format" avoid having to draw filled
rectangles?  Do you mean there is native support for gradient fill?
In any case...

> Should I say 
> 
>     if (gppsfile)
> 	draw_inside_color_smooth_box_postscript(out);
>     else if(term->name == "my terminal")
>         MY_TERMINAL_draw_inside_color_smooth_box();
>     else
>         ...

Yes. 
The idea is that there is a generic routine draw_inside_color_smooth_box_bitmap
that can be used by any terminal.  However, some terminals may be able
to do the job more efficiently using some private routine. The only
driver to implement this so far is the postscript driver.  The test
"if (gppsfile)..." is a short way of testing for the driver; it might
be more proper to say
  if (!strcmp(term->name,"post") || !strcmp(term->name,"epslatex")
     || !strcmp(term->name,"pslatex") ....

> or is there a better (more consistent) solution? I hate touching the
> code outside my own (new) terminal, but in this case I probably can't
> avoid it.

There was some small amount of discussion on the list about creating
a new terminal entry point that would draw an area (triangle? rectangle?)
with a gradient fill.  The above calls would then become

   if (term->gradient_fill_box)
       term->gradient_fill_box(  some set of parameters  );

> draw_inside_color_smooth_box_postscript could be rewritten as well to
> produce smooth shading instead of 1000 single-color boxes (smooth
> liear shading with a stitching function). I know exactly what has to
> be done, but I would need some thinking to implement it properly. If
> someone knows PostScript language better than I do, I'm ready to
> describe the procedure more precisely. (A better and more efficient
> code can be produced using a new approach.)

That would be nice, particularly because the current PostScript
implementation triggers anti-aliasing artifacts on some versions
of ghostscript.  But are you sure there is a better way in
PostScript? I know this could be done in SVG, but I am unaware
of any way to do gradients in PostScript other than lots of little
single-color boxes.

> Many plot on http://gnuplot.sourceforge.net/demo_4.1/pm3d.html could
> be drawn more efficiently if I knew in advance that I'm able to draw
> an NxM image as opposed to drawing NxM rectangles. 

If you know that, you maybe should be using "plot with image" instead.

> Even the 4th and the 5th example could be simplified considerably,
> but the examples 6-12 are obvious examples of such inefficient graphic,
> which could be stored as a bitmap image.

You mis-understand the purpose of the demo.  It is not trying to
show an efficient way of plotting a rectangular image. It is simply
demonstrating different color schemes possible by changing the
palette definition.

> At which places in the source should  (colud?) this be improved?

If I understand correctly what you want, it was already implemented
by Dan Sebald and others as plot styles "with image" and
"with rgbimage".  But there is probably room for improving the
code. One recent request (# 1480115) is to add support for an
alpha channel.


-- 
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA