plplot-devel — Technical discussion about PLplot development

Re: [Plplot-devel] tk03 bug

[Alan W. I. <ir...@be...>]

On Mon, 24 Dec 2001, Maurice LeBrun wrote:

> Alan W. Irwin writes:
>  > ./plserver -f tk03
>  >
>  > Every time I click on the "open new" button, I get the following error
>  > message:
>  >
>  > *** PLPLOT WARNING ***
>  > plgdevlst:  too many devices
>
> I'm on it.  There's also some configuration problems involving excluded
> devices, which I have a pretty good idea how to fix.
>
> I've also got a project going involving revamping the way resources are
> set for Tk widgets.  I'd kinda hoped to get it installed w/ reasonable
> backward compatibility & tested b/f the next release, but I'll need at
> least a week.  Wanna put off the release for a few weeks?

Sure, so long as "few" translates to 4 or less....;-) That fits in pretty
much with my timing since I have a lot of things from the wishlist I would
like to do before the release.  Hopefully, both of us will be done long
before 24 January so we can release earlier, but let's set 24 January as the
hard deadline for the release.

Alan

Re: [Plplot-devel] tk03 bug

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > ./plserver -f tk03
 > 
 > Every time I click on the "open new" button, I get the following error
 > message:
 > 
 > *** PLPLOT WARNING ***
 > plgdevlst:  too many devices

I'm on it.  There's also some configuration problems involving excluded
devices, which I have a pretty good idea how to fix.

I've also got a project going involving revamping the way resources are
set for Tk widgets.  I'd kinda hoped to get it installed w/ reasonable
backward compatibility & tested b/f the next release, but I'll need at
least a week.  Wanna put off the release for a few weeks?

-- 
Maurice LeBrun    mj...@ga...

[Plplot-devel] Our mail list problems continue, but I am making good progress

[Alan W. I. <ir...@be...>]

Yesterday only a subset of my plplot_cvs commit messages got through.  I
posted a support request about this to SF.  Although there has been no
official response and the mail status report there (dated November 28, grrh)
says everything is fine, here is one users response to my support request.

