In relation to the plotting errors I'm receiving, it's not only example 25. Almost every full color fill or gradient fill is shifted 2 pixels to the right (thus this is in example 12, 25 but also example 16 seems to show this problem.

I found a way to 'reset' the stream including the background after fiddling with the order of the functions I have in the reset function. I haven't looked at memory usage yet, but I hope that when you, in the stream, use adv(0), ssub(1,1) and clear() it does not actually keep the previous plot in memory and create new memory for a new plot, even though it's plotted on the same device?


> Date: Fri, 2 Aug 2013 22:33:33 -0700
> From:
> To:
> CC:
> Subject: RE: [Plplot-devel] PLfill function shifts 2 pixels (wxwidgets)
> On 2013-08-03 13:39+1000 Joost Kuckartz wrote:
> > By executing nmake, it compiled ALL the examples.
> I was glad to hear you have had "NMake Makefiles" success. That's the
> beauty of CMake. You are allowed to pick whatever backend generator
> that fits your needs. On my Wine platform I have recently built and
> tested PLplot with the "MinGW Makefiles", "MSYS Makefiles", "Ninja",
> and "NMake Makefiles JOM" generators. The first two gave complete
> success for all languages. "Ninja" currently cannot handle anything
> other than C or C++ (but it is fine for those) and I have only tested
> C and C++ so far for "NMake Makefiles JOM".
> > No problem, I
> executed example 25 as you requested, and yes, the same issue as I've
> shown in the screenshots I've sent before occurred.
> I have recently compiled wxwidgets on the Wine platform and ran a few
> examples sucessfully (but not example 25). I will try to build that
> again in the next week or so to see whether there are misalignment
> issues for example 25 or not for that platform. And I hope the others
> here that have access to Windows and wxwidgets give example 25 a try
> to help see whether this misalignment issue is general one for
> wxwidgets on Windows.
> > So, I basically copied the examples code into wxWidgets without
> modifications, so if my code is incorrect, the code online should be
> incorrect... Maybe it is the online code that is incorrect, because
> the website hasn't been updated for quite some time. Also the website
> states an svn checkout location which only offers revisions until
> March 2013, thus missing all revisions by using the svn checkout
> location listed at the sourceforge page.
> You should be using the repository code listed at the sourceforge
> project page rather than the website code although I doubt they are
> much different. (What happened was as part of the March "Allura"
> upgrade, SourceForge froze our old repo and copied the information in
> it to a new repo at a different location with updated binary format.
> Our next release should update the code references at our website from
> the old repo to the new repo to eliminate this source of confusion.)
> Thanks for the additional information you gave about your
> wxwidgets/PLplot project, and if you happen to implement fixes for
> some of the issues of the wxwidgets device driver, we would be happy
> to accept your patches.
> Alan
> __________________________
> Alan W. Irwin
> Astronomical research affiliation with Department of Physics and Astronomy,
> University of Victoria (
> Programming affiliations with the FreeEOS equation-of-state
> implementation for stellar interiors (; the Time
> Ephemerides project (; PLplot scientific plotting
> software package (; the libLASi project
> (; the Loads of Linux Links project (;
> and the Linux Brochure Project (
> __________________________
> Linux-powered Science
> __________________________