gnuplot-beta — Developers and beta testers of new gnuplot code

Re: Windows EMF

[Hans-Bernhard B. <br...@ph...>]

On Mon, 21 Jun 2004, Stephane Barbaray wrote:

> Made again some new modification on emf.trm, the file is available now
> on sourceforge (Patches section), here is a part of the history relating
> the change :

Stephane, do I take this new patch submission to mean that you consider
your earlier patch to be out of date by now, and only the newer one should
be used?

[Hint: you could have submitted a new patch file into your old patch 
tracker entry instead...]

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Windows EMF

[Stephane B. <gn...@co...>]

BBands wrote:

>>Well I'm wondering if they really tested it, because
>>there is only 2 or=20
>>3 EMR (EMF structs/records) causing troubles...
>>so maybe a fix for the hotfix soon? :-[
>>   =20
>>
>
>I suspect it is a case of not invented here, they
>simply can't be bothered if their software didn't
>create it.
>
>In any case I am back if you need any testing, etc...
> =20
>

Hello again,

Made again some new modification on emf.trm, the file is available now
on sourceforge (Patches section), here is a part of the history relating
the change :

1.0.9 03-Jun-2004 Stephane Barbaray <ste...@co...>,
Ethan Merritt <merritt@u.washington.edu>
- fixed linewidth bug
- all is now really assumed as 1024x768@96dpi,
   before it was a mix between 1600x1200@120dpi and 1024x768@96dpi,
   so font may now render differently than before...
- pointsize rework (size twice also now)
- HCHAR and VCHAR are more efficiently computed

So in the gnuplot's test you should see the right linewidth, and a
better centered text in the box but it will never be perfectly centered
since I can't compute the width of a font, it's just an approximation
according to font height...
Still no implementation for pattern and polygon filling...

--=20
St=E9phane BARBARAY.

Re: Time to branch off 4.0 from 4.1?

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

> > then "show variables" should have define all
> > usual mousing variables, obviously with zero values, and the MOUSE_KEY
> > should be set to -1:
>
> I do not like this idea at all. zero is a legal coordinate value, so
> setting coordinates to zero is not a safe way of indicating an abnormal
> return.

I didn't mean MOUSE_X, but MOUSE_KEY -- that's the indication what has
happened during "pause mouse".

From the programming point of view, what a driving program has to write to
gnuplot in either case -- an Octave example:

A. "close" sets MOUSE_X, .. to e.g. 0, and MOUSE_KEY to -1:

graw('\nprint MOUSE_X, MOUSE_Y, MOUSE_KEY;');
...read them from fifo...
if (mouse_key >= 0) ...

B. "close" does not define anything:

graw('\nif (defined(MOUSE_KEY)) print MOUSE_X, MOUSE_Y, MOUSE_KEY; else
print "0 0 -1"\n');
...read them from fifo...
if (mouse_key >= 0) ...

Note that "\n..." is necessary as one character gets eaten during close.


In summary: I would like more to have MOUSE_KEY defined always, and being
positive for mouse and key events, and being negative for a "fatal" case of
no such event.


> I suggest that the proper fix is to modify your scripts to test for the
> existence of the variable before trying to print it.

The above-mentioned script works, just "it does not look so nice" with the
additional "if ; else 0 0 -1".


BTW, one bug:

gnuplot> plot x
gnuplot> pause mouse key
 ..hit q
gnuplot> pause mouse key
 ..now must press Ctrl-C
gnuplot> pause mouse key
    warning: Mousing not active
                     ^
         expecting string

gnuplot> pause mouse
         warning: Mousing not active


It should report the "Mousing not active", or rather "Interactive terminal
window is closed", even in the 1st trail; that Ctrl-C is fatal for driving
apps.



> > Finally, what do you think about this: "q" hotkey is disabled when
> > "pause mouse key" comes to action;
>
> I have been unable to figure out how to do this.
> The "q" hotkey is handled directly by gnuplot_x11, which doesn't know
> anything about "pause mouse".

Thus, a special string must be sent to the interactive terminal at the
beginning, and another one at the end.

Actually, it will be the same thing as switching on/off mouse-related menu
items in the PM terminal, when mouse gets disabled in gnuplot. See
mouse.c: builtin_toggle_mouse()
...
# ifdef OS2
    update_menu_items_PM_terminal();
# endif
...


/* update menu items in PM terminal */
void
update_menu_items_PM_terminal(void)
{
    send_gpPMmenu(PM_pipe);
}


=> and send_gpPMmenu does:

    putc('#', PM_pipe);
    fwrite(&gpPMmenu, sizeof(gpPMmenu), 1, PM_pipe);

Great hack, but works as user expects.


> I think it would take a separate communication channel and a new set of
> driver calls to implement this, since gnuplot would have to inform
> gnuplot_x11 asynchronously that it is requested to change how it is
> handling X11 input events. Frankly, I think it would be a huge headache to
> get this working.

That's why my previous idea to change "set_cursor" api to "set_interactive"
to pass exactly such events, instead of those e.g.  SET_SPECIAL events sent
by some .trm.


> The only alternative I have been able to come up with is to
> move the "q" processing for the current plot window out of gnuplot_x11
> altogether, and make it equivalent to
>    bind 'q' '<some command related to set term x11 close>'
> If you have any better ideas, please speak up.

But "q" is traditional as it closes -persisten gnuplot_x11 too.

> > thus, command.c should call
> > "x11_hotkeys(0)" and afterwards "x11_hotkeys(1)" to enable them again.
> x11_hotkeys()?   Is this a new driver primitive that you have designed?
> I agree it would be possible to do this sort of thing by adding a new set
> of driver primitives.  But that's a big job and I don't have time to tackle it.

To be reused set_cursor. Ok, then it can wait for cvs branch splitting.

---
Petr

Re: Time to branch off 4.0 from 4.1?

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

On Friday 18 June 2004 06:09 am, you wrote:
>
> If user closes gnuplot_x11, 

If a user kills gnuplot_x11 then all bets are off.  Killing it (SIGTERM etc)
will bypass any code that I add.  So I assume you mean:
if a user closes the plot window...

> then "show variables" should have define all 
> usual mousing variables, obviously with zero values, and the MOUSE_KEY
> should be set to -1:

I do not like this idea at all.
zero is a legal coordinate value, so setting coordinates to zero is not a safe way
of indicating an abnormal return.

> This is absolutely important in order not to break scripts for
> bidirectional communication of other programs with gnuplo, which get
> feedback from mousing by writing the above MOUSE_* values to pipe /
> fifo.

But a script should not assume that any of these variables are defined. 
In fact they are not defined to begin with, and only become defined
at the time a mouse click is first requested and successfully recognized.
I suggest that the proper fix is to modify your scripts to test for the
existence of the variable before trying to print it.

This is simply a specific example of the more general case of 
user-defined variables.  Scripts are free to define and use variables
via gnuplot, but they cannot assume the variables are defined. Or else
they must be very careful to insure that a variable becomes defined
before trying to use it, but that strikes me as a dangerous programming
style.

> Finally, what do you think about this: "q" hotkey is disabled when
> "pause mouse key" comes to action;

I have been unable to figure out how to do this.
The "q" hotkey is handled directly by gnuplot_x11, which doesn't know
anything about "pause mouse".   I think it would take a separate
communication channel and a new set of driver calls to implement 
this, since gnuplot would have to inform gnuplot_x11 asynchronously
that it is requested to change how it is handling X11 input events.
Frankly, I think it would be a huge headache to get this working.

The only alternative I have been able to come up with is to
move the "q" processing for the current plot window out of gnuplot_x11
altogether, and make it equivalent to 
   bind 'q' '<some command related to set term x11 close>'
If you have any better ideas, please speak up.

> thus, command.c should call 
> "x11_hotkeys(0)" and afterwards "x11_hotkeys(1)" to enable them again.

x11_hotkeys()?   Is this a new driver primitive that you have designed?
I agree it would be possible to do this sort of thing by adding a new set
of driver primitives.  But that's a big job and I don't have time to tackle it.

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Time to branch off 4.0 from 4.1?

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

> I have some ideas, but not a complete solution.
> How exactly do you "close gnuplot"?  Do you mean that you
> click on one of the buttons that the window manager adds to
> the frame of the plot window?  Or do you type "q", or what?

Yes, by hitting "q" key or by Alt-F4.

> On the gnuplot side I have added code to terminate the
> paused_for_mouse state whenever a GE_reset event is seen.
>
> Please let me know if this change resolves your problems with
> running gnuplot via a script.  There are ways to close a window that
> bypass this mechanism (killing gnuplot_x11 from the command line is
> one of them), but I think this change handles the normal cases.

Yes, it works better. Now, can you please add the following improvement:

If user closes gnuplot_x11, then "show variables" should have define all
usual mousing variables, obviously with zero values, and the MOUSE_KEY
should be set to -1:

MOUSE_X = 0
MOUSE_Y = 0
MOUSE_X2 = 0
MOUSE_Y2 = 0
MOUSE_SHIFT = 0
MOUSE_ALT = 0
MOUSE_CTRL = 0
MOUSE_KEY = -1

This is absolutely important in order not to break scripts for bidirectional
communication of other programs with gnuplo, which get feedback from mousing
by writing the above MOUSE_* values to pipe / fifo.

In my testing Octave scripts, which does some actions passed from gnuplot's
"pause mouse key", after the following sent to gnuplot via fifo:

fprintf(gp.f, 'pause mouse key\n\n');
fflush(gp.f);
fprintf(gp.f, 'print MOUSE_X, MOUSE_Y, MOUSE_KEY\n');
fflush(gp.f);

gnuplot reports (obvious) error: "undefined variable: MOUSE_KEY".


Finally, what do you think about this: "q" hotkey is disabled when "pause
mouse key" comes to action; thus, command.c should call "x11_hotkeys(0)"
and afterwards "x11_hotkeys(1)" to enable them again. Note that "<space>"
hotkey is still quite useful to be unchanged.

---
PM

Re: Mouse control

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

> like the viewing angle.  This is if I run gnuplot from the terminal.  If
> I execute gnuplot from inside the script the mouse can not be used to
> change the viewing angle.  I am starting up gnuplot in the following
> way:
>
> 	Am I doing something wrong here, or is there something I can add.  I
> thought that it is due to a strange setting of the display variable but
> I checked that it is set to ":0.0".  Any ideas?

Please read gnuplot FAQ as well as 'help term x11'. It says you must do 'set
mouse' before plotting to x11.

---
PM

Re: Time to branch off 4.0 from 4.1?

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

On Thursday 17 June 2004 05:26 am, Petr Mikulik wrote:
>
> The problem is when "pause mouse" is issued by an application using
> gnuplot as its front end. Particular case: In Octave, I use ginput.m
> (see gnuplot web page for the script) to receive given number of point
> coordinates. Then, it send "pause mouse" to gnuplot and reads one
> coordinate after another using fifo. If you close gnuplot in between,
> then the reader gets blocked -- you will need "Ctrl-C" in your driving
> application, or to kill gnuplot, or like that.
>
> Do you have an idea how to avoid this block?

I have added a check in gplt_x11 for the DestroyNotify event,
which should be generated any time a plot window is closed.
If it is the current plot window, then gnuplot_x11 passes the
information on to gnuplot via the mousing pipe using the existing
GE_reset mechanism.

On the gnuplot side I have added code to terminate the
paused_for_mouse state whenever a GE_reset event is seen.

Please let me know if this change resolves your problems with
running gnuplot via a script.  There are ways to close a window that
bypass this mechanism (killing gnuplot_x11 from the command line is
one of them), but I think this change handles the normal cases.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Mouse control

[Justace C. <pro...@co...>]

Developers and Users...

	I have been playing around with gnuplot inside of my perl scripts for a
bit now.  All is going well except for one thing.  When I use splot to
plot "x y z" groups I can use the mouse to move the plot around, ie:
like the viewing angle.  This is if I run gnuplot from the terminal.  If
I execute gnuplot from inside the script the mouse can not be used to
change the viewing angle.  I am starting up gnuplot in the following
way:

  open(GNUPLOT, "|gnuplot");
  GNUPLOT->autoflush(1);

  print GNUPLOT "

    set xrange [1:${maxX}]
    set xtics (1, 129, 257, 385, 513, 641, 769, 897)
    set format y \"%3.0f\"

    set title \"${Ltitle}\"
    set ylabel \"Average Pedestal\"
    set xlabel \"\"
  ";

  if($fullscale == 1) {
    print GNUPLOT "
      set yrange [0:260]
    ";
  } else {
    print GNUPLOT "
      set yrange [${minY}:${maxY}]
    ";
  }

  print GNUPLOT "
    splot '${tmpfile}' using 1:2:3 title \"\" pt 7 ps .5

    pause -1

  ";

  getc();


	Am I doing something wrong here, or is there something I can add.  I
thought that it is due to a strange setting of the display variable but
I checked that it is set to ":0.0".  Any ideas?

Justace

Re: Time to branch off 4.0 from 4.1?

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

> > Another point follows a recent discussion: when in "pause mouse" on X11,
> > and closing the window, then gnuplot does not respond any longer and it
> > must be killed.
>
> I can't replicate this behavior either with the current cvs version.
> Yes, if you close the plot window then you need to type ctrl-C to exit the
> pause-for-mouse state.  But this doesn't kill gnuplot, it just returns to the
> command line.

Yes, it works as you explain.

The problem is when "pause mouse" is issued by an application using gnuplot
as its front end. Particular case: In Octave, I use ginput.m (see gnuplot
web page for the script) to receive given number of point coordinates. Then,
it send "pause mouse" to gnuplot and reads one coordinate after another
using fifo. If you close gnuplot in between, then the reader gets blocked --
you will need "Ctrl-C" in your driving application, or to kill gnuplot, or
like that.

Do you have an idea how to avoid this block?

---
PM

Re: Time to branch off 4.0 from 4.1?

[Hans-Bernhard B. <br...@ph...>]

On Wed, 16 Jun 2004, Allin Cottrell wrote:

> On Wed, 16 Jun 2004, Ethan Merritt wrote:
> 
> > So I think Stephane's patch is usable, with maybe a footnote
> > somewhere to warn of possible character problems.  My
> > one remaining reservation is that the revised version is no
> > longer unicode compatible.
> 
> Could we persuade Stephane to revert that aspect of the change?  

Or, maybe more to the point: is it feasible to break out that aspect and
only keep the other modifications?  Stephane originally submitted a
complete modified emf.trm instead of a diff, IIRC, but that shouldn't stop
us from merging that and the current emf.trm selectively.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Time to branch off 4.0 from 4.1?

[Hans-Bernhard B. <br...@ph...>]

On Wed, 16 Jun 2004, Ethan Merritt wrote:

> On the topic of compiler compatibility, 
> do we care about the following warnings from "gcc -pedantic"?

We should care, but not too strongly.   This is one of the pedantic
ISO/ANSI C limits that pretty much every compiler on the planet seems to
overcome easily.  I.e. they seem to have been a bit more cautious in 
selecting that number than they strictly had to.

In other words: there are *lots* of serious warnings we should tackle
first before worrying about these.  -pedantic mode is the least of our
worries, as long as a simple gcc drowns us in hundreds of -Wsign-compare
warnings.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Time to branch off 4.0 from 4.1?

[Allin C. <cot...@wf...>]

On Wed, 16 Jun 2004, Ethan Merritt wrote:

> So I think Stephane's patch is usable, with maybe a footnote
> somewhere to warn of possible character problems.  My
> one remaining reservation is that the revised version is no
> longer unicode compatible.

Could we persuade Stephane to revert that aspect of the change?  As I
recall, he made the change for compatibility with libemf, but the
non-recognition of the "wide" version of emf text is itself a bug in
libemf, and furthermore I'm not aware of anyone using libemf (which is
a bit of a shame, but there you are); gnuplot certainly doesn't use
it in any way.

Allin Cottrell

Re: Time to branch off 4.0 from 4.1?

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

On the topic of compiler compatibility, 
do we care about the following warnings from "gcc -pedantic"?

set.c:181: warning: string length `738' is greater than the length `509' ISO C89 compilers are required to support
show.c:184: warning: string length `753' is greater than the length `509' ISO C89 compilers are required to support
show.c:880: warning: string length `541' is greater than the length `509' ISO C89 compilers are required to support
../term/dxf.trm:182: warning: string length `985' is greater than the length `509' ISO C89 compilers are required to support
../term/svg.trm:632: warning: string length `1027' is greater than the length `509' ISO C89 compilers are required to support
../term/pslatex.trm:270: warning: string length `1079' is greater than the length `509' ISO C89 compilers are required to support
../term/pstricks.trm:258: warning: string length `747' is greater than the length `509' ISO C89 compilers are required to support
../term/metafont.trm:204: warning: string length `1548' is greater than the length `509' ISO C89 compilers are required to support
../term/metafont.trm:261: warning: string length `807' is greater than the length `509' ISO C89 compilers are required to support
../term/metafont.trm:298: warning: string length `519' is greater than the length `509' ISO C89 compilers are required to support
../term/metapost.trm:466: warning: string length `1969' is greater than the length `509' ISO C89 compilers are required to support
unset.c:149: warning: string length `774' is greater than the length `509' ISO C89 compilers are required to support


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Mouse coord lag (Re: An observation in animate demo.)

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

On Tuesday 15 June 2004 10:28 am, Daniel J Sebald wrote:
> I found the location of HAVE_USLEEP in the most recent CVS version and
> commented out the "usleep(100)" code.  That removes the "lag" in text
> drawing.

Apologies, Dan.  You are correct that the usleep() call is causing the
problem.  I went astray because I didn't realize that different linux kernels
implement the underlying operating system call differently, and I imagine
there is variation in other OS implementations as well.

I originally tested this code on a system that truly counts out the
requested number of microseconds.  But most out-of-the-box
linux systems guarantee only that *at least* that much time elapses,
and in fact return on the next clock tick (1/60 of a seconds).  This is
no good.

So it seems the cure can be worse than the disease in this case.
(Remember the original problem only manifested if the user 
suspended gnuplot without backgrounding it as well).  I will try to
find a different cure, but if I can't I will just back out the usleep() call
altogether.


-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Time to branch off 4.0 from 4.1?

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

On Wednesday 16 June 2004 06:49 am, Allin Cottrell wrote:
>
> That's true of the 4.0 release, but not once the patch recently
> submitted by Stephane is applied.  Ethan had trouble reading
> gnuplot-generated EMFs under wine, but the evidence is that the
> new-format gnuplot EMFs are read correctly under the actual Windows
> gdi.

Correct.  Also I later discovered that the character strangeness
under wine can be fixed after reading in the plot by explicitly
selecting "convert to MicroSoft Office drawing object".

So I think Stephane's patch is usable, with maybe a footnote
somewhere to warn of possible character problems.  My
one remaining reservation is that the revised version is no
longer unicode compatible.  

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Time to branch off 4.0 from 4.1?

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

On Wednesday 16 June 2004 07:01 am, Petr Mikulik wrote:
> Another point follows a recent discussion: when in "pause mouse" on X11,
> and closing the window, then gnuplot does not respond any longer and it
> must be killed.

I can't replicate this behavior either with the current cvs version.
Yes, if you close the plot window then you need to type ctrl-C to exit the 
pause-for-mouse state.  But this doesn't kill gnuplot, it just returns to the
command line.

Could you please give me an exact sequence of commands and
events to try using the current cvs version?  

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Time to branch off 4.0 from 4.1?

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

> I sense some of us are already champing at the bit to get off with
> integrating tons of new features into 4.1, once it's started.

Yes, I'm looking forward to this event!

> *) If we move towards ANSI-C function definitions, I think that should be
> *) K&R incompatibilities.  Mainly the use of 'char' in some function's

