Re: Peculiarities in demo plots

[sfeam <sf...@us...>]

On Saturday, 16 May 2015 11:43:48 PM Daniel J Sebald wrote:
> On 04/20/2015 02:00 AM, Daniel J Sebald wrote:
> 
> > In other words, the QGraphicsItem class might be similar to the failsafe
> > mode of x11, as far as its operation is concerned--I'm assuming failsafe
> > is where an image is created by drawing squares on the canvas.
> >
> > For that example, if I turn on failsafe mode, i.e.,
> >
> > plot $DATA with image failsafe
> >
> > that example with "NaN should appear as background" and "Negative values
> > become NaN with a log-scale color mapping" looks similar in x11 and Qt
> > terminals. In fact, shrinking down the image I can see in both cases
> > that "NaN should appear as background" is actually in front of the
> > pixmap while "Negative values become NaN with a log-scale color mapping".
> >
> > I'm fine with the demo, but now that I understand it I don't see the
> > terminal type as being highly responsible for the feature. (Partial
> > transparency is a different issue. That's something more significant.
> > Could probably do alpha-blending in X11, but I don't think anyone wants
> > to tackle that.) The "failsafe" option is somewhat vague. Given what I
> > suspect about the image being actually drawn with individual rectangles
> > (something that "image" defaults to when cast into a 3D
> > non-perpendicular view), it might have been nicer to force this mode
> > with a different type, say "pixmap" as opposed to "image".
> 
> Has anyone put more thought into this failsafe option?  I don't think it 
> is urgent to change, but I do think in the long run the failsafe option 
> would be better as its own plot type, e.g., pixmap.  It's more 
> distinctive that way. 

I may be overly influenced by knowing what's underneath the hood,
but I don't see it that way.  The original failsafe option was purely
an internal accommodation for terminals that didn't support 
term->image().  The core code for drawing images could test for whether
the terminal had dedicated support, and if not it could fall back to 
the failsafe mode.   It turned out that for certain purposes it
was useful to force that same pixel-by-pixel mode on demand even for
terminals that do support term->image().  For instance svg applies
color-smoothing to images, so if you want a clean heatmap it is better
to use "with image pixels".

   http://gnuplot.sourceforge.net/demo_svg_5.0/heatmaps.html

The NaN business is just a distraction.  It is nice to have some
well-defined behaviour in the presence of NaN, but that depends
on what is possible to support in each terminal's term->image() 
code.  The failsafe code is terminal-independent, so it is easier
to be consistent.   But this is was never driving creation of
the failsafe/fallback/pixels mode, and indeed was only added
later.

	Ethan

> In other words, pixmap and image would have the 
> same underlying construction but the difference would be that "pixmap" 
> is assured to be pixel-based in the sense that NAN can remove the 
> pixels.  "image" would only be pixel based in the case there is no 
> support for images (2D/3D) in the terminal.  The point is to attempt to 
> use more efficient image capabilities when possible with "image".
> 
> Making failsafe (i.e., pixmap) a type would also mean an additional 
> option variable isn't needed.  Also, more significantly, if hidden 
> surfaces ever arise there is a big distinction between treating an image 
> as pixels and as a whole image.  Individual pixels treated as simple 
> polygons falls naturally into the hidden surface routine, whereas a 
> whole image doesn't.  Depth order would be the only thing for obscuring 
> the hidden portion of a whole image.
> 
> Dan