"Alan, this problem is affecting a number of projects - you
were lucky to have things working again for a short while.
We (anjuta) have had no messages through our lists for a
good while :-(

"Monitoring a number of support requests for information on
what might be wrong.

So apparently this problem is not just specific to us.

This is awkward timing for us with the last minute commits and messages
associated with the pre-release period.  Also, with the Christmas break upon
us, I don't expect SF to do much about it for a while.  Anyhow, if you must
get a message through to another developer, use their private e-mail address
as well as plplot-devel.

Also, even though the plplot-cvs list is not reliable, please don't let that
intimidate you from doing well-defined projects before the release.  For
example, I am beginning to make some good progress on getting consistency
between all the standard examples for the various front ends.  The scorecard
is yorick, java, tcl, python, and C all give the same results up to example
7 (aside from some small shifting of letters in some examples which I
believe is due to inevitable floating-point logic in the decision about
letter stroke positioning.) Today, I hope to finish off getting
consistent results for example 8 (only tcl still to do).

My goal is to get consistent results for all examples (excluding the
complicated 14th, 17th, 19th, and 20th examples). I expect finishing this
project will be more time-consuming than what I have done so far up to
example 8. The segfault problems in example 9 for python still need to be
investigated/fixed, and the api extensions and complete example scripts need
to be generated for certain of the remaining examples/front ends.
Nevertheless, because of the progress I have been able to make in the last
couple of days, I still have good hope that I can get this completely done
before the release.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

[Plplot-devel] Source Forge mail is slow or else not working at all

[Alan W. I. <ir...@be...>]

I have made several important commits today with no notice back.  Also remarks
about the commits (all of Olof's windows stuff) to the devel list with nothing
back from sourceforge.  It is possible they are right in the middle of the
transition to the new mail handling facility, but the sourceforge status page
says nothing about the mail service being down.

Anyhow, be careful to do cvs update before you change anything now since the
sourceforge mail service is either slow or completely halted.

You will know there is actually no problem any more if you get this message
twice.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

[Plplot-devel] Re: Win32 patch

[Alan W. I. <ir...@be...>]

On Fri, 21 Dec 2001, Olof Svensson wrote:

> Hi Alan,
>
> here's the patch I promised you last week - it took a little bit longer
> because Alexandre Gobbo and I fought to get Python with pyqt working
> with this driver under windows - and yesterday we managed!

Thanks very much for this effort.  It is great to hear your report that
plplot now works fine for win 98, win NT, and win 2K!

I have just applied your patch to CVS.  Could you please try a clean
checkout (i.e. to entirely new plplot directory) to make sure everything is
in CVS that is required by you?

> Here's the instruction to build the examples:
>
>   * Open a MS-DOS prompt window
>   * Change directory to plplot\sys\win32\msdev
>   * Type "nmake"
>   * Type "cd plplip"
>   * Type "nmake plplib.mak"
>   * Type "cd ..\Examples"
>   * Type "nmake Examples.mak"
>
> The example executables can then be found in plplot\tmp.

I don't have access to win 98, NT, or 2000, but I strongly encourage anybody
else here with such access to give this a try.

>
> What is left now is to write some documentation and update the
> INSTALL.TXT file. I'll wait with this till the last moment before the
> release since I might have some time to implement some missing
> features... I'll be on holiday over Christmas and I'll be back on
> January 3rd. I'll check my emails so if you decide to release the new
> version before January 3rd just send me an email and I'll write up
> something for the documentation.

Please do that now while everything is fresh in your mind!  Also, it is
tough enough to coordinate release timing with Joao (who will be helping
with the testing) so it would simplify my life if you document what is in
CVS now rather than waiting for the perfect moment.

>
> Alexandre and I will come back after Christmas with a patch for the
> python binding.

I will look forward to that.

>
> PS. Would it be possible to rename the "win3" device to "win32"? I think
> it was called "win3" because it was supposed to also run on Windows 3.X,
> which is now rather obsolete... I have though no strong feelings about
> this and I can happily continue with calling the device "win3".

I have no strong feelings either.  Does anybody else?

Once again, thanks to you and Alexandre for making plplot work in a number
of windows environments again.

Alan

RE: [Plplot-devel] tk03 bug

[Alan W. I. <ir...@be...>]

On Thu, 20 Dec 2001, Geoffrey Furnish wrote:

> I think it would be worth checking if a similar config without dynamic
> drivers, shows the same problem.

Good call!  (I should have thought of that myself, but I was fixated on the
fact that the tk driver is static.) There is no warning message at all with
static configuration, and I exercised the GUI quite hard hitting "open new"
many times and getting good-looking results (and no warning message) in
every case.

So somehow the dynamic configuration is interfering with the static tk
driver enough to generate the warning message consistently for me, and that
interference does not seem to happen for static configuration. This problem
may have been with us from the early days of the dynamic form of drivers.
My tests of 5.0.4 were of course for static, and my few tk tests since then
might also have been for static configuration.

I hope you or Maurice (who I view as our Tcl/Tk experts here) can get to the
bottom of this one in short order.  Although there don't seem to be any
practical consequences of the warning message you get with dynamic
configuration and tk03, I am always concerned such messages are a symptom of
some deeper-lying, important problem.

Alan

[Plplot-devel] tk03 bug

[Alan W. I. <ir...@be...>]

I built plplot from CVS head with the following commands:

cd plplot

make configure

./configure --prefix=/usr/local/plplot --with-double \
--enable-dynamic-drivers --enable-java --enable-gnome > & ! configure.out

make >&! make.out

There were no errors in the configure or make step.

cd tmp
make cdemos fdemos cxxdemos tkdemos

(This step had no errors.  Probably only the last of these is necessary to
show the tk03 bug, but I am being explicit about exactly what I did just in
case other people have trouble confirming this).

./plserver -f tk03

Every time I click on the "open new" button, I get the following error
message:

*** PLPLOT WARNING ***
plgdevlst:  too many devices

This warning message did not happen for 5.0.4, and I believe I have also
tested tk03 since the release of 5.0.4 without noticing any messages like
this.  Anyhow, I think it is fairly likely that this warning message is the
result of Maurice's recent tk changes.  I suppose it could also be due to
dynamic driver changes, but I presume that should not have much impact since
the tk driver remains static.

My interactive test of all the tk widget examples shows the results look
good even for tk03.  (Note my tests were quite superficial and did not test
most of the tk GUI widget functions.)

Maurice, do you have the same problem with tk03 on your system?

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] Wish list for the release

[Alan W. I. <ir...@be...>]

On Wed, 19 Dec 2001, Joao Cardoso wrote:

>
> Hi
>
> My wish "list": a cookbook (a README will be OK :) on how to setup java,
> python, pyqt...

That is a good idea, and I will add it to the list
probably above the line....  :( .


> I have tested the current plplot cvs snapshot on a suse-7.2
> (not a clean one, but upgraded from suse-7.0) and I had the "usual" problems
> with environment variables.
>
> The good news is that python (2.0), java (1.1.8), gd (1.8.4) and pyqt (had to
> compile sip-3.0 and PyQt-3.0) worked OK at first sight. Of course the more
> conservative drivers/bindings also worked OK.

Good news, indeed!

Alan

Re: [Plplot-devel] Wish list for the release

[Joao C. <jc...@fe...>]

Hi

My wish "list": a cookbook (a README will be OK :) on how to setup java,=20
python, pyqt... I have tested the current plplot cvs snapshot on a suse-7=
=2E2=20
(not a clean one, but upgraded from suse-7.0) and I had the "usual" probl=
ems=20
with environment variables.

The good news is that python (2.0), java (1.1.8), gd (1.8.4) and pyqt (ha=
d to=20
compile sip-3.0 and PyQt-3.0) worked OK at first sight. Of course the mor=
e=20
conservative drivers/bindings also worked OK.

Joao

Re: [Plplot-devel] Solaris xwin.c fix

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > (1) We have sunos users with this problem as well.  I haven't looked at your
 > cvs commits yet, but if you are detecting solaris at the configuration stage
 > (rather than simply having a user option), then you may want to detect sunos
 > as well.

Yeah, turns out I did need to generalize that, thanks.

 > (2) I have one report that with the old (5.0.4) code on sunos, there was an
 > interesting workaround.  If this user called plParseOpts (indirectly through
 > the yorick front-end, but I just checked the yplot code, and this is the
 > only result of the yplot command he used) the xwin problem disappeared. If a
 > call to plParseOpts solves the problem, perhaps that call is initializing
 > things properly on sunos (and solaris?)?  That might give us a clue how to
 > do the initialization properly in general for those systems so we would no
 > longer need to specify default values in xwin.c for those systems.

Ugh.  Sounds really strange.. no idea what could be happening.  I'd have to
have my hands on such a system to figure things out.

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Solaris xwin.c fix

[Alan W. I. <ir...@be...>]

On Mon, 17 Dec 2001, Alan W. Irwin wrote:

....If this user called plParseOpts (indirectly through
> the yorick front-end, but I just checked the yplot code, and this is the
> only result of the yplot command he used) the xwin problem disappeared.

To be more specific the call was with PL_PARSE_FULL.

Alan

Re: [Plplot-devel] Solaris xwin.c fix

[Alan W. I. <ir...@be...>]

On Sun, 16 Dec 2001, Maurice LeBrun wrote:

> The superior solution is as follows:
>  - turn the DEFAULT_VISUAL #define at the top of xwin.c into a configuration
> variable instead
>  - the configure logic will set DEFAULT_VISUAL to 1 under SunOS, 0 otherwise.
>
> For DEFAULT_VISUAL set to 1, the following lines from GetVisual() will be used:
>
>     if ( ! visuals_matched) {
>         xwd->visual = DefaultVisual( xwd->display, xwd->screen );
>         xwd->depth = DefaultDepth( xwd->display, xwd->screen );
>     }
>
> which will plug into XCreateWindow() in the same way as the DefaultXXX calls
> now.
>
> I'll make the change.

Thanks, Maurice.  Two additional point here.

(1) We have sunos users with this problem as well.  I haven't looked at your
cvs commits yet, but if you are detecting solaris at the configuration stage
(rather than simply having a user option), then you may want to detect sunos
as well.

(2) I have one report that with the old (5.0.4) code on sunos, there was an
interesting workaround.  If this user called plParseOpts (indirectly through
the yorick front-end, but I just checked the yplot code, and this is the
only result of the yplot command he used) the xwin problem disappeared. If a
call to plParseOpts solves the problem, perhaps that call is initializing
things properly on sunos (and solaris?)?  That might give us a clue how to
do the initialization properly in general for those systems so we would no
longer need to specify default values in xwin.c for those systems.

Alan

Re: [Plplot-devel] Solaris xwin.c fix

[Maurice L. <mj...@ga...>]

Maurice LeBrun writes:
 > The superior solution is as follows:
 >  - turn the DEFAULT_VISUAL #define at the top of xwin.c into a configuration
 > variable instead
 >  - the configure logic will set DEFAULT_VISUAL to 1 under SunOS, 0 otherwise.

Done.  I also added the configure logic & other changes to handle the old
problem of missing itclDecls.h's (discussed here last June).

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Solaris xwin.c fix

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > Since we use mostly plplot-general and plplot-devel, it was only by accident
 > that I spotted an xwin suggestion on our forum which appears to be useful.
 > Please look at
 > http://sourceforge.net/forum/forum.php?thread_id=105137&forum_id=8607 where
 > it is stated a change to our XCreateWindow call solves all solaris problems
 > for this particular user.
 > 
 > I don't know anything about the syntax of XCreateWindow, but it appears the
 > guy used the X default depth and visual rather than the values known to
 > plplot (which I assume were either not set correctly at all and the Linux X
 > server could overcome this or had values which were legal for the Linux X
 > server but somehow illegal for the solaris X server).  I applied this change
 > (after correcting his typo where he substituted ev for dev), and it works
 > fine on my Linux box. Thus, I have gone ahead and put it in CVS as a basis
 > for further discussion.

I only just this weekend got a chance to look into this.  In the process I
reviewed all the changes to xwin.c made over the last few months.  The only
one that looks dubious is this one, so it was good that Alan prodded me to
look at it.

I found from "cvs log" the following commits having to do with visuals in
xwin.c :

----------------------------
revision 1.89
date: 2001/11/26 18:54:13;  author: airwin;  state: Exp;  lines: +9 -2
Use default depth and visual when using XCreateWindow.  This works on Linux,
and it apparently solves a problem with the solaris X server, but there may
be a better way to do this.

----------------------------
revision 1.85
date: 2001/08/31 20:27:26;  author: jcard;  state: Exp;  lines: +4 -3
remove the X error handler, needed when the xwin driver
 attempted  to store colors in a true visual colormap.

----------------------------
revision 1.69
date: 1996/10/31 05:08:04;  author: furnish;  state: Exp;  lines: +216 -51
Hack in support for using read only shared color cells when the visual
does not support read write private color cells.  Also, switch
DEVAULT_VISUAL to 0, so that we have a chance of locating a
conventional PseudoColor visual.

----------------------------
revision 1.49
date: 1994/08/25 03:58:15;  author: mjl;  state: Exp;  lines: +41 -16
Change to use default visual for now, since otherwise the current
procedure results in a BadMatch when calling XCreateWindow on some systems
(Suns).  To really get it right, XGetRGBColormaps or something similar
must be used to pair the visual with a compatible colormap.


The last one is telling.. apparently this same problem was encountered &
"fixed" by the same method 7 years ago!

The difficulty is that the new XCreateWindow completely disregards all the
work being done in GetVisual().  I can't really vouch for the code in
GetVisual() as I didn't write it (and have forgotten most of what I learned
about visuals anyway) but I assume it is there for good reason.  Further, the
visual obtained in GetVisual() is then used to set the xwd->rw_cmap, which
could be wrong if the default visual is being used.

The superior solution is as follows:
 - turn the DEFAULT_VISUAL #define at the top of xwin.c into a configuration
variable instead
 - the configure logic will set DEFAULT_VISUAL to 1 under SunOS, 0 otherwise.

For DEFAULT_VISUAL set to 1, the following lines from GetVisual() will be used:

    if ( ! visuals_matched) { 
        xwd->visual = DefaultVisual( xwd->display, xwd->screen ); 
        xwd->depth = DefaultDepth( xwd->display, xwd->screen ); 
    } 

which will plug into XCreateWindow() in the same way as the DefaultXXX calls
now.

I'll make the change.

-- 
Maurice LeBrun    mj...@ga...

[Plplot-devel] Re: cgm driver reasonably stable now

[Alan W. I. <ir...@be...>]

On Fri, 14 Dec 2001, Alan W. Irwin wrote:

> In non-familied mode, page 4 of x16c has red and rather fat contour lines
> rather than the expected thin, yellow contours.  In familied mode the colour
> is fine, but the contours are still fat in error.

N.B. Andrew privately reminded me that the contours of page 4 are supposed to
be wider.  You just cannot see it as well for the psc driver (which I was
comparing with) because the width scale there changes more gradually than
the cgm width scale.  Therefore, the cgm driver was doing the right thing
there.

>
> Also in non-familied mode, p. 6 of the pythondemos and tcldemos has a red
> grid rather than the expected yellow grid.  This error does not occur
> for familied mode.

I just checked, and Andrew's recent fix has solved *all* these mentioned
colour problems for the cgm driver.  Thus, as far as I am concerned it is
perfect. Thanks, Andrew!

In addition to cgm, there is one other vector graphics standard we should
probably support called SVG (Scalable Vector Graphics).  (I hasten to add
this is not something to consider for the current release, but probably
something we should do in the next 6 months or so.) SVG is a vector graphics
format that has recently been adopted as a W3C standard. There is tremendous
excitement about this format as the next big thing for web publishing
because it is XML based and because many kinds of graphics are smaller if
represented as vectors rather than bitmaps.  To see the maturity of static
SVG support already available in a free package, check out the batik
(http://xml.apache.org/batik/index.html) project.

Alan

Re: [Plplot-devel] Wish list for the release

[Alan W. I. <ir...@be...>]

Thanks, Maurice, for that clarification.  This project (as well as my wish
for dynamic tk and xwin drivers) is gone from the release wish list.  So
here is the revised list with some additional comments where progress has
already been made.

(1) Solve the python 2.1 segfault bug for example 9.  Probably release
critical.

(2) Get documentation to build on my new Debian system.  Release critical.

(3) Document what I did recently for the cgm driver configuration.
Hopefully, this will be the start of a new cookbook for the dynamic
(and static) driver configuration.

(4) Finish python examples and modify them to be exact replicas of the
C examples as a consistency check on the python front end.

(4a) Do the same for the tcl examples.

(5) gdimage extended example including all the things to make a colour image
work.

(6) Finish Java examples (with commented out API when that is not available).

Everything above this line is my responsibility.  Everything below is someone
else's responsibility, but I am willing to help with testing.
****************************************

(7) Perfect cgm driver.  DONE (thanks Andrew) except for some rare colour
and width bugs that will probably have to wait for the next release for
solution.

(8) Finish W98 and W2000 changes.  Apparently, Olof has made great progress
here (in fact he is now completely satisfied with the driver), and he
therefore intends to send me the definitive patch early next week.

(9) Get command-line parameter parsing to work for octave x examples.
DONE (Thanks, Joao).

(10) Java API (Geoffrey, once I get some more examples ready for him).

(11) Some refinement of the pyqt GUI.  Allesandro has made some progress on
the paging, but our discussion continues.

(12) There may be some more plimage changes Joao has in mind, but I am
not sure.

I very much appreciate how everybody has responded for projects below the
line (either by making excellent progress toward finishing them or else by
making good arguments why these projects shouldn't be on the wish list for
the release).  If anybody has other short projects in mind which they would
like to see done before the release, please feel free to add them to the
list (below the line, of course....;-))

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Sat, 15 Dec 2001, Maurice LeBrun wrote:

> I'm talking about the 3d shading algorithm, which is bolted on top of the 3d
> perspective (surface) plot.  Not the 2d shade-exclusion problem that was fixed
> previously.  These are way different problems.
>
> The 3d perspective algorithm follows lines of a constant coordinate.  It
> decides to draw or not-draw based on the condition: is it visible.  If it
> crosses from visible to not-visible or vice versa in one segment, the
> intersection point is calculated and the segment drawn from there.  Once
> that coordinate line is finished, the next one is started.  So you see, the
> original algorithm has no concept of "regions" at all.
>
> The new shading code that is bolted on top of this only worked if the triangle
> to be shaded is entirely visible.  If any of the three vertices is not
> visible, the triangle is not plotted at all, which gives rise to the visual
> effects you see in the demo.  I was able to work out boundary conditions for
> some cases and thereby eliminate some of the unshaded areas, but not all.
> It turns out to be surprisingly complex -- after a few initial successes I had
> lots of spectacular failures with spiky triangles drawn all over the screen,
> and had to give up.  At that point I concluded it might be simpler to start
> from scratch with a published 3d shading algorithm.
>
> --
> Maurice LeBrun    mj...@ga...
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Wish list for the release

[Maurice L. <mj...@ga...>]

Alan W. Irwin writes:
 > On Sat, 15 Dec 2001, Maurice LeBrun wrote:
 > 
 > > When I looked into this last spring (fixing several bugs in the process), I
 > > concluded we might be better off with a new algorithm.  The original algorithm
 > > only follows lines, not regions.  If one endpoint of the line is hidden but
 > > the other is not, it merely calculates the intersection point and draws from
 > > that point.  Extending this to 2D and getting it right does not look easy to
 > > me.  The existing shade extension is clever but I found the boundary
 > > conditions too messy to be able to make solid headway without considerable
 > > effort.
 > 
 > Maurice, I am having trouble interpreting your words here since the previous
 > posts in this thread discussed both 2D and 3D shading which have separate
 > algorithms.  I believe (although I am not sure) that part of your paragraph
 > may refer to a better algorithm for the 2D shading (which might be a good
 > idea, but there is currently no bug in that case), and part of the paragraph
 > to 3D shading (which does have a bug). Could you please clarify?  I am
 > particularly interested in whether you think a new 3D shading algorithm is
 > required to fix the 3D shading bug.  If so, I will drop it from the release
 > wish list.

I'm talking about the 3d shading algorithm, which is bolted on top of the 3d
perspective (surface) plot.  Not the 2d shade-exclusion problem that was fixed
previously.  These are way different problems.

The 3d perspective algorithm follows lines of a constant coordinate.  It
decides to draw or not-draw based on the condition: is it visible.  If it
crosses from visible to not-visible or vice versa in one segment, the
intersection point is calculated and the segment drawn from there.  Once
that coordinate line is finished, the next one is started.  So you see, the
original algorithm has no concept of "regions" at all.  

The new shading code that is bolted on top of this only worked if the triangle
to be shaded is entirely visible.  If any of the three vertices is not
visible, the triangle is not plotted at all, which gives rise to the visual
effects you see in the demo.  I was able to work out boundary conditions for
some cases and thereby eliminate some of the unshaded areas, but not all.
It turns out to be surprisingly complex -- after a few initial successes I had
lots of spectacular failures with spiky triangles drawn all over the screen,
and had to give up.  At that point I concluded it might be simpler to start
from scratch with a published 3d shading algorithm.

-- 
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Wish list for the release

[Alan W. I. <ir...@be...>]

Thanks for these clarifications of the status of dynamic Tk driver.  I will
drop this from the release wish list.

Alan

email: ir...@be...
phone: 250-727-2902=09FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

On Sat, 15 Dec 2001, Maurice LeBrun wrote:

> Jo=E3o Cardoso writes:
>  > On Thursday 13 December 2001 21:53, Alan W. Irwin wrote:
>  > | On Thu, 13 Dec 2001, Joao Cardoso wrote:
>  > | > On Tuesday 11 December 2001 23:50, Alan W. Irwin wrote:
>  > ...
>  >
>  > | > | (13) dynamic tk and xwin driver.  (probably Joao).  My
>  > | > | impression from commented out parts of the code that I reviewed
>  > | > | for the cgm driver is this might be ready to go now that we
>  > | > | understand exactly what is required in the gd and cgm cases.
>  > | > | Every dynamic driver requires a link to libplplot and some
>  > | > | require additional links to their own special libraries.
>  > | > | Wouldn't those special libraries just be the Tk library for the
>  > | > | tk driver and the X libraries for the xwin driver?
>  > | >
>  > | > The xwin and tk drivers can't be made dynamic.
>  > | >
>  > | > There is no problem with the xwin driver alone, but the tk driver
>  > | > (either static or dynamic) won't work with a dynamic xwin driver.
>  > | > The tk driver needs some functions that are in the xwin driver.
>  > | >
>  > | > The only solution, which is not elegant, would be to link tk.o
>  > | > and xwin.o to make tk.drv.
>  > |
>  > | Would you please implement this solution?
>  >
>  > I'm sorry, I have forgot other details. I had already deeply
>  > investigated this, and it is *not possible* to make the tk driver
>  > dyn-loadable without serious changes in the library itself. That's
>  > one of the reasons why I started the (not yet funtional) ntk driver.
>  > ...
>  >
>  > Joao
>
> And I'd planned to defer those "serious changes" to when the TEA branch g=
ets
> merged in, after AM/LT (or perhaps at the same time).  I really am going =
to
> work on this :), but not till next month.
>
> --
> Maurice LeBrun    mj...@ga...
>
> _______________________________________________
> Plplot-devel mailing list
> Plp...@li...
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
>

