> On Sep 30, 2017, at 2:35 PM, 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. >>>
The eofill setting is saved by the plbuf at a bop (see line 176 and 359 in plbuf.c). >>> 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. I’m confused because plbuf is saving the dev_eofill setting. >>> >>> @Phil and Jim: >>> >>> I obviously must be missing something about the plbuf code, but what? >>> >> I have noticed some inconsistencies in the mash-up of plbuf and drivers when it comes to handling state and escape (e.g. plD_esc) functions. Based on my recollection of old graphics devices, I think I understand the difference (state has to do with internal plplot and escape has to do with commands to the graphic device) but with the way graphics devices have evolved we may want to revisit the implementation (e.g. make sure no settings are getting lost on a replot). The biggest weakness in plbuf is that what it thinks should be saved may not match what is needed. When working on the core and drivers, it is easy to add a bit of state and not update plbuf. There might be a way to make plbuf be more aggressive in saving state information and restoring it when replaying the buffer. I can make the aggressiveness be a setting that a driver can set it if it wants the current behavior—I am concerned that some of the older drivers might have issues. > @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 > ------------------------------------------------------------------------------ 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