I'm not expert here, but I propose to have gnuplot 4.0 compatible to as much
as compilers possible -- 4.0 is a major step forward, so why not have it
that. (If somebody will ever need a K&R compatibility in future versions, he
can submit an (unofficial) patch to SF -- as most current developers don't
access such compilers, that's the reason for being unofficial.)

> *) Some currently open bugs that need fixing.  I won't even try to comment
> on the recurring mouse interaction timing/concurrency problems on various
> platforms.
> But the yrange flip needs to be fixed

yes, now it is quite irritating

Another point follows a recent discussion: when in "pause mouse" on X11, and
closing the window, then gnuplot does not respond any longer and it must be
killed. Also, it should not close itself when hitting "q" (especially not
in "pause mouse key").

---
PM

Re: Time to branch off 4.0 from 4.1?

[Allin C. <cot...@wf...>]

On Wed, 16 Jun 2004, Hans-Bernhard Broeker wrote:

> *) K&R incompatibilities.  Mainly the use of 'char' in some function's
> parameter lists, most prominently in the terminal API.  Currently we're
> neither fully compatible with K&R, nor with ANSI-C.  I suggest we fix
> towards K&R C after the split, and only on the 4.0 branch.  The 4.1 stem
> would be moved towards ANSI/ISO C instead.

