PLplot

Arjen Markus <arjen.markus@...> writes:

> Hello,
>
> Stefan Menzel reported a bug (plplot-Bugs-1973336) regarding plotting
> a single pixel. This is a special case in plpoin (where the value of
> the argument code is -1).
>
> The wingcc driver does not plot anything, whereas the GD driver does
> (at least for PNG).
>
> Given the implementation (as a line drawn from the point to itself)
> and the comment in the header that this may not work for smart enough
> drivers/devices, I wonder how we can solve this:
>
> - The wingcc driver has a separate function to draw a single pixel. We
> could change the driver to use that function to draw such a degenerate
> line. Then the effect would be limited to the wingcc driver, thus
> solving Stefan's immediate problem.  Each device for which this is an
> issue would have to be adapted.
>
> - We can change the plpoin() function or better: the underlying line
> drawing function grline() to to invoke the correct drawing function if
> the line is degenerate. This is (a lot?) more work, as currently the
> devices are not required to have a separate pixel drawing function
> (there is no provision in the dispatch table for this).
>
> Should we go for the first or the second solution?
>

In the new win driver, the line function looks for the degenerate case
where the start and end point are the same and uses the 


For example

  // If the beginning and end are the same
  if ( xpixb == xpixe && ypixb == ypixe ) {
    // Draw a pixel
    rc = SetPixel(dev->current_dc, xpixb, ypixb, dev->pen_color);
  } else {
    // Otherwise draw a line
    rc = MoveToEx(dev->current_dc, xpixb, ypixb,NULL);
    if(rc) rc = LineTo(dev->current_dc, xpixe, ypixe);
  }

There is a similar logic for X11 using XDrawPoint and XDrawLine.
I think this change should be made even if a single point drawing
function is implemented.

The plpoin does not draw a single pixel point per se.  The intent of the
function is to draw a point on the graph (which can multiple pixels).
Unless there is a reason to create an API call that draws a single
pixel, then I advocate we leave the dispatch table alone.

Jim Dishaw wrote:

>There is a similar logic for X11 using XDrawPoint and XDrawLine.
>I think this change should be made even if a single point drawing
>function is implemented.
>
>The plpoin does not draw a single pixel point per se.  The intent of the
>function is to draw a point on the graph (which can multiple pixels).
>Unless there is a reason to create an API call that draws a single
>pixel, then I advocate we leave the dispatch table alone.
>
>  
>
Well, that sounds fair enough to me - it is by far the simplest solution too
and it keeps the changes local. And using the new win driver could be a 
workaround
for the moment.

Regards,

Arjen

On Mon, Jun 02, 2008 at 01:51:42PM +0200, Arjen Markus wrote:
> Jim Dishaw wrote:
> 
> >There is a similar logic for X11 using XDrawPoint and XDrawLine.
> >I think this change should be made even if a single point drawing
> >function is implemented.
> >
> >The plpoin does not draw a single pixel point per se.  The intent of the
> >function is to draw a point on the graph (which can multiple pixels).
> >Unless there is a reason to create an API call that draws a single
> >pixel, then I advocate we leave the dispatch table alone.
> >
> >  
> >
> Well, that sounds fair enough to me - it is by far the simplest solution too
> and it keeps the changes local. And using the new win driver could be a 
> workaround
> for the moment.
> 
> Regards,
> 
> Arjen

Perhaps we should do an audit of the other common drivers to check if
any others suffer from this problem. A quick modification to one of the
examples might do the trick. 

Andrew

>
>
> Perhaps we should do an audit of the other common drivers to check if
> any others suffer from this problem. A quick modification to one of the
> examples might do the trick.
>
> Andrew
>

This sounds like a good plan to me. In the mean time I have
adapted the wingcc driver to draw a pixel instead of a line if the
line's end points coincide.

I used example x22 for testing this new feature - a bunch of zero-length
vectors should be very recognisable. Only it took me a while before
I realised that the plvec() function optimises these away ;).

That raises the question whether plvec() should indeed suppress
zero-length vectors: they convey information too! Any thoughts?

Regards,

Arjen

Hi Arjen,

> This sounds like a good plan to me. In the mean time I have
> adapted the wingcc driver to draw a pixel instead of a line if the
> line's end points coincide.
> 
> I used example x22 for testing this new feature - a bunch of zero-length
> vectors should be very recognisable. Only it took me a while before
> I realised that the plvec() function optimises these away ;).
> 
> That raises the question whether plvec() should indeed suppress
> zero-length vectors: they convey information too! Any thoughts?

In Mathematics I would say if the start and end point of a vector are 
the same one obtains a Null vector which is just not visible, so I think 
plvec() is correct in not plotting them. The problem is, that in vector 
oriented graphics there is nothing like a pixel, if I'm not wrong. 
Therefore it's also not a good idea to have a separate pixel
drawing function in the dispatch table, since this is something vector 
oriented drivers can't do (e.g. wxGraphicsContext based on cairo can't 
do that).

So we would need to investigate why some drivers plot a point (png) 
while others don't (wingcc).

Regards,
Werner