Re: smooth shading & terminal specialities

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

Ethan Merritt wrote:

>>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.
> 
> 
> But how does the higher level code tell a driver what to put in those
> 49x49 boxes?  In the general case each one has a different color, so
> I do not see how you end up saving anything.

I'm not completely following, and I think I'm still wondering about the terminal function mechanism.  Perhaps I'm used to thinking of C++ where one can override the function of a class and in some cases if base object in question doesn't have an overriding function, the function falls back to the base function.

The idea would be that for terminals which don't support term->image() there would be a base version of image_rhombus() (or some such thing) that draws an image using rhombuses and effectively acts the way pm3d currently does.

If there is image support, there is a big savings because the data is compact, i.e., a matrix of numbers as opposed to all the corners of each pixel, the rendering is better and faster at the driver or system call level, no aliasing issues, etc.

Dan