gnuplot-beta

Re: palette allocation during mouse rotation

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

Here's a patch for that gnuplot "allocating colors..." redraw problem with rotation.  The princple is as follows:

On the _terminal driver side_ of the pipe is the following test:

/* Only send the palette if it is different from the last palette,
 * one hasn't been sent yet, or if the plot number is different from
 * the plot number the last time the palette was set.
 */

If one thinks through the logic for that, you'll find it avoids flaky behavior on part of the palette, even in multiplot mode.

That keeps gplt_x11.c from having to reconstruct the color tables unless necessary.  The refresh speedup is clearly back to what it once was.

I would add that another part of this equation is that the gnuplot core doesn't need to send the palette so often.  If it followed the formula that it only send the palette when the _terminal_ changes or the palette commands are entered, it would reduce more wasted CPU.  (If some devices need a copy of the palette for every plot, the driver should keep a copy internally.)  Don't want to get into that, however.  (Note the rule would change if developers went the path of the core used plots as objects, Hans' desire.)

[Petr, I added a couple helper functions.  Could you have a look at the following functions and see if you agree everything is copied and/or deleted properly?

/* create on the heap, a copy of a palette */
duplicate_palette(t_sm_palette *p)
/* remove a palette from the heap */
destroy_palette(t_sm_palette *p)
udft_del(udft_entry *p_del)
udft_cpy(udft_entry *dest, udft_entry *src)

They are right next to palettes_differ().  The part that confuses me is how the Afunc, Bfunc, Cfunc are used.  They appear to be linked list elements, but the list pointers don't appear to be assigned anywhere, and I don't understand why (if they are linked-list elements) they would be tacked into a structure somewhere.  So they must be ignored.

/* user-defined function table entry */
typedef struct udft_entry {
    struct udft_entry *next_udf; /* pointer to next udf in linked list */
    char *udf_name;		/* name of this function entry */
    struct at_type *at;		/* pointer to action table to execute */
    char *definition;		/* definition of function as typed */
    t_value dummy_values[MAX_NUM_VAR]; /* current value of dummy variables */
} udft_entry;

I attempted to get the at_type and definition copy right, but it sure gets deep.  I stopped at temp_at().

I didn't use gp_alloc(), but instead malloc() because there was only malloc()s in getcolors.c.

If you know of any functions that already exist that are similar to what I created, let me know.

I copied your original bug report that started the palette stuff so that you may verify your example still works.]

...

OK, so that's one problem down and two to go.  I'll see if I can get to another one next weekend.

Dan


Petr Mikulik wrote:
>     Hello,
> 
> I think the palette should not be touched, only the "set view" numbers. 
> I think it was Johannes who programmed this rotation by mouse without 
> rereading the data.
> 
>   Petr
> 
>> Haven't thought about this, but just want to remind you the rule is to 
>> allocate the palette only if it changes.  Could it be that something 
>> about the palette is being changed on the plot you are generating?  If 
>> so, it isn't a bug as programmed, but we may want to come up with a 
>> scheme of tagging the color map somehow because we are going back and 
>> forth two different ones.  (I actually would prefer such an approach 
>> because testing the whole palette each time a redraw is done to check 
>> for a change is inefficient.)
>>
>>>
>>> From: Petr Mikulik <mi...@ph...>
>>> Date: 2005/11/27 Sun PM 12:04:34 EST
>>> To: Daniel J Sebald <dan...@ie...>
>>> Subject: palette allocation during mouse rotation
>>>
>>>      Hello Daniel,
>>>
>>> I have just tried to type
>>>
>>>      splot x with line palette
>>> or
>>>      set pm3d
>>>      splot x
>>>
>>> and then rotated the plot by mouse. Now, the title bar shows that 
>>> gnuplot is
>>> allocating the color palette all the time. I think it was not the case
>>> before your last patch. Could you please have a look to this issue?
>>>
>>> Thanks, Petr
> 
> 

There is a bug in the color palette treatment in the X11 terminal: when
using multiple X11 terminals, window redraw (requested e.g. by a window
manager) will change its palette.

Try this script:


set pm3d map

set term x11 10
set title '10 gray levels'
set palette gray
set palette maxcolors 10
splot x*x

set term x11 2
set title '2 colors'
set palette color
set palette maxcolors 2
splot x


Now, maximize or resize window #10 by mouse => it will change from gray map
with 10 gray levels to color map with 2 colors.

Is it possible to fix it?

---
PM

Re: palette allocation during mouse rotation

[Petr M. <mi...@ph...>]

> Here's a patch for that gnuplot "allocating colors..." redraw problem with 
> rotation.  The princple is as follows:

It looks OK. I passed "pm3dcolors.dem" on it (with "set pm3d map" => "set 
pm3d"), rotated by mouse, it's no more reallocating colors and no strange 
thing happened.

BTW, I prefer to surround unused code by #if 0 #endif instead of /**  */; 
it's more readable.

> OK, so that's one problem down and two to go.  I'll see if I can get to 
> another one next weekend.

Please resend the patch when it's final for cvs.

---
PM

Re: palette allocation during mouse rotation

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

I have a bit of free time to wrap up the patch to stop the constant palette refresh with X11 mouse activity.  Just one detail and I wanted to get developers opinions.

As part of a palette comparison a copy of the previous palette is stored.  Part of that is copying a udft_entry.  Right now it is only a partial copy of udft_entry as the color routines don't use all parts of the udft_entry in the test.

I'm just wondering which of these alternatives are preferred:

1) Leave this code inside getcolor.c as an incomplete copy and call the routines:

  udft_partial_cpy()
  udft_partial_del()

2) Make the routines a complete copy and delete keeping track of details for temp_at, perm_at, free_at and move them to somewhere like eval.h/eval.c so that they might find some future use somewhere else.

