Menu
▾
▴
gnuplot-beta
|
From: Christoph B. <us...@be...> - 2013-04-18 19:19:37
|
Hi, I am working on an _arc() terminal entry and during this some questions about possible design/features came up: 1. The main issue is about the clipping. In the current implementation, the circles are always clipped at the graph boundaries. * The clipping of the circles must be done inside each individual terminal implementation (works e.g. with Postscript, cairo-related terminals, SVG and others). * I would suggest, that the information, whether clipping is necessary, and to which rectangle it should be clipped is provided by a terminal-independent function. * Should the circle object support a [no]clip parameter, which can control the clipping at the graph border? In the current implementation the circle object is useless for marking something around the graph boundary (could just be a single dot on the border). This might also be implemented as a new value for 'set clip' and could also affect all other objects. As another thing I would suggest two distinct terminal entries _arc() and filledarc(). I'm looking forward to your comments and suggestions, Christoph |
|
From: Ethan A M. <sf...@us...> - 2013-04-18 20:46:34
|
On Thursday, April 18, 2013 12:06:59 pm Christoph Bersch wrote:
> Hi,
>
> I am working on an _arc() terminal entry and during this some questions
> about possible design/features came up:
>
> 1. The main issue is about the clipping. In the current implementation,
> the circles are always clipped at the graph boundaries.
Not quite correct.
The graphics code sets a current clip area and then calls
do_arc(), which clips to whatever area was set.
For circles the clip area is set to the graph boundaries if the center
is specified in plot ("first" or "second") coordinates or in graph
coordinates, but not if it is specified in screen coordinates.
> * The clipping of the circles must be done inside each individual
> terminal implementation (works e.g. with Postscript, cairo-related
> terminals, SVG and others).
> * I would suggest, that the information, whether clipping is necessary,
> and to which rectangle it should be clipped is provided by a
> terminal-independent function.
The current clipping area is maintained in the global structure
gadgets.h:extern BoundingBox *clip_area; /* Current clipping box */
If the clipping area is set to the entire canvas, then no clipping is
visible. Note that this is different from not doing clipping at all.
Some of the older terminals would segfault if lines were drawn off the
edge of the canvas, so clipping to the canvas boundary was important.
> * Should the circle object support a [no]clip parameter, which can
> control the clipping at the graph border?
So far I haven't seen a need for that, but maybe you have a new use
case that would want it.
> In the current implementation
> the circle object is useless for marking something around the graph
> boundary (could just be a single dot on the border).
Not really. You just have to specify the position in screen, rather
than plot, coordinates. You wouldn't normally specify the graph
boundary in plot coordinates anyhow so I don't see this as much of a
restriction. It is true that the most obvious way to position
something on the graph boundary is to use graph coordinates
set obj 1 at graph 0, graph 1
and currently the code in graphics.c would set the corresponding
clip area to the graph boundary. Perhaps it shouldn't? Or perhaps
that would be where your proposed clipping flag would come in?
> This might also be
> implemented as a new value for 'set clip' and could also affect all
> other objects.
The same clipping area and clipping primitives are used for all
objects. The clipping of filled curves is a partial exception,
since it gets very complicated to determine the correct clipping
for a filled curves whose vertices are off the edge of the canvas.
> As another thing I would suggest two distinct terminal entries _arc()
> and filledarc().
>
> I'm looking forward to your comments and suggestions,
I suggest that before investing a lot of time in this you first
dummy up a bit of terminal-specific output and compare it to the
result of the generic code in do_arc(). You might be surprised
at how much alike they look. I originally coded up a postscript
specific term->arc routine that used the PS Level 2 arc function.
But the result was not notably better than the generic function
so I abandoned the idea. That was before the cairo terminals
were added, however, so I didn't do the comparison for those.
Ethan
|
|
From: Christoph B. <us...@be...> - 2013-04-19 06:26:39
|
Am 18.04.2013 22:40, schrieb Ethan A Merritt: > On Thursday, April 18, 2013 12:06:59 pm Christoph Bersch wrote: >> >> * I would suggest, that the information, whether clipping is necessary, >> and to which rectangle it should be clipped is provided by a >> terminal-independent function. > > The current clipping area is maintained in the global structure > gadgets.h:extern BoundingBox *clip_area; /* Current clipping box */ Yes, I saw this, but didn't know if this information was supposed to be transparent to the terminal drivers. >> In the current implementation >> the circle object is useless for marking something around the graph >> boundary (could just be a single dot on the border). > > Not really. You just have to specify the position in screen, rather > than plot, coordinates. You wouldn't normally specify the graph > boundary in plot coordinates anyhow so I don't see this as much of a > restriction. It is true that the most obvious way to position > something on the graph boundary is to use graph coordinates > set obj 1 at graph 0, graph 1 > and currently the code in graphics.c would set the corresponding > clip area to the graph boundary. Perhaps it shouldn't? Or perhaps > that would be where your proposed clipping flag would come in? Yes, in my case it was something like: set xrange[0:10] set yrange[-1.2:1.2] set object circle at graph 0, first 1 radius 0.1 plot cos(x) And specifying this circle center with screen coordinates is somewhat fiddly. Also if one plots with circle >> This might also be >> implemented as a new value for 'set clip' and could also affect all >> other objects. > > The same clipping area and clipping primitives are used for all > objects. The clipping of filled curves is a partial exception, > since it gets very complicated to determine the correct clipping > for a filled curves whose vertices are off the edge of the canvas. > >> As another thing I would suggest two distinct terminal entries _arc() >> and filledarc(). >> >> I'm looking forward to your comments and suggestions, > > I suggest that before investing a lot of time in this you first > dummy up a bit of terminal-specific output and compare it to the > result of the generic code in do_arc(). You might be surprised > at how much alike they look. I originally coded up a postscript > specific term->arc routine that used the PS Level 2 arc function. > But the result was not notably better than the generic function > so I abandoned the idea. That was before the cairo terminals > were added, however, so I didn't do the comparison for those. I already have some code snippets for the cairo, Postscript and SVG terminals. You are right, there is hardly any difference, but I liked the idea of having an own terminal entries for graphic primitives like the circle :-) Thank you for you comments, Christoph |
|
From: Ethan A M. <sf...@us...> - 2013-04-19 18:56:56
|
On Thursday, April 18, 2013 11:26:31 pm Christoph Bersch wrote:
> Am 18.04.2013 22:40, schrieb Ethan A Merritt:
> > On Thursday, April 18, 2013 12:06:59 pm Christoph Bersch wrote:
> >>
> >> * I would suggest, that the information, whether clipping is necessary,
> >> and to which rectangle it should be clipped is provided by a
> >> terminal-independent function.
> >
> > The current clipping area is maintained in the global structure
> > gadgets.h:extern BoundingBox *clip_area; /* Current clipping box */
>
> Yes, I saw this, but didn't know if this information was supposed to be
> transparent to the terminal drivers.
The word "transparent" has unfortunately become ambiguous in
[American] English. I don't know whether you mean "supposed to be
easily inspected by terminal drivers" or "supposed to be invisible
to terminal drivers".
As it stands, the clip_area structure is only used by the higher level code.
No existing driver refers to it. I would say that if it becomes desirable
to pass explicit clipping information to a terminal driver, then a new
terminal entry point should be created for that purpose. But so far that
has not been necessary. I think it is preferable to have the core
code do the clipping so that the result is not terminal-dependent.
> Yes, in my case it was something like:
> set xrange[0:10]
> set yrange[-1.2:1.2]
> set object circle at graph 0, first 1 radius 0.1
> plot cos(x)
>
> And specifying this circle center with screen coordinates is somewhat
> fiddly.
I'm OK with the idea of adding a TBOOLEAN clip property for "set object".
Nevertheless I think that "plot ... with {circles|ellipses}" should
continue to always clip to the graph boundary, just as line or points
are always limited to the graph interior.
Ethan
|
|
From: Christoph B. <us...@be...> - 2013-04-24 19:52:45
|
Am 19.04.2013 20:56, schrieb Ethan A Merritt: > On Thursday, April 18, 2013 11:26:31 pm Christoph Bersch wrote: >> >> Yes, I saw this, but didn't know if this information was supposed to be >> transparent to the terminal drivers. > > The word "transparent" has unfortunately become ambiguous in > [American] English. I don't know whether you mean "supposed to be > easily inspected by terminal drivers" or "supposed to be invisible > to terminal drivers". I didn't know, if this information was supposed to be easily inspected by terminal drivers. > I think it is preferable to have the core > code do the clipping so that the result is not terminal-dependent. Yes, I agree, although additionally allowing terminal-dependent clipping would give better results in some cases (e.g. proper clipping of line ends). I just submitted a patch for improved polygon clipping in the core code to sf http://sourceforge.net/p/gnuplot/bugs/1237/ > > I'm OK with the idea of adding a TBOOLEAN clip property for "set object". I would like to see this. Another point related to clipping is different handling of the border of a clipped rectangles vs clipped polygon: reset set lmargin at screen 0.5 set xrange[0:2] set yrange[0:2.5] set macro obj_style = 'fillstyle empty border lc rgb ''red'' lw 5' set object rectangle from first -1,1 to 1,0.5 @obj_style set object polygon from first -1,1.5 to 1,1.5 to 1,2 to -1,2 @obj_style set object 2 @obj_style plot x Christoph |