This sounds good to me.

> *) Some currently open bugs that need fixing.  I won't even try to comment
> on the recurring mouse interaction timing/concurrency problems on various
> platforms.  But the yrange flip needs to be fixed, and the EMF terminal
> output has to be made compatible with Windows 2K and XP (note: I suspect
> any dependence on _Office_ version numbers is a red herring) --- it's
> essentially unusable right now.

That's true of the 4.0 release, but not once the patch recently
submitted by Stephane is applied.  Ethan had trouble reading
gnuplot-generated EMFs under wine, but the evidence is that the
new-format gnuplot EMFs are read correctly under the actual Windows
gdi.

-- 
Allin Cottrell
Department of Economics
Wake Forest University, NC

Time to branch off 4.0 from 4.1?

[Hans-Bernhard B. <br...@ph...>]

Hello, everyone,

I sense some of us are already champing at the bit to get off with
integrating tons of new features into 4.1, once it's started.  In-flow of
new bugs also seems pretty much within expectations for a stable release
by now, so it seems time to move on.  Thus I'm prepared to tag and branch
any time now, but I'ld like some things cleared up first:

*) If we move towards ANSI-C function definitions, I think that should be
done *before* we split off a 4.0 branch, to reduce "patch distance"  
between the two branches.  I'm in favour of doing that, with a tag 4.0.1
before we start it, and another tag (4.0.2) right afterwards.  4.0.2 would
become the branch-off point for the 4.0-release branch.

