Hi Alan On 30 September 2017 at 19:35, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2017-09-30 15:06+0100 Phil Rosenberg wrote: > >> Hi Alan >> >> >> On 30 September 2017 at 07:31, Alan W. Irwin <ir...@beluga.phys.uvic.ca> >> wrote: >>> >>> On 2017-09-30 02:27+0100 p.d.rosenb...@gmail.com 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.
Sorry, must have forgot to hit reply all > > 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. Does geometry set the size of the canvas? This is specifically transmitted to the viewer as it is not recorded in the buffer anywhere. But is you check plbuf_bop you can see the state parameters that are recorded at the beginning of each page. I have now added the dev_eofill variable to that list. I have also set the function opt_eofill to call plP_State so that if a change occurs later in the execution it will get picked up. Should you feel the need to write a plsfillrule() function then all the stuff is there so that if you just duplicated opt_eofill then all the code is there so that the buffer would catch it. Note that I have tested this up to the point of checking in the debugger that the correct fill rule is recognised by the viewer and the correct parameter is passed in to the wxWidgets fill function. This definitely works correctly both with and without -eofill specified for example 27. However I didn't spot a difference in the output. Maybe you can check it if you know how it should look > >> >> 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 <m...@gazoo.ph.utexas.edu> > To: Alan W. Irwin <ir...@beluga.phys.uvic.ca> > Cc: PLplot development list <Plplot-devel@lists.sourceforge.net> > 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. Hmm, I do think the initialisation is a bit messy, but I am unlikely to find the time soon to look at this. I think the best strategy long term would be to pass the PLStream out to the user as an opaque void *, then have them pass it back in for each API call. This would remove the global plsc variable which I think is important long term if we ever want to be intrastream thread safe but this would be a huge API change. This is the way libcurl works by the way. ------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
