[Plplot-devel] -eofill issues with -dev wxwidgets and possible rewrite of streams and src/plargs.c

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

On 2017-09-30 15:06+0100 Phil Rosenberg wrote:

> Hi Alan
>
>
> On 30 September 2017 at 07:31, Alan W. Irwin <ir...@be...> wrote:
>> On 2017-09-30 02:27+0100 p.d...@gm... wrote:
>>
>>> I suspect this will be a bug in the render buffer, where the fill
>>
>> method is not correctly stored in or read from the buffer. You can
>> check this by doing a plreplot with and device and seeing if the
>> correct behaviour is maintained.
>>
>> To Phil and Jim:
>>
>> @Jim:
>>
>> I am specifically also addressing you in this discussion because of
>> your knowledge of the plbuf code so I hope you will be able to reply
>> to the final question below.
>>
>>
>> Also, I have some contradictory evidence regarding what you suspect
>> above.  For example when I search src/plbuf.c for "eofill" there is
>> nothing.  Also, when I search that code for anything to do with fills,
>> the fill state appears to only include information concerning discrete
>> fills (with line patterns as in example 15) rather than information
>> like pls->dev_eofill that is needed for solid fills.  So I suspect
>> adding that information to the fill state might solve this issue.
>>
>> However, without attempting to make such a change (yet) if I run
>>
>> examples/c/x27c -dev qtwidget -eofill
>>
>> or
>>
>> examples/c/x27c -dev xwin -eofill
>>
>> I get the correct behaviour (an odd-even rule fill) regardless of
>> whether I resize the GUI or call plreplot after each call to
>> spiro in examples/c/x27c.c.  Aren't both of those actions supposed
>> to use the plbuf code to replot the buffer?  And from the above
>> search of the src/plbuf.c code how is it possible that pls->dev_eofill is
>> used properly by this code when no
>> reference to that exists within that code.
>>
>> @Phil and Jim:
>>
>> I obviously must be missing something about the plbuf code, but what?
>>
>
>
> Having just had a quick look at the code, args.c has no mention of the
> buffer at all. I suspect that what is happening with your test case is
> that even when the buffer is parsed the same plStream struct is used
> with the flag correctly set. The buffer will never overwrite this flag
> because it never recorded it in the first place.

Hi Phil:

Your reply inadvertently dropped Jim and the list from the addressees so
I have reinstated those for obvious reasons.  I have also changed the
subject line to the current topics that have been raised during this
discussion.

Your above remark does appear to give a rational explanation of why
the above experiments worked. Therefore, there must be something else
special to the -dev wxwidgets case that makes that case not work.  By
the way, other command-line options such as

examples/c/x27c -dev wxwidgets -geometry 300x200

do work fine for -dev wxwidgets so the issue with the -eofill option
with -dev wxwidgets is likely not a general command-line option issue
with -dev wxwidgets but something specific about how the -eofill
option is handled for the -dev wxwidgets case.

>
> Something that I often wondered with regards to these options - why
> are they not dealt with via plP_state? These are things that change
> the state of the stream and then all the buffer recording would be
> performed in one location. Also I tend to feel that a function
> plsfillrule( PLINT rule ) would be much more intuitive than messing
> around with strings and calling plparseopts(). Similarly with other
> options like setting the driver etc.
>
> So, I think the best way to fix this is to have the various args.c
> routines call plP_state() to pass the information in question to the
> drivers and get it recorded to the buffer.

If I remember correctly, Andrew Ross tried (way back when) to
implement what he thought were some important yet simplifying changes
to the src/plargs.c code, but he could not get them to work so had to
reluctantly abandon that development effort despite his huge
familiarity with the PLplot code at that time.  So that is
simultaneously a warning about the complexity of the plargs.c
implemention and a huge motivation to reimplement it in a way that is
much easier to understand.  And if it turns out the -eofill issue with
wxwidgets is because of some subtle issue with src/plargs.c that is
another big motivation to reimplement that code.

Also, if you are going to tackle this project you (and Jim) should
probably also look hard at Maurice's historical suggestion concerning
streams which was as follows:

___________________________
Date: Tue, 10 Dec 2002 02:52:43 -0600 (CST)
From: Maurice LeBrun <mj...@ga...>
To: Alan W. Irwin <ir...@be...>
Cc: PLplot development list <Plp...@li...>
Subject: Re: [Plplot-devel] plinit, plend, plinit sequence now works, but I am having second thoughts

I can't tell you the specific answer to your questions due to how maniacally
busy I am these days (having just joined Lightspeed Semiconductor), but I can
elucidate some of the plplot design ideas that have historically been
un-documented.  And, I can give it in an object-oriented context, which
(because it is "canonical") is a lot nicer than the "this is the way it should
work" approach I've used historically. :)

This also includes proposals for change to how we do it now -- i.e. the
behavior of plinit().  I've always been somewhat bothered by the way stream 0
vs stream N is handled (this bugged me back in '94 but I wasn't exactly
swimming in free time then either).

When plplot starts, you have the statically pre-allocated stream, stream 0.
Yes the stream 0 that I hate b/c it's not allocated on the heap like a proper
data-structure/object (in the plframe widget I automatically start from stream
1).

So stream 0 is like a class definition and an instance rolled into one.  What
I think we need to do is get rid of the "instance" part of this and leave
stream 0 as a "class definition" only.  In this case all the command line
arguments and initial pls...() calls (before plinit) serve to override the
default initializion of the class variables, i.e. set stream 0 parameters only

In other words, stream 0 becomes the template for all plplot streams.  You can
use it, but once you've called plinit() you have your own "instance" of the
plplot "object" -- i.e. you have a new stream with all the relevant state info
copied from stream 0.  If you change it, it dies when your stream dies with
plend1().
If you really want to change stream 0 (i.e. the "plplot object" "class data")
you can always set your stream number to 0 and fire away.

To summarize:

plinit() creates a new stream, copied from stream 0
plend1() deletes that stream
plend() deletes all streams, except of course stream 0 which is "class data"

___________________________

Maurice's idea was never implemented, but if this idea excites you and
you would feel it would simplify rewriting src/plargs.c, then you (or
Jim) should do the streams change first, and if that passes all
comprehensive tests (which I would be happy to help with), then do the
rewrite of src/plargs.c afterwards.

@Phil and Jim:

Anyhow, I strongly encourage you to try anything you like here with
streams and src/plargs.c with the obvious caveats that the resulting
code should be easier to understand and give as good or better results
than the current code when comprehensive tests are applied.  It also
"would be nice" if these changes solved the original problem that
started this discussion which is to get the -eofill option to work
properly for -dev wxwidgets, but we don't have the knowledge at this
stage to decide whether that fix is orthogonal or not to the discussed
changes in streams and src/plargs.c so "time will tell" on that issue.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________