*) K&R incompatibilities.  Mainly the use of 'char' in some function's
parameter lists, most prominently in the terminal API.  Currently we're
neither fully compatible with K&R, nor with ANSI-C.  I suggest we fix
towards K&R C after the split, and only on the 4.0 branch.  The 4.1 stem
would be moved towards ANSI/ISO C instead.  We will have to burn the
bridges to K&R C at some point, and this feels as good a time as any.  
The only viable alternative to this approach I see right now would be to
step onto a soapbox and declare 3.7.3 as the last version actually
compilable on K&R compilers, and that's that.

*) Some currently open bugs that need fixing.  I won't even try to comment
on the recurring mouse interaction timing/concurrency problems on various
platforms.  But the yrange flip needs to be fixed, and the EMF terminal
output has to be made compatible with Windows 2K and XP (note: I suspect
any dependence on _Office_ version numbers is a red herring) --- it's
essentially unusable right now.

-- 
Hans-Bernhard Broeker (br...@ph...)
Even if all the snow were burnt, ashes would remain.

Re: Mouse coord lag (Re: An observation in animate demo.)

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

Ethan Merritt wrote:

>I have replicated your observation, and I can confirm that
>the patch fixes it.  If it bothers you, you can apply the attached
>patch to gplt_x11.c.   This patch is from Jay Painter, and I don't
>fully understand it, which is why I was reluctant to insert it into
>version 4.0 late in the game.
>
Well, I can't get the patch to work on the latest CVS version.  The diff file breaks up the hunks in a strange way where "#ifdef USE_MOUSE" and "#if 0" are used.

