From: Hezekiah M. C. <hc...@at...> - 2008-10-23 23:16:58
Attachments:
ext-cairo-test-problem.c
ext-cairo-test-workaround.c
|
I have run across a problem using the extcairo driver and multiple, differently dimensioned plots. The attached C program ext-cairo-test-problem.c is a modified version of examples/c/ext-cairo-test.c from the PLplot source tree and illustrates the problem I am having. To compile the attached code, you can use: gcc ext-cairo-test-problem.c -o ext-cairo-test-problem `pkg-config --cflags --libs plplotd cairo` and: gcc ext-cairo-test-workaround.c -o ext-cairo-test-workaround `pkg-config --cflags --libs plplotd cairo` They require that the extcairo driver is enabled. After the generated executable is run, a test.ps file is generated. For the ext-cairo-test-problem case, there are labels painted in the lower left corner of the page. For the ext-cairo-test-workaround case, new labels are superimposed over the original "x" "y" "title" labels, as expected. The basic steps to reproduce the problem: 1. Start an extcairo plot 2. Create a new plot stream with plmkstrm 3. Set the new plot stream to use extcairo and have different dimensions than the original plot started in (1) using plsetopt("geometry", "NEWXxNEWY") 4. End the new plot stream created in (2) with plend1 5. Plot something, now that PLplot is using plot (1) again as the plotting target, and see how the coordinates are calculated incorrectly. I found a workaround, illustrated in ext-cairo-test-workaround.c, which is done by adding the following steps: 4.1. Create another new stream, using the extcairo driver. 4.2. Set the new stream to have the same dimensions as the original plot started in (1). 4.3. End the new plot stream created in (4.1) with plend1. In this case, OR if the new stream created in (2) is initialized using some other plot device (ex. psc), the problem does not come up. This problem does not occur, as far as I can tell, for any other driver combinations. png + psc, psc + pscairo, extcairo + psc and other all work fine. extcairo + extcairo is where I run in to the problem. I have been digging through the PLplot code in an attempt to track down the source of this problem for a better fix than the above workaround but I have not had any luck so far. Any suggestions on how to proceed? I am using the latest PLplot SVN. Thanks, Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |
From: Hezekiah M. C. <hc...@at...> - 2008-10-23 22:48:32
Attachments:
plplot-cairo-driver-problem.ml
|
On Thu, Oct 23, 2008 at 5:22 PM, Hezekiah M. Carty <hc...@at...> wrote: > I have run across a problem using the extcairo driver and multiple, > differently dimensioned plots. The attached C program > ext-cairo-test-problem.c is a modified version of > examples/c/ext-cairo-test.c from the PLplot source tree and > illustrates the problem I am having. Apparently this is not restricted to the extcairo driver, but instead affects all Cairo plotting devices. Another test using pscairo + pngcairo shows the same issue. The attached OCaml code illustrates a similar problem with a misplaced plotted point at the last call to plploin. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |
From: Hazen B. <hba...@ma...> - 2008-10-24 03:32:53
|
On Oct 23, 2008, at 6:41 PM, Hezekiah M. Carty wrote: > On Thu, Oct 23, 2008 at 5:22 PM, Hezekiah M. Carty > <hc...@at...> wrote: >> I have run across a problem using the extcairo driver and multiple, >> differently dimensioned plots. The attached C program >> ext-cairo-test-problem.c is a modified version of >> examples/c/ext-cairo-test.c from the PLplot source tree and >> illustrates the problem I am having. > > Apparently this is not restricted to the extcairo driver, but instead > affects all Cairo plotting devices. Another test using pscairo + > pngcairo shows the same issue. The attached OCaml code illustrates a > similar problem with a misplaced plotted point at the last call to > plploin. The problem is here: static PLFLT downscale = 0.; This should be stored separately as part of each plot stream rather than being a single static global variable. -Hazen |
From: Alan W. I. <ir...@be...> - 2008-10-24 04:38:30
|
On 2008-10-23 23:28-0400 Hazen Babcock wrote: > > On Oct 23, 2008, at 6:41 PM, Hezekiah M. Carty wrote: > >> On Thu, Oct 23, 2008 at 5:22 PM, Hezekiah M. Carty >> <hc...@at...> wrote: >>> I have run across a problem using the extcairo driver and multiple, >>> differently dimensioned plots. The attached C program >>> ext-cairo-test-problem.c is a modified version of >>> examples/c/ext-cairo-test.c from the PLplot source tree and >>> illustrates the problem I am having. >> >> Apparently this is not restricted to the extcairo driver, but instead >> affects all Cairo plotting devices. Another test using pscairo + >> pngcairo shows the same issue. The attached OCaml code illustrates a >> similar problem with a misplaced plotted point at the last call to >> plploin. > > The problem is here: > > static PLFLT downscale = 0.; > > This should be stored separately as part of each plot stream rather > than being a single static global variable. Hi Hazen, The problem occurs in svg.c as well, and there may be others. When I surveyed the devices recently in preparation for my scaling work for svg.c, I found virtually all of them scale (for obvious reasons) between internal PLplot (16-bit) coordinates and device coordinates. Just look for PIXELS_X somewhere in the various device-driver source codes, i.e., software@raven> grep -l PIXELS_X * cairo.c cgm.c gd.c null.c pbm.c plmeta.c svg.c tk.c tkwin.c wingcc.c xwin.c where PIXELS_X-1 = 32767 = maximum value of internal (virtual) PLplot coordinates. This may not be a complete list since the scaling implementation may be done differently for devices not on this list. When I did my scaling work for svg.c, I followed what was done in cairo.c so the storage problem you found for cairo must also occur for svg.c as well. I am not sure about the rest of the above list. For example, gd.c stores the scaling factor in a device-specific struct, and I haven't followed the code well enough to know whether separate versions of the struct are set up for each stream or not. Anyhow, I encourage you do a quick general survey to find which devices have the scale storage problems for multiple streams and which are okay. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ |
From: Werner S. <sm...@ia...> - 2008-10-24 06:49:11
|
Hi, > > The problem is here: > > static PLFLT downscale = 0.; > > > This should be stored separately as part of each plot stream rather > than being a single static global variable. Yes, this variable needs to be moved to the PLcairo struct. A instance of this struct is saved into the dev variable of the plplot stream and then every stream has it's own downscale variable. I can fix that if nobody else does. Regards, Werner > > > > -Hazen > > > ------------------------------------------------------------------------- > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > Build the coolest Linux based applications with Moblin SDK & win > great prizes > Grand prize is a trip for two to an Open Source event anywhere in > the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel -- Dr. Werner Smekal Institut fuer Allgemeine Physik Technische Universitaet Wien Wiedner Hauptstr 8-10 A-1040 Wien Austria email: sm...@ia... web: http://www.iap.tuwien.ac.at/~smekal phone: +43-(0)1-58801-13463 (office), +43-(0)1-58801-13469 (laboratory) fax: +43-(0)1-58801-13499 |
From: Hezekiah M. C. <hc...@at...> - 2008-10-24 18:22:55
Attachments:
cairo-driver-downscale.patch
|
On Fri, Oct 24, 2008 at 2:49 AM, Werner Smekal <sm...@ia...> wrote: > Hi, > >> >> The problem is here: >> >> static PLFLT downscale = 0.; > >> >> >> This should be stored separately as part of each plot stream rather >> than being a single static global variable. > > Yes, this variable needs to be moved to the PLcairo struct. A instance of > this struct is saved into the dev variable of the plplot stream and then > every stream has it's own downscale variable. I can fix that if nobody else > does. If not one has come up with a different patch yet, the attached patch seems to fix the problem for the Cairo devices on my system. Hez -- Hezekiah M. Carty Graduate Research Assistant University of Maryland Department of Atmospheric and Oceanic Science |
From: Hazen B. <hba...@ma...> - 2008-10-25 02:21:13
|
On Oct 24, 2008, at 2:22 PM, Hezekiah M. Carty wrote: > On Fri, Oct 24, 2008 at 2:49 AM, Werner Smekal > <sm...@ia...> wrote: >> Hi, >> >>> >>> The problem is here: >>> >>> static PLFLT downscale = 0.; >> >>> >>> >>> This should be stored separately as part of each plot stream rather >>> than being a single static global variable. >> >> Yes, this variable needs to be moved to the PLcairo struct. A >> instance of >> this struct is saved into the dev variable of the plplot stream >> and then >> every stream has it's own downscale variable. I can fix that if >> nobody else >> does. > > If not one has come up with a different patch yet, the attached patch > seems to fix the problem for the Cairo devices on my system. Applied. Thanks! -Hazen |
From: Hazen B. <hba...@ma...> - 2008-10-25 02:30:51
|
On Oct 24, 2008, at 12:38 AM, Alan W. Irwin wrote: > On 2008-10-23 23:28-0400 Hazen Babcock wrote: >> > Hi Hazen, > > The problem occurs in svg.c as well, and there may be others. On closer inspection, the svg driver is pretty much riddled with this problem. You could have all kinds of strange things happen if you tried to use two or more svg streams concurrently, not the least of which would be that all your output would always go into the current stream and then it would likely crash when you closed one of the streams. I was probably being lazy when I wrote it. I will try and fix it up in the next day or two. -Hazen |
From: Hazen B. <hba...@ma...> - 2008-10-25 03:09:03
|
On Oct 24, 2008, at 10:26 PM, Hazen Babcock wrote: > > On Oct 24, 2008, at 12:38 AM, Alan W. Irwin wrote: > >> On 2008-10-23 23:28-0400 Hazen Babcock wrote: >>> >> Hi Hazen, >> >> The problem occurs in svg.c as well, and there may be others. > > On closer inspection, the svg driver is pretty much riddled with this > problem. You could have all kinds of strange things happen if you > tried to use two or more svg streams concurrently, not the least of > which would be that all your output would always go into the current > stream and then it would likely crash when you closed one of the > streams. > > I was probably being lazy when I wrote it. I will try and fix it up > in the next day or two. Ok. This was pretty straightforward if a little tedious. Tentatively this driver (rev 8965) should now be capable of dealing with multiple plotting streams simultaneously. -Hazen |
From: Alan W. I. <ir...@be...> - 2008-10-26 20:16:07
|
On 2008-10-24 23:04-0400 Hazen Babcock wrote: > > On Oct 24, 2008, at 10:26 PM, Hazen Babcock wrote: > >> On closer inspection, the svg driver is pretty much riddled with this >> problem. You could have all kinds of strange things happen if you >> tried to use two or more svg streams concurrently, not the least of >> which would be that all your output would always go into the current >> stream and then it would likely crash when you closed one of the >> streams. >> >> I was probably being lazy when I wrote it. I will try and fix it up >> in the next day or two. > > Ok. This was pretty straightforward if a little tedious. Tentatively > this driver (rev 8965) should now be capable of dealing with multiple > plotting streams simultaneously. Hi Hazen: ctest revealed a segfault for the familied files case for example 7. valgrind confirmed memory management issues whenever -fam was turned on for any multipage example (e.g., example 2). By chance, example 7 is the one that turned into a segfault. This reminded me of similar problems years ago for gd.c so I looked in the same place in the code where ordering was so important then for the way device-dependent data were handled, and I made sure svg.c followed the same order and ideas as well. Those changes (culminating in revision 8975) now lead to an absolutely clean valgrind result for example 7 (with -fam option) and example 10 (without the -fam option). Also ctest runs through all the examples without problems now for -dev svg. So it appears my fixes (which simply follow the pattern in gd.c) work. I don't claim to have a deep understanding of what is going on, however, so it would be good to review my changes. 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); PLplot scientific plotting software package (plplot.org); 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 __________________________ |