Re: smooth shading & terminal specialities

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

Mojca Miklavec wrote:
> Hello,
> 
> 
> In color.c I noticed the following code:
> 
>    if (gppsfile)
>     draw_inside_color_smooth_box_postscript(out);
>    else
>     draw_inside_color_smooth_box_bitmap(out);
> 
> 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). 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
>        ...

No.

> or is there a better (more consistent) solution?

Yes.  Your intuition is probably correct on this one.

My opinion is that this "gppsfile" variable should be eliminated.  From what I understand, the purpose of this is a flag in the main code that indicates a PostScript comment can be added to the file for later use.  This is for the purpose of later running an awk script to look for repeated postscript strings and redefine them as shorter strings for purposes of compression.

The goal is laudable, but oh how convoluted this is.  Not clean code.  Why not just write the PostScript version of these "draw one" routines with short definitions in the first place?  Plus, why would this have to be done at the core code level?  Also, why couldn't someone just gzip the file in question after the fact?  That will pretty much accomplish this "substitute long string with short string" approach.  (Files with greater repetition have better compression in general.)

It's OK, in my mind, to write routines in the C files that the "trm" files can "callback", and there certainly is some planning to do here.  For example, in the case of images, PostScript has a very nice feature in which images can have an angle in 3D space associated with them.  I didn't use that feature (not yet anyway).  Instead I wrote an image projection routine that constructs an image from little rhombus-es (rhombi?) for each pixel.  Now, that rhombus method should be the routine that the terminal driver falls back on if there is no whole image projection feature as in PostScript (i.e., the terminal driver can call a routine that happens to be in the src directory, no big deal).  I didn't know any language or library would have such a feature so didn't account for it originally, so a lack of foresight on my part.  That can be fixed easily, if developers decide to do so.

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

Think of how best to do this before embarking on it.  PostScript is the most feature rich language I'm aware of.  (The Adobe language reference should be consulted first.)

Are you saying you have a method that does shading in general?  Or just for PostScript?

> 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. 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. At which places in the source should
> (colud?) this be improved?

I agree.  Regarding the PostScript image projection, in fact, even the images with non-square parallelograms can be done efficiently with image data, so long as each element has four sides of the same size.  We just removed from the image routine a test to verify that every element is of the same size.  Such code could be used to check if the pm3d image would fit the bill.  (Yes, it will slow the code slightly, but as soon as it fails then things speed up again because the code would stop checking.)

That would mean that

* somewhere in the pm3d code would be this test to check if the pm3d drawing constitutes a flat 2D surface.

* if flat surface, call the "image" terminal routine having a new projection angle input

* For those terminals not supporting projected images, they can callback the routine that draws projected images with individual rhombus-es (or rhombi?)

I guess I've never completely understood the convention of "default routine" in the terminal driver concept.  Someone will have to explain this.  (I can think of two essentially the same, but slightly different approaches.)

Dan