Re: [Plplot-devel] Wish list for the release

[Alan W. I. <ir...@be...>]

On Sat, 15 Dec 2001, Maurice LeBrun wrote:

> When I looked into this last spring (fixing several bugs in the process), I
> concluded we might be better off with a new algorithm.  The original algorithm
> only follows lines, not regions.  If one endpoint of the line is hidden but
> the other is not, it merely calculates the intersection point and draws from
> that point.  Extending this to 2D and getting it right does not look easy to
> me.  The existing shade extension is clever but I found the boundary
> conditions too messy to be able to make solid headway without considerable
> effort.

Maurice, I am having trouble interpreting your words here since the previous
posts in this thread discussed both 2D and 3D shading which have separate
algorithms.  I believe (although I am not sure) that part of your paragraph
may refer to a better algorithm for the 2D shading (which might be a good
idea, but there is currently no bug in that case), and part of the paragraph
to 3D shading (which does have a bug). Could you please clarify?  I am
particularly interested in whether you think a new 3D shading algorithm is
required to fix the 3D shading bug.  If so, I will drop it from the release
wish list.

Alan

Re: [Plplot-devel] Wish list for the release

[Maurice L. <mj...@ga...>]

Jo=E3o Cardoso writes:
 > On Thursday 13 December 2001 21:53, Alan W. Irwin wrote:
 > | On Thu, 13 Dec 2001, Joao Cardoso wrote:
 > | > On Tuesday 11 December 2001 23:50, Alan W. Irwin wrote:
 > ...
 >=20
 > | > | (13) dynamic tk and xwin driver.  (probably Joao).  My
 > | > | impression from commented out parts of the code that I reviewe=
