Re: Peculiarities in demo plots

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

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