Basically, do you want a

udft_cpy()
udft_del()

?

Dan

Re: palette allocation during mouse rotation

[<br...@ph...>]

Daniel J Sebald wrote:
> As part of a palette comparison a copy of the previous palette is 
> stored.  Part of that is copying a udft_entry.  Right now it is only a 
> partial copy of udft_entry as the color routines don't use all parts of 
> the udft_entry in the test.

No.  Don't even think of it.

If you need a copy of a data structure, you make a copy, period.  Copies 
that aren't copies are a nightmare we absolutely don't need.

Re: palette allocation during mouse rotation

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

OK, I've made a fix for the palette allocation problem and placed it on the SourceForge patch page (1448674).  This should make us all happier.

For reference, the original email was of Jan 7, 2006.  Basically, Petr could apply this at any time, but I left it on the patch page for Hans and Ethan to take a run through.  I made a complete "copy_at()" in eval.c patterned after "free_at()".  Using free_at() as a model should mean no memory is assigned by copy_at() that won't be deleted by free_at().  So, take a look at that.

Also, in getcolor.c are a couple routines

copy_udft()
clear_udft()

Although they are conceptually similar to copy_at() and free_at(), I figured they really aren't as portable so avoided bloating things too much.  (Note copy_udft() and clear_udft() only get included in the core gnuplot routine, not gplt_x11.)

Dan


Petr Mikulik wrote:
>> Here's a patch for that gnuplot "allocating colors..." redraw problem 
>> with rotation.  The princple is as follows:
> 
> 
> It looks OK. I passed "pm3dcolors.dem" on it (with "set pm3d map" => 
> "set pm3d"), rotated by mouse, it's no more reallocating colors and no 
> strange thing happened.
> 
> BTW, I prefer to surround unused code by #if 0 #endif instead of /**  
> */; it's more readable.
> 
>> OK, so that's one problem down and two to go.  I'll see if I can get 
>> to another one next weekend.
> 
> 
> Please resend the patch when it's final for cvs.
> 

Re: palette allocation during mouse rotation

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

Juergen Wieferink wrote:
> Am Montag, 13. M=E4rz 2006 08:36 schrieb Daniel J Sebald:
>=20
>>OK, I've made a fix for the palette allocation problem and placed it on=
 the