d
 > | > | for the cgm driver is this might be ready to go now that we
 > | > | understand exactly what is required in the gd and cgm cases.=20=

 > | > | Every dynamic driver requires a link to libplplot and some
 > | > | require additional links to their own special libraries.=20
 > | > | Wouldn't those special libraries just be the Tk library for th=
e
 > | > | tk driver and the X libraries for the xwin driver?
 > | >
 > | > The xwin and tk drivers can't be made dynamic.
 > | >
 > | > There is no problem with the xwin driver alone, but the tk drive=
r
 > | > (either static or dynamic) won't work with a dynamic xwin driver=
.
 > | > The tk driver needs some functions that are in the xwin driver.
 > | >
 > | > The only solution, which is not elegant, would be to link tk.o
 > | > and xwin.o to make tk.drv.
 > |
 > | Would you please implement this solution?
 >=20
 > I'm sorry, I have forgot other details. I had already deeply=20
 > investigated this, and it is *not possible* to make the tk driver=20=

 > dyn-loadable without serious changes in the library itself. That's=20=

 > one of the reasons why I started the (not yet funtional) ntk driver.=

 > ...
 >=20
 > Joao

And I'd planned to defer those "serious changes" to when the TEA branch=
 gets
merged in, after AM/LT (or perhaps at the same time).  I really am goin=
g to
work on this :), but not till next month.