There are a number of modifications in the patch, but it seems to me the new core change within is the use of XCheckEvent, i.e.,

+    while (XCheckTypedWindowEvent(dpy, event->xany.window, ConfigureNotify, event));

What this does, I believe, is keep getting ConfigureNotify type events 
(and discarding after getting) until there are none left in the queue. 
 At that point the last one that was retrieved (XCheckEvent doesn't 
modify "event" unless there is a valid one present) is the one that is 
acted upon.  I'm assuming then with this change the mouse events that 
are queued, except for the most recent, are discarded.

As for all the other smaller changes, I can't tell what the 
ramifications are without being able to patch the file.

Dan

Re: Mouse coord lag (Re: An observation in animate demo.)

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

On Tuesday 15 June 2004 08:34 am, Ethan Merritt wrote:
> On Tuesday 15 June 2004 01:42 am, Daniel J Sebald wrote:
> > I haven't pinpointed where the lag is coming from to confirm it is
> > associated with the above change, so it could be a different change as
> > well.
>
> The underlying problem here is the re-drawing algorithm.
> I have had a fix queued up, but it's a large enough change that
> I felt uneasy about putting it in before the version 4.0 release.

I have replicated your observation, and I can confirm that
the patch fixes it.  If it bothers you, you can apply the attached
patch to gplt_x11.c.   This patch is from Jay Painter, and I don't
fully understand it, which is why I was reluctant to insert it into
version 4.0 late in the game.



-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: Mouse coord lag (Re: An observation in animate demo.)

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

Daniel J Sebald wrote:

> Before diving too much into this, let's make sure it is, in fact, a 
> change between these two dates that is causing this.  I am fairly 
> certain the versions I speak of above are just as downloaded from CVS. 
> (Before making any changes, I always duplicate the "gnuplot" directory 
> to "gnuplot-cvs".) 


And no one else seems to see this, so that is making me wonder too.

Dan

Re: Mouse coord lag (Re: An observation in animate demo.)

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

Ethan Merritt wrote:

>Is it rotated text?
>

It isn't rotated text.

I thought I had the date of the changed pinned down somewhat.  However, 
there is a month's time between the two version.  From what I can see, 
there is a version I downloaded on May 4, 2004 in which I see no slow 
text drawing.  Then there is a version I downloaded on May 31, 2004 in 
which I see slow text drawing.

I have attached a "diff" between the two directories... and there are a 
*lot* of changes, so I'm not sure how much this would help.  Perhaps you 
know better what to look for.

Before diving too much into this, let's make sure it is, in fact, a 
change between these two dates that is causing this.  I am fairly 
certain the versions I speak of above are just as downloaded from CVS. 
 (Before making any changes, I always duplicate the "gnuplot" directory 
to "gnuplot-cvs".)

Dan

Re: Mouse coord lag (Re: An observation in animate demo.)

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

On Tuesday 15 June 2004 01:42 am, Daniel J Sebald wrote:
> I haven't pinpointed where the lag is coming from to confirm it is
> associated with the above change, so it could be a different change as
> well.

Do you have any rotated text in your figure?
That is the only case that I know for certain has slowed down.
The underlying problem here is the re-drawing algorithm.
I have had a fix queued up, but it's a large enough change that
I felt uneasy about putting it in before the version 4.0 release.

> Oh, something peculiar though.  By doing the above jostling of the
> mouse, the dashed box seems to be fast responding.  Why would it be that
> the dashed box gets to its final position so quickly while the text
> keeps drawing away?

Is it rotated text?

-- 
Ethan A Merritt       merritt@u.washington.edu
Biomolecular Structure Center
Mailstop 357742
University of Washington, Seattle, WA 98195

Re: y-axis reversed again

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

> >There seems to be again the bug of "y-axis gets reversed" in "set pm3d map"
> >splots. Now, every 2nd splot zoomed by mouse has reversed y-axis. Can you
> >please have a look to this?
>
> Just to narrow this down, please try duplicating what you are seeing
> with "-nofeedback" at the command line.

This option doesn't matter.

Just do
	set pm3d map
	splot x

and zoom it by mouse several times. Y-range reverses every 2nd time.

---
PM