>>SourceForge patch page (1448674).  This should make us all happier.
>>
>>For reference, the original email was of Jan 7, 2006.  Basically, Petr
>>could apply this at any time, but I left it on the patch page for Hans =
and
>>Ethan to take a run through.  I made a complete "copy_at()" in eval.c
>>patterned after "free_at()".  Using free_at() as a model should mean no
>>memory is assigned by copy_at() that won't be deleted by free_at().  So=
,
>>take a look at that.
>=20
>=20
> I've curiously taken a look into your copy_at() because IIRC
> free_at() was written by me. :-)
>=20
> I do see a minor problem with your code:
>=20
> eval.c (copy_at):
>=20
> +	    if ( a->index =3D=3D PUSHC || a->index =3D=3D DOLLARS ) {
> +                if ((a->arg.v_arg.type =3D=3D STRING)
> +			&& a->arg.v_arg.v.string_val
> +			&& (b->arg.v_arg.v.string_val
> +			    =3D (char *) gp_alloc(strlen(a->arg.v_arg.v.string_val)+1, "cop=
ied=20
> v_arg")))
> +		    strcpy(b->arg.v_arg.v.string_val, a->arg.v_arg.v.string_val);
> +		else
> +		    b->arg.v_arg.v.string_val =3D NULL;
> +            }
>=20
> If the current action "a" pushes an integer or real value (quite
> common), this code seems to init ...string_val to NULL.  But
> "string_val" is the char* member of a *union*, resetting the numeric
> value to be pushed.  AFAICS, you should omit the "else" part.
>=20
> I haven't compiled or tested your implementation, and probably it
> won't harm for your specific usage of copy_at().

You are right.  It is a union, which I knew, but I just wasn't thinking s=
traight.  I will fix that and update the patch.

Thanks Juergen,

Dan

Re: palette allocation during mouse rotation

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

Hans-Bernhard Br=F6ker wrote:
> Daniel J Sebald wrote:
>=20
>> As part of a palette comparison a copy of the previous palette is=20
>> stored.  Part of that is copying a udft_entry.  Right now it is only a=
=20
>> partial copy of udft_entry as the color routines don't use all parts=20
>> of the udft_entry in the test.
>=20
>=20
> No.  Don't even think of it.
>=20
> If you need a copy of a data structure, you make a copy, period.  Copie=
s=20
> that aren't copies are a nightmare we absolutely don't need.

OK.  Full copy it is.

Dan

gnuplot, wxterminal and antialiasing

[<tim...@en...>]

Hi !

I've had the pleasure to see the first comment of H.B. Broeker on the
behaviour of the wxWidgets/Cairo terminal. Definitely, this comment raise=
s
an interesting question (at least it interests me).

Here is the comment :

   One thing jumped at me almost immediately: the anti-aliased
   line drawing seems not work out all that well.  Two main
   issues there are:

   1) the usual "plot x" line at default settings is
   terribly
   wobbly.  Yes, the windows terminal does that, too.  But with
   anti-aliasing it looks even worse, somehow.

   2) the diagonal line of 'plot x' looks considerably
   fatter than the key sample.

   Both effects appear even more striking in

       set polar
       set size ratio -1
       plot 2.23

   So: may I be so bold as to ask for a terminal switch that
   turns anti-aliasing off?  Maybe it's only my LCD screen
   that's acting up here, but frankly, I don't think
   anti-aliasing is doing gnuplot all that much good.  At least
   here on my screen it seems to make typical aliasing
   artefacts (like the wobble on both the diagonal line and the
   circle) stand out even more, instead of working against them.


I am well aware of the problem, and I have several ideas about it. This
problem comes from the terminal API, which works with integers everywhere.
That's why 'plot x', on all platforms, looks wobbly to some extent instea=
d
of being a straight diagonal.

Please take a look at this screeshot http://tipote.free.fr/compare.png
I have done this screenshot to compare the different available interactiv=
e
terminals regarding the wobbling effect. You will see :

- Top Left : the wxterminal I am working on, in its current state.
It features antialiasing and its side-effects as H.B.B noted them :
wobbling more visible than in other terminals because our eyes are no mor=
e
disturbed by the aliasing, and key sample thinner because it is drawn
exactly on the centers of the pixels so it doesn't use/need any
antialiasing.

- Bottom Left : the Windows terminal, through Wine.
Here, aliased lines, definitely wobbling too.

- Bottom Right : the X11 terminal.
Basically the same rendering as the Windows terminal (apart from the fat
box), with aliased lines (and fonts) and wobbling.

- Top right : a modified wxterminal, which cheats by saying to gnuplot
that it has 10000 times more pixels than it really has. This oversampling
allows to use the Cairo API at its full extent, as it is based on doubles
instead on integers (motivated by the so-called subpixel accuracy of the
antialiasing method). This way, the diagonal of 'plot x' is purely
straight and clean ! Drawbacks : some ticks, the key samples and more
generally all horizontal or vertical lines are no longer placed on intege=
r
coordonates, so they are blurred by the antialiasing algorithm.

To see the same terminals render the polar 'plot 2.23' example quoted by
H.B.B., see here http://tipote.free.fr/compare2.png


As for me, I prefer the rendering with the modified oversampling
wxterminal because it gets rid of the annoying aliased and wobbling lines.
However, it definitely blurs all the lines of the box, of the ticks and o=
f
the key.

What do you think of it ?

Should there be an option in the wxterminal to choose between :
   noantialiasing,
   antialiasing,
   antialiasing+oversampling
?

On the long run, a solution could be to rewrite or complete the term API
in terms of double instead of integers, but still use integers for the
box/ticks/key. Do you think it's feasible ?

Thank you for your help and you rinterest in the wxWidgets terminal !

Timoth=E9e

Re: gnuplot, wxterminal and antialiasing

[Ethan M. <merritt@u.washington.edu>]

On Friday 10 March 2006 03:10 pm, Timoth=E9e Lecomte wrote:

> This problem comes from the terminal API, which works with integers
> everywhere. That's why 'plot x', on all platforms, looks wobbly to
> some extent instead of being a straight diagonal.

I was able to mitigate this problem dramatically for the svg termimal
simply by increasing the driver's internal scale by a factor of 10.
Screen coordinates are still integers, but the resolution is 10x better,
and the wobble is essentially eliminated.

> Please take a look at this screeshot

Here are a pair of screenshots, before and after increasing the
svg internal scale by a factor of 10.

http://www.bmsc.washington.edu/people/merritt/gnuplot/scale_1.png
http://www.bmsc.washington.edu/people/merritt/gnuplot/scale_10.png

> As for me, I prefer the rendering with the modified oversampling
> wxterminal because it gets rid of the annoying aliased and wobbling
> lines.

Does it affect the speed?=20
I'm already concerned that the wxterminal is slow compared to x11.


=2D-=20
Ethan A Merritt
Biomolecular Structure Center
University of Washington, Seattle WA

Re: gnuplot, wxterminal and antialiasing

[<tim...@en...>]

> On Friday 10 March 2006 03:10 pm, Timoth=E9e Lecomte wrote:
>
>> This problem comes from the terminal API, which works with integers
>> everywhere. That's why 'plot x', on all platforms, looks wobbly to
>> some extent instead of being a straight diagonal.
>
> I was able to mitigate this problem dramatically for the svg termimal
> simply by increasing the driver's internal scale by a factor of 10.
> Screen coordinates are still integers, but the resolution is 10x better=
,
> and the wobble is essentially eliminated.
>
>> Please take a look at this screeshot
>
> Here are a pair of screenshots, before and after increasing the
> svg internal scale by a factor of 10.
>
> http://www.bmsc.washington.edu/people/merritt/gnuplot/scale_1.png
> http://www.bmsc.washington.edu/people/merritt/gnuplot/scale_10.png

Ok, so this is the same method as what I called "oversampling". The only
difference is that I used a higher scale factor, 10000.

>> As for me, I prefer the rendering with the modified oversampling
>> wxterminal because it gets rid of the annoying aliased and wobbling
>> lines.
>
> Does it affect the speed?
> I'm already concerned that the wxterminal is slow compared to x11.

I see exaclty the same speed as without "oversampling", that is to say it
is still much slower than x11, but not worse than without oversampling.

Regarding the speed of the wxWidgets/Cairo rendering, there may be severa=
l
bottlenecks :
- first, my code is surely not optimised (a lot of mutex lock, etc.),
- then Cairo itself is still young so the upcoming 1.2 version may contai=
n
speed improvements,
- and finally I can use a backend drawing with Glitz, so that Cairo will
use  OpenGL and profit from the gpu acceleration

I sincerely think that the first point is the most pertinent, because eve=
n
if I disable antialiasing, the speed does not improve much...
However, in theory, the antialiasing makes the rendering slower, that's s=
ure.

Best regards,

Timoth=E9e