--=20
Maurice LeBrun    mj...@ga...

Re: [Plplot-devel] Wish list for the release

[Maurice L. <mj...@ga...>]

Rafael Laboissiere writes:
 > * Alan W. Irwin <ir...@be...> [2001-12-13 13:53]:
 > 
 > > I believe the problem is actually pretty simple.  Just from looking at the
 > > results, the current 3D shaded logic apparently makes a decision about
 > > which (relatively large) triangle is hidden and which not, and has no
 > > facility to refine the triangles shape and size so that they can smoothly
 > > follow the line marking the edge of hidden regions.  We were up against a
 > > similar problem for the excluded regions of 2D shade plots, but (see the
 > > last page of x16c) Rafael found a working solution that involved a binary
 > > search (IIRC) to refine the triangles so they smoothly followed the edge of
 > > the excluded region.  Although he has stated his code cannot be directly
 > > used in the 3D shading case, I am hoping his general idea can be used.  If
 > > so, it should be a matter of a reasonably short effort to fix this with
 > > much thanks for whoever came up with the solution.
 > 
 > >From my recollection, the algorithms have completely different
 > implementations, athough the problems addressed are quite similar.  I am
 > afraid that the effort needed will be not that short, but who knows?

When I looked into this last spring (fixing several bugs in the process), I
concluded we might be better off with a new algorithm.  The original algorithm
only follows lines, not regions.  If one endpoint of the line is hidden but
the other is not, it merely calculates the intersection point and draws from
that point.  Extending this to 2D and getting it right does not look easy to
me.  The existing shade extension is clever but I found the boundary
conditions too messy to be able to make solid headway without considerable
effort.  

