Re: smooth shading & terminal specialities

[Mojca M. <moj...@gm...>]

I'm sending a sample .ps file with gradient fill for the default palette.

I calculated the values at 11 equally spaced points and converted them
into hex numbers, now stored in /data. PostScript terminal currently
draws 1024 single-color rectangles. Does anyone notice any difference
in the palette produced by gradient fill and the one produced by 1024
samples? (I've read that sinus can be represented using 10 samples
with only 1% of mistake.) Well, the number of samples for making
gradient fill can be increased, but defining the color in 20 points is
still far less than drawing 1024 rectangles, not counting the
inefficiency and antialiasing artefacts that arise in the current
approach.

I don't know enough about PostScript language to be able to tell how
/data can be calculated in the PostScript file itself, but I'm almost
sure that it is possible. In any case gnuplot can calculate those 11
(or more) values if needed.

Could someone with some more inspect into PS terminal implement such
gradient fills for draw_inside_color_smooth_box_postscript(...)? I can
explain the details if needed.


On 5/8/06, Ethan Merritt (and others) 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...

Yes, native support for gradient fill.

> 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.

I'm attaching an example showing gradients in PS.

> 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.

Sure, but that doesn;t mean that it couldn't be rendered more
efficiently. (One would loose the ability to manualy change the
palette in the PostScript file afterwards (since gnuplot should
calculate the colors before drawing an image as opposed to the current
situation where PostScript calculates the proper color), but I don't
think that this would be a serious reason for not implementing better
rendering. How many people are manual editin PostScript code and how
many are suffering from GhostScript antialiasing "bug"?)

> Thus you mean to automagically change "with pm3d" into "with image" witho=
ut
> knowing it to user? That's not a good idea I think.

The user shouldn't notice any difference.

> OK.  How about PDF, does that have more features like gradient fill than =
does P.S.?

PS *does have* gradient fill.

> ...  Forgot to mention desires for compression in images that have come u=
p.
> (That really has no significance to recent discussion about terminal comm=
ands.)
> And also the colorbox can be done with an image.

I wanted to implement that behaviour in my driver (if maxcolors>0 use
image instead of gradient fill), but I would be glad if gnuplot would
be clever enough to take care about that.


> >>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.
>
> Mojca, could you explain a bit more about what you meant.  I think we're =
trying to guess here a bit too much.

OK. Let me try to explain, For drawing the "plotting area" in this
image (http://gnuplot.sourceforge.net/demo_4.1/pm3d.8.png), which is
nothing else but a bitmap image, gnuplot calls my terminal
    term->set_color(...)
    term->fillbox(...)
49 x 49 times. For bitmap teminal this doesn't really matter, but for
my terminal it means constructing 49x49 paths and fill each one of
them separately (bot at compile time of the image and when displaying
it in GhostView or Acrobat), not to mention aliasing-artefacts (I
don't know how they are called, but GhostView shows white stripes all
over the plot). This is extremely inefficient. It would be much better
if gnuplot would call a routine
    term->image(49,49, ....)
The result would be the visually the same (only better since no
artefacts would occur) and both compiling and rendering would be more
efficient. If the driver doesn't support "images", it can still draw
49 times 49 filled rectangles.

Mojca