Re: smooth shading & terminal specialities

[Daniel J S. <dan...@ie...>]

Ethan Merritt wrote:
> On Sunday 07 May 2006 07:53 pm, Mojca Miklavec wrote:
>>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") ....

Really?  I thought we're supposed to keep terminal-specific code out of the core and override terminal functions.


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

Well, doing it as an image, one would think that the viewer driver knows to do proper anti-aliasing.  (Recall PostScript isn't bitmap based... only in its last rendering does it do 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.

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

Oh yeah, I forgot all about that.  (Whoever oversees that may assign that request to me, user "sebald".  I can't seem to do that without having created it.)  Am I right that the alpha would be a depth of four, one of the channels being 0/nonzero?  So maybe the syntax should be something like "with rgbaimage", or "with argbimage"?  Or is there some trick where one of the rgb colors becomes a opaque?

Dan