-- 
Maurice LeBrun    mj...@ga...

[Plplot-devel] cgm driver reasonably stable now

[Alan W. I. <ir...@be...>]

With the fix to cgm.c that I just committed, all cgm files are generated
smoothly in all modes I tested.

I only found 3 minor rendering problems using visual inspection of the 211
(!) pages of test results in non-familied mode.  I also did some spot checks
in familied mode.

In non-familied mode, page 4 of x16c has red and rather fat contour lines
rather than the expected thin, yellow contours.  In familied mode the colour
is fine, but the contours are still fat in error.

Also in non-familied mode, p. 6 of the pythondemos and tcldemos has a red
grid rather than the expected yellow grid.  This error does not occur
for familied mode.

Andrew, you should be able to see the fat contours for page 4 of x16c in
familied mode, but you will need to install a cgm viewer (ralcgm might
be suitable for your system) that displays multiple pages to look
at the non-familied errors.

I don't know what exactly is clobbering the colour and width on such
relatively rare occasions.  But I think you are the one that should sort
this out since you are most familiar with how colour is handled in cgm.c. It
would be nice if you could get this fixed up before the release, but if you
don't have time now, that is fine as well since these cgm rendering problems
occur so rarely.

Alan

email: ir...@be...
phone: 250-727-2902	FAX: 250-721-7715
snail-mail:
Dr. Alan W. Irwin
Department of Physics and Astronomy,
University of Victoria, P.O. Box 3055,
Victoria, British Columbia, Canada, V8W 3P6
__________________________

Linux-powered astrophysics
__________________________

Re: [Plplot-devel] Wish list for the release

[<jca...@in...>]

On Thursday 13 December 2001 21:53, Alan W. Irwin wrote:
| On Thu, 13 Dec 2001, Joao Cardoso wrote:
| > On Tuesday 11 December 2001 23:50, Alan W. Irwin wrote:
=2E..

| > | (13) dynamic tk and xwin driver.  (probably Joao).  My
| > | impression from commented out parts of the code that I reviewed
| > | for the cgm driver is this might be ready to go now that we
| > | understand exactly what is required in the gd and cgm cases.=20
| > | Every dynamic driver requires a link to libplplot and some
| > | require additional links to their own special libraries.=20
| > | Wouldn't those special libraries just be the Tk library for the
| > | tk driver and the X libraries for the xwin driver?
| >
| > The xwin and tk drivers can't be made dynamic.
| >
| > There is no problem with the xwin driver alone, but the tk driver
| > (either static or dynamic) won't work with a dynamic xwin driver.
| > The tk driver needs some functions that are in the xwin driver.
| >
| > The only solution, which is not elegant, would be to link tk.o
| > and xwin.o to make tk.drv.
|
| Would you please implement this solution?

I'm sorry, I have forgot other details. I had already deeply=20
investigated this, and it is *not possible* to make the tk driver=20
dyn-loadable without serious changes in the library itself. That's=20
one of the reasons why I started the (not yet funtional) ntk driver.
=2E..

Joao

Re: [Plplot-devel] Wish list for the release

[Rafael L. <ra...@ic...>]

* Alan W. Irwin <ir...@be...> [2001-12-13 13:53]:

> I believe the problem is actually pretty simple.  Just from looking at the
> results, the current 3D shaded logic apparently makes a decision about
> which (relatively large) triangle is hidden and which not, and has no
> facility to refine the triangles shape and size so that they can smoothly
> follow the line marking the edge of hidden regions.  We were up against a
> similar problem for the excluded regions of 2D shade plots, but (see the
> last page of x16c) Rafael found a working solution that involved a binary
> search (IIRC) to refine the triangles so they smoothly followed the edge of
> the excluded region.  Although he has stated his code cannot be directly
> used in the 3D shading case, I am hoping his general idea can be used.  If
> so, it should be a matter of a reasonably short effort to fix this with
> much thanks for whoever came up with the solution.

From my recollection, the algorithms have completely different
implementations, athough the problems addressed are quite similar.  I am
afraid that the effort needed will be not that short, but who knows?

-- 
Rafael

Re: [Plplot-devel] Wish list for the release

[Alan W. I. <ir...@be...>]

On Thu, 13 Dec 2001, Joao Cardoso wrote:

> On Tuesday 11 December 2001 23:50, Alan W. Irwin wrote:
> | (12) IMO, the most egregious bug for the plplot library shows up for x08c
> | with the non-smooth edges (missing triangles) to the hidden parts of the
> | plot for pages 5 through 8 (the 3D shade plot demonstration). If a C expert
> | here is wondering how they can chip in, it would be *wonderful* to finally
> | get rid of this bug.
>
>
> Yes, this worries me too, but it is not a matter of C expertise. I think that
> Geoffrey has already tried to correct it, and if I remember correctly he said
> "better to write it from the begining"

I believe the problem is actually pretty simple.  Just from looking at the
results, the current 3D shaded logic apparently makes a decision about which
(relatively large) triangle is hidden and which not, and has no facility to
refine the triangles shape and size so that they can smoothly follow the
line marking the edge of hidden regions.  We were up against a similar
problem for the excluded regions of 2D shade plots, but (see the last page
of x16c) Rafael found a working solution that involved a binary search
(IIRC) to refine the triangles so they smoothly followed the edge of the
excluded region.  Although he has stated his code cannot be directly used in
the 3D shading case, I am hoping his general idea can be used.  If so, it
should be a matter of a reasonably short effort to fix this with much thanks
for whoever came up with the solution.

> |
> | (13) dynamic tk and xwin driver.  (probably Joao).  My impression from
> | commented out parts of the code that I reviewed for the cgm driver is this
> | might be ready to go now that we understand exactly what is required in
> | the gd and cgm cases.  Every dynamic driver requires a link to libplplot
> | and some require additional links to their own special libraries.  Wouldn't
> | those special libraries just be the Tk library for the tk driver and the X
> | libraries for the xwin driver?
>
>
> The xwin and tk drivers can't be made dynamic.
>
> There is no problem with the xwin driver alone, but the tk driver (either
> static or dynamic) won't work with a dynamic xwin driver. The tk driver needs
> some functions that are in the xwin driver.
>
> The only solution, which is not elegant, would be to link tk.o and xwin.o to
> make tk.drv.

Would you please implement this solution?

>
> | I have probably forgotten some things so feel free to add to this list so
> | long as the project is reasonably short (a few days or less).
>
>
> This is an issue that worries me. You make a beatifull job testing plplot
> regularly, and you post your conclusions/bugs/requests. But we might be busy
> at the time, and your conclusions/requests becomes lost. I always archive
> your testing requests for latter usage, but most of the time I just forgot to
> use them.
>
> I think that we should start using some mechanism to correct this. A
> possibility will be using the "tasks manager",
> http://sourceforge.net/pm/?group_id=2915 , creating an entry for each driver
> and language binding. What do you think?

Probably that is a good idea for open-ended projects, but for this release
wishlist I am trying to to stick to short projects that can be finished with
a burst of concentrated effort.

BTW, I now regret my phrasing above where I said "I have probably forgotten
some things...." . I (like many here, I assume) have a long "ToDo" list of
possible fixups and issues we have discussed on this list.  So I never
forget, and I do come back to nag you again....;-)

Actually, what has happened with the wishlist is I made a judgement call
about what subset of the ToDo list involves projects that are short and
predictable enough (as opposed to open-ended) that it seems possible to
squeeze it in before the release. Others may have different views and I
welcome more discussion of this. For example, I will take the 3D shaded plot
bug (as shown by x08c) off the list if the general conclusion is the fix is
too tough to do in a short amount of time for a knowledgable C programmer.
If others want to add more to the list, that's fine as well.  The whole
point of the (amended) list though is these are the items the group feels we
should concentrate on before the release.  The wishlist I presented in my
e-mail was just the first stab at this priority list.

Alan