opengrads-devel — OpenGrADS development issues, with focus on interfaces and extensions

[Opengrads-devel] Opengrads perl interface and grads2

[Diego M. V. <dv...@cl...>]

Hi *,
 Sorry for the newbie question, but is the perl interface compatible with
grads2? 

 I'm trying to install the perl interface in an Ubuntu 10.04, x86_64 linux.
I installed grads from the repositories (v2.0.a7.1), and downloaded
gerl-1.0.0 ( following the instructions in the wiki ). Everything goes right
untill the tests. Make test fails with:

Use of uninitialized value $got in split at
/home/paola/gerl-1.00/blib/lib/Grads.pm line 932.

So I installed anyway, and ran the tests one by one. The second one ( perl
t/gerl.t ) gives the following:

1..16
# Running under perl version 5.010001 for linux
# Current time local: Fri Jul 29 12:44:01 2011
# Current time GMT: Fri Jul 29 15:44:01 2011
# Using Test.pm version 1.25_02
ok 1
open2: exec of gradshdf -u -l -b failed at
/usr/local/share/perl/5.10.1/Grads.pm line 146

 And that makes me think that it's assuming grads1 for, AFAIK, gradshdf is
not available by itself in grads2 (again, newbie here, please excuse). The
wiki says it needs version 1.9.0 or later.

 Maybe it is compatible but I am making a mess supposing grads from
repositories and opengrads are compatible/almost_the_same ? And BTW, am I
wrong thinking that having grads2 makes grads1 useless?

thanks in advance,
 -- Diego.

Re: [Opengrads-devel] 9

[pedro t. <ped...@ya...>]

It’ll renew your potency completely!.. http://www.spiral1.fi/friends.links.php?egoogleId=34d3

Re: [Opengrads-devel] Opengrads perl interface?

[Arlindo da S. <da...@al...>]

On Tue, May 24, 2011 at 5:16 PM, Eric Sokolowsky
<Eri...@na...>wrote:

> Arlindo da Silva wrote:
> > On Thu, May 19, 2011 at 4:58 PM, Eric Sokolowsky
> > <Eri...@na... <mailto:Eri...@na...>> wrote:
> >
> >     Hello,
> >
> >     I have been using the opengrads perl interface for several years now.
> I
> >     recently tried to find the latest version of it on sourceforge and it
> >     seems as if it has been removed. Is this true? I find it useful, and
> I
> >     have even fixed some of its bugs, so I'd like it to be reinstated if
> >     possible so I can contribute my fixes.
> >
> >
> > No, it is still there. Take a look at:
> >
> >    http://sourceforge.net/projects/opengrads/files/perl-grads/1.00/
> >
> > Sourceforge had a recent service upgrade that required our passwords to
> > be reset. If you are using our CVS repository, make sure to logon to
> > sf.net <http://sf.net> and reset your password.
> >
> > BTW, I never made any other release beyond 1.0.0. If you have made
> > updates perhaps we should release v 1.0.1?
> >
> >   Arlindo
> >
> > --
> > Arlindo da Silva
> > da...@al... <mailto:da...@al...>
> >
>
> Ah there it is. I was looking in the wrong place. Thanks for the
> pointer. Once I get my fixes in it would probably be good to make
> another release.
>
> Is this project using SVN or still just using CVS?
>
>
CVS. If I ever change I'd probably go to mercurial or git.

   Arlindo



> Eric
>
>
> ------------------------------------------------------------------------------
> vRanger cuts backup time in half-while increasing security.
> With the market-leading solution for virtual backup and recovery,
> you get blazing-fast, flexible, and affordable data protection.
> Download your free trial now.
> http://p.sf.net/sfu/quest-d2dcopy1
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>



-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Opengrads perl interface?

[Eric S. <Eri...@na...>]

Arlindo da Silva wrote:
> On Thu, May 19, 2011 at 4:58 PM, Eric Sokolowsky 
> <Eri...@na... <mailto:Eri...@na...>> wrote:
> 
>     Hello,
> 
>     I have been using the opengrads perl interface for several years now. I
>     recently tried to find the latest version of it on sourceforge and it
>     seems as if it has been removed. Is this true? I find it useful, and I
>     have even fixed some of its bugs, so I'd like it to be reinstated if
>     possible so I can contribute my fixes.
> 
> 
> No, it is still there. Take a look at:
> 
>    http://sourceforge.net/projects/opengrads/files/perl-grads/1.00/
> 
> Sourceforge had a recent service upgrade that required our passwords to 
> be reset. If you are using our CVS repository, make sure to logon to 
> sf.net <http://sf.net> and reset your password.
> 
> BTW, I never made any other release beyond 1.0.0. If you have made 
> updates perhaps we should release v 1.0.1?
> 
>   Arlindo
>  
> -- 
> Arlindo da Silva
> da...@al... <mailto:da...@al...>
> 

Ah there it is. I was looking in the wrong place. Thanks for the 
pointer. Once I get my fixes in it would probably be good to make 
another release.

Is this project using SVN or still just using CVS?

Eric

Re: [Opengrads-devel] Opengrads perl interface?

[Sokolowsky, E. (GSFC-610.3)[G. S. & T. INC] <eri...@na...>]

Ah, I had missed that it was its own project. I will try the link you sent. Thank you.

Eric
________________________________________
From: Arlindo da Silva [da...@al...]
Sent: Saturday, May 21, 2011 2:47 PM
To: ope...@li...
Subject: Re: [Opengrads-devel] Opengrads perl interface?

On Thu, May 19, 2011 at 4:58 PM, Eric Sokolowsky <Eri...@na...<mailto:Eri...@na...>> wrote:
Hello,

I have been using the opengrads perl interface for several years now. I
recently tried to find the latest version of it on sourceforge and it
seems as if it has been removed. Is this true? I find it useful, and I
have even fixed some of its bugs, so I'd like it to be reinstated if
possible so I can contribute my fixes.


No, it is still there. Take a look at:

   http://sourceforge.net/projects/opengrads/files/perl-grads/1.00/

Sourceforge had a recent service upgrade that required our passwords to be reset. If you are using our CVS repository, make sure to logon to sf.net<http://sf.net> and reset your password.

BTW, I never made any other release beyond 1.0.0. If you have made updates perhaps we should release v 1.0.1?

  Arlindo

--
Arlindo da Silva
da...@al...<mailto:da...@al...>

Re: [Opengrads-devel] Opengrads perl interface?

[Arlindo da S. <da...@al...>]

On Thu, May 19, 2011 at 4:58 PM, Eric Sokolowsky
<Eri...@na...>wrote:

> Hello,
>
> I have been using the opengrads perl interface for several years now. I
> recently tried to find the latest version of it on sourceforge and it
> seems as if it has been removed. Is this true? I find it useful, and I
> have even fixed some of its bugs, so I'd like it to be reinstated if
> possible so I can contribute my fixes.
>
>
No, it is still there. Take a look at:

   http://sourceforge.net/projects/opengrads/files/perl-grads/1.00/

Sourceforge had a recent service upgrade that required our passwords to be
reset. If you are using our CVS repository, make sure to logon to sf.net and
reset your password.

BTW, I never made any other release beyond 1.0.0. If you have made updates
perhaps we should release v 1.0.1?

  Arlindo

-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] Opengrads perl interface?

[Eric S. <Eri...@na...>]

Hello,

I have been using the opengrads perl interface for several years now. I 
recently tried to find the latest version of it on sourceforge and it 
seems as if it has been removed. Is this true? I find it useful, and I 
have even fixed some of its bugs, so I'd like it to be reinstated if 
possible so I can contribute my fixes.

Eric Sokolowsky

Re: [Opengrads-devel] Supplibs heads up

[Arlindo da S. <da...@al...>]

Jennifer,

   Thanks for the heads up. We have been building pkgconfig & cairo for
sometime now as it is required for gxyat. So far I have not included Xrender
and the X11 surface and I'll make sure I enable it.  Updating NetCDF to
4.1.2 is an excellent idea, I'll follow your lead on that as well.

  I have not had much time to work on grads lately. On my to do list is to
develop a POSIX extension that would bring a lot of new functionality to the
scripting language. With my hectic schedule in my day job I am not sure when
I'll get around to it...

  Looking forward to your new releases.

  Cheers!

     Arlindo

On Thu, Apr 14, 2011 at 1:30 PM, Jennifer Adams <jm...@co...> wrote:

> Dear All,
>
> I have done a lot of work on the supplibs, getting ready for releases
> of 2.0.0 (really soon) and 2.1.a0 (not sure when). For 2.0.0, there
> are new versions of zlib, netcdf, hdf5, jasper, and grib2. These are
> the libs I feel it is necessary to keep up to date, to make sure we
> take advantage of performance enhancements. For 2.1 (the cairo
> release), there are 6 new ones: pkgconfig, Xrender, pixman, freetype,
> fontconfig, and cairo. I can statically link GrADS with all of these.
> The linear algebra library clapack will also be in 2.1, but I have not
> started working with it at all yet. All of my configure options and
> notes for building are in http://iges.org/grads/gadoc/supplibs.html
>
> For the cairo build, there are still a couple of outstanding issues I
> have not yet resolved:
>
> 1. The fontconfig library requires the presence of some local
> configuration files, they are generated as you build the library and
> are installed in ./etc/fonts under the directory where you install
> fontconfig. The environment variable FONTCONFIG_FILE points to the
> location of these config files. But there is a portability problem
> because the binary distributions do not include these files.
> Inconsistency between available fonts on each system the library is
> built on is going to be a headache.
>
> 2. I struggled a lot to pare down the list of libraries that cairo
> needs in order to enable only the features that are relevant for
> GrADS. For testing, I used a dynamically linked build of cairo
> installed with macports and compared performance with my own built-
> from-source version. One difference I have not yet resolved is
> painting with a pattern fill instead of a color. I have pushed that
> problem to the back of my list for the moment.
>
> I thought you might want to know where things stand. Please be aware
> that there may be some minor changes yet to come for 2.1 supplibs.
>
> --Jennifer
>
>
>
> ------------------------------------------------------------------------------
> Benefiting from Server Virtualization: Beyond Initial Workload
> Consolidation -- Increasing the use of server virtualization is a top
> priority.Virtualization can reduce costs, simplify management, and improve
> application availability and disaster protection. Learn more about boosting
> the value of server virtualization. http://p.sf.net/sfu/vmware-sfdev2dev
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>



-- 
Arlindo da Silva
da...@al...

[Opengrads-devel] Supplibs heads up

[Jennifer A. <jm...@co...>]

Dear All,

I have done a lot of work on the supplibs, getting ready for releases  
of 2.0.0 (really soon) and 2.1.a0 (not sure when). For 2.0.0, there  
are new versions of zlib, netcdf, hdf5, jasper, and grib2. These are  
the libs I feel it is necessary to keep up to date, to make sure we  
take advantage of performance enhancements. For 2.1 (the cairo  
release), there are 6 new ones: pkgconfig, Xrender, pixman, freetype,  
fontconfig, and cairo. I can statically link GrADS with all of these.  
The linear algebra library clapack will also be in 2.1, but I have not  
started working with it at all yet. All of my configure options and  
notes for building are in http://iges.org/grads/gadoc/supplibs.html

For the cairo build, there are still a couple of outstanding issues I  
have not yet resolved:

1. The fontconfig library requires the presence of some local  
configuration files, they are generated as you build the library and  
are installed in ./etc/fonts under the directory where you install  
fontconfig. The environment variable FONTCONFIG_FILE points to the  
location of these config files. But there is a portability problem  
because the binary distributions do not include these files.  
Inconsistency between available fonts on each system the library is  
built on is going to be a headache.

2. I struggled a lot to pare down the list of libraries that cairo  
needs in order to enable only the features that are relevant for  
GrADS. For testing, I used a dynamically linked build of cairo  
installed with macports and compared performance with my own built- 
from-source version. One difference I have not yet resolved is  
painting with a pattern fill instead of a color. I have pushed that  
problem to the back of my list for the moment.

I thought you might want to know where things stand. Please be aware  
that there may be some minor changes yet to come for 2.1 supplibs.

--Jennifer

Re: [Opengrads-devel] Fwd: Issues with Store-Bought v. Home-Grown builds of Cairo

[Mike F. <mfi...@gm...>]

Hi Jennifer, glad you're making good progress with cairo.  The output is very good and that won't be an issue, beyond speed, combining two images with -t and -b in printim is critical to me (like is done with your weather maps).  I'd be happy to guinea pig; I run both mac and centos  thanks

 Best /R Mike

On Jan 26, 2011, at 8:58, Jennifer Adams <jm...@co...> wrote:

> Dear All, 
> I can get a stand-alone program and GrADS to link statically with my own cairo build on my mac. I'm pretty sure I'll be able to do that on our CentOS boxes as well. That is a big relief, because it means the GrADS distribution method won't have to change. The use of cairo will be handled as an optional feature. Brian and I feel that there should always be a usable version of GrADS that will compile and link without any supplibs at all. 
> 
> As for keeping the old printim code, it will be a nuisance to rewrite it to match the new structure of the metafile buffer, and it bloats GrADS, but we can keep it around for backwards compatibility and to avoid widespread panic. I don't think there will be a high demand for printim output after a side by side comparison with the cairo equivalent. 
> 
> The new supplibs (so far) are pkg-config, pixman, fontconfig, freetype, Xrender, and cairo. They all build without too much fuss. I will update my supplibs documentation page with all my notes and configure options. I hope that will easily translate into the opengrads supplibs distribution. 
> 
>> ps: Can you explain what makes "gfast" be faster than "gslow"? Is this for PNG generation or drawing on the screen?
> 
> gfast was linked dynamically with the macports build of cairo; gslow was linked with my own build that did not use libXrender. Once I added libXrender to my own cairo build, and relinked gslow, it was the same as gfast. All tests were based on drawing to an X window. We don't yet have any cairo code in GrADS to generate image output. 
> 
> --Jennifer
> 
> On Jan 24, 2011, at 9:20 PM, Arlindo da Silva wrote:
> 
>> On Fri, Jan 21, 2011 at 12:36 PM, Jennifer Adams <jm...@co...> wrote:
>> Dear All, 
>> I just sent this message to the Cairo forum, but I am copying it here to keep you in the loop regarding my progress with Cairo, and to see if you have any suggestions for how to get me out of the weeds. 
>> 
>> Quick Comments:
>> 
>> 1)  I've been including cairo in the opengrads releases for a couple of years now and it has work reliably on all platforms, including windows and freebsd. I was a little concerned in the beginning that the growing dependency list for cairo was going to be a nightmare but so far so good.
>> 
>> 2) The current opengrads supplibs include cairo and its dependencies, although I do not do any drawing to the screen at this point. However, it would be simple to enable additional surfaces to support your new features.
>> 
>> 3) Because cairo uses pkg-config, autoconf support is rather trivial (see Patrice's email earlier on).  I also include pkg-config in the supplibs and it really helps ensure the consistency of the supplib/grads builds. It would be good if we could jointly maintain this supplib distribution.  I got nearly 500 downloads for the latest supplib release I did for 2.0.a9, so I think a lot of people appreciate this semi-binary approach: grads sources, but pre-compiled supplibs. 
>> 
>> 4) Most of the opengrads supplibs are in the form of static .a libraries as customary in grads builds. However, in the recent releases of cairo I was not able to have a portable static build across all the platforms (without having to redo the build for cairo and its dependencies). I ended up building cairo as a shared library, and relying on wrapper scripts to ensure the correct shared libraries are linked at run time. I can go over the details and rationale if you are interested, but this mechanism has also improved the robustness of the builds as missing .so are include included in the distribution. (The users have no idea that "grads" is actually a script that points to the real binary down below.)  The wrapper script is written in perl except under Windows where I use VBscript.
>> 
>>   Let me know if there is anything I can do to help.
>> 
>>      Arlindo
>> 
>> ps: Can you explain what makes "gfast" be faster than "gslow"? Is this for PNG generation or drawing on the screen?
>> 
>> 
>> 
>> 
>> 
>>  
>> --Jennifer
>> 
>> 
>> Begin forwarded message:
>> 
>>> From: Jennifer Adams <jm...@co...>
>>> Date: January 21, 2011 12:31:50 PM EST
>>> To: cairo <ca...@ca...>
>>> Subject: Issues with Store-Bought v. Home-Grown builds of Cairo 
>>> 
>>> Dear Experts, 
>>> 
>>> I apologize in advance for a long email ... I'm just trying to be thorough. The bottom line is my own build of Cairo compared with the macports/yum build is MUCH too slow, and I don't know why. 
>>> 
>>> I am working toward getting Cairo to handle all the graphics for GrADS, an open-source program for the analysis and display of meteorological data. The old way of doing graphics in GrADS was a combination of direct calls to the X11 library (for the X window interface), calls to the gd library (for image output), plus some extremely dated code to create postscript output. All text was drawn in Hershey fonts. Cairo improves on this mish-mash in so many ways; the graphics are looking absolutely fantastic, the toy font API is adequate for our needs, and I know my users are going to be very excited when they see these improvements. 
>>> 
>>> For GrADS distribution, I provide binary executables for a small set of platforms, but many users must build from source. GrADS requires a long list of supplemental libraries to fully enable all its features: the current count is 20. With the exception of X11 and a few other system libs, we link statically with all these supplibs, so that our binaries are portable (some of the supplibs GrADS needs are rather obscure.) I get the impression from browsing through the forum archives that linking statically with Cairo isn't really the right way to do it, so during my development and testing I have been linking dynamically with a macports build of Cairo. It's been fine that way, a little slower than the old way of using direct X11 calls, but not deal-breakingly slow. 
>>> 
>>> Looking forward to the time when I must put out a release, I am trying to integrate Cairo into the GrADS autoconfiguration scripts and the setup we have for building all the supplibs from source. I can't assume that all my users will have macports or yum to do the dirty work for them, so I provide a set of instructions to build the libraries from source and link them with GrADS. It is something like the end-to-end build instructions on the Cairo website. I try to keep it as simple as possible, and tailor these instructions for the specific needs of GrADS. 
>>> 
>>> Testing out my home-grown Cairo recipe, it built without any problems (specifics given below). Then I linked GrADS two ways, one with the macports build (gfast), the other with my home-grown build (gslow). More specifics on how I linked the executables and output from otool are given below. The performance difference between glsow v. gfast is astonishing. Where gfast took 1-2 seconds to draw a plot, gslow took ~100 seconds to do the same thing. I reran all these steps on our 64-bit linux server running CentOS 5.4 and got similar results. 
>>> 
>>> Thanks to earlier answers I got regarding getting cairo-trace to work, I created a huge trace file, but I'm not sure how to interpret it. It contained ~77,000 fills and ~10,000 strokes. I reran cairo-trace with the --profile option and posted it at ftp://iges.org/pub/jma/gs.89039.lzma . The output from running cairo-perf-trace on my trace file is given below. I have no idea whether the trace info is helpful. 
>>> 
>>> What I could use is some advice about linking statically v. dynamically for my binary distributions, and some guidance for how to build Cairo from source (with only as-needed features) and link it with my application so that I get the same performance as the carefully packaged, fully-enabled versions of Cairo. 
>>> 
>>> Thank you!! 
>>> --Jennifer
>>> 
>>> 
>>> 
>>> --
>>> Jennifer M. Adams
>>> IGES/COLA
>>> 4041 Powder Mill Road, Suite 302
>>> Calverton, MD 20705
>>> jm...@co...
>>> 
>>> 
>>> 
>>> OS X version 10.5.8
>>> 
>>> > uname -a
>>> Darwin Atlantic-2.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
>>> 
>>> > gcc --version
>>> i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)
>>> 
>>> 
>>> Configuration options used to build cairo from source:
>>> pkg-config-0.23
>>> (I then set the environment vars PKG_CONFIG and PKG_CONFIG_PATH to the appropriate places)
>>> pixman-0.21.2 
>>> freetype-2.4.3  --without-fsspec --without-fsref --without-ats --without-quickdraw-toolbox --without-quickdraw-carbon 
>>> fontconfig-2.8.0  --enable-libxml2 --with-freetype-config=...
>>> cairo-1.10.2 --disable-dependency-tracking \
>>> --enable-xlib=yes \
>>> --enable-xml=yes \
>>> --enable-fc=yes \
>>> --enable-ft=yes \
>>> --enable-xlib-xrender=no \
>>> --enable-xcb=no \
>>> --enable-qt=no \
>>> --enable-quartz=no \
>>> --enable-win32=no \
>>> --enable-skia=no \
>>> --enable-os2=no \
>>> --enable-beos=no \
>>> --enable-drm=no \
>>> --enable-pthread \
>>> --enable-gl=no
>>> 
>>> 
>>> Linking commands used to build gfast and gslow (relevant bits highlighed in red): 
>>> 
>>> gcc  -g -O2  -lSystemStubs -o gslow grads.o gxsubs.o gxmeta.o gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o gauser.o gasdf.o gatxt.o -L/Users/jma/supplibs/lib -lcairo -L/usr/X11R6/lib -lX11 /Users/jma/supplibs/lib/libreadline.a /Users/jma/supplibs/lib/libncurses.a  /Users/jma/supplibs/lib/libgd.a /Users/jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libgrib2c.a /Users/jma/supplibs/lib/libjasper.a /Users/jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libmfhdf.a /Users/jma/supplibs/lib/libdf.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/supplibs/lib/libnetcdf.a /Users/jma/supplibs/lib/libhdf5_hl.a /Users/jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libcurl.a  /Users/jma/supplibs/lib/libtiff.a /Users/jma/supplibs/lib/libgeotiff.a /Users/jma/supplibs/lib/libshp.a  -lm 
>>> 
>>> gcc  -g -O2  -lSystemStubs -o gfast grads.o gxsubs.o gxmeta.o gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o gauser.o gasdf.o gatxt.o -L/opt/local/lib -lcairo -lX11 /Users/jma/supplibs/lib/libreadline.a /Users/jma/supplibs/lib/libncurses.a  /Users/jma/supplibs/lib/libgd.a /Users/jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libgrib2c.a /Users/jma/supplibs/lib/libjasper.a /Users/jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libmfhdf.a /Users/jma/supplibs/lib/libdf.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/supplibs/lib/libnetcdf.a /Users/jma/supplibs/lib/libhdf5_hl.a /Users/jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libcurl.a  /Users/jma/supplibs/lib/libtiff.a /Users/jma/supplibs/lib/libgeotiff.a /Users/jma/supplibs/lib/libshp.a  -lm 
>>> 
>>> 
>>> > otool -L gslow
>>> gslow:
>>>         /Users/jma/supplibs/src/cairo/lib/libcairo.2.dylib (compatibility version 11003.0.0, current version 11003.2.0)
>>>         /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current version 9.0.0)
>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.5)
>>>         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
>>> > otool -L gfast
>>> gfast:
>>>         /opt/local/lib/libcairo.2.dylib (compatibility version 11003.0.0, current version 11003.0.0)
>>>         /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
>>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.5)
>>>         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
>>> 
>>> 
>>> > cairo-perf-trace gg.88743.trace
>>> [ # ]  backend                         test   min(s) median(s) stddev. count
>>> [ # ]    image: pixman 0.21.2
>>> [  0]    image                           gg    0.691    0.696   0.30%    6/6
>>> [ # ]  image16: pixman 0.21.2
>>> [  0]  image16                           gg    0.692    0.696   0.21%    6/6
>>> 
>>> 
>> 
>> 
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
>> February 28th, so secure your free ArcSight Logger TODAY!
>> http://p.sf.net/sfu/arcsight-sfd2d
>> _______________________________________________
>> Opengrads-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>> 
>> 
>> 
>> 
>> -- 
>> Arlindo da Silva
>> da...@al...
>> ------------------------------------------------------------------------------
>> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
>> Finally, a world-class log management solution at an even better price-free!
>> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
>> February 28th, so secure your free ArcSight Logger TODAY! 
>> http://p.sf.net/sfu/arcsight-sfd2d_______________________________________________
>> Opengrads-devel mailing list
>> Ope...@li...
>> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
> 
> --
> Jennifer M. Adams
> IGES/COLA
> 4041 Powder Mill Road, Suite 302
> Calverton, MD 20705
> jm...@co...
> 
> 
> 
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires 
> February 28th, so secure your free ArcSight Logger TODAY! 
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel

Re: [Opengrads-devel] Fwd: Issues with Store-Bought v. Home-Grown builds of Cairo

[Jennifer A. <jm...@co...>]

Dear All,
I can get a stand-alone program and GrADS to link statically with my  
own cairo build on my mac. I'm pretty sure I'll be able to do that on  
our CentOS boxes as well. That is a big relief, because it means the  
GrADS distribution method won't have to change. The use of cairo will  
be handled as an optional feature. Brian and I feel that there should  
always be a usable version of GrADS that will compile and link without  
any supplibs at all.

As for keeping the old printim code, it will be a nuisance to rewrite  
it to match the new structure of the metafile buffer, and it bloats  
GrADS, but we can keep it around for backwards compatibility and to  
avoid widespread panic. I don't think there will be a high demand for  
printim output after a side by side comparison with the cairo  
equivalent.

The new supplibs (so far) are pkg-config, pixman, fontconfig,  
freetype, Xrender, and cairo. They all build without too much fuss. I  
will update my supplibs documentation page with all my notes and  
configure options. I hope that will easily translate into the  
opengrads supplibs distribution.

> ps: Can you explain what makes "gfast" be faster than "gslow"? Is  
> this for PNG generation or drawing on the screen?

gfast was linked dynamically with the macports build of cairo; gslow  
was linked with my own build that did not use libXrender. Once I added  
libXrender to my own cairo build, and relinked gslow, it was the same  
as gfast. All tests were based on drawing to an X window. We don't yet  
have any cairo code in GrADS to generate image output.

--Jennifer

On Jan 24, 2011, at 9:20 PM, Arlindo da Silva wrote:

> On Fri, Jan 21, 2011 at 12:36 PM, Jennifer Adams <jm...@co...>  
> wrote:
> Dear All,
> I just sent this message to the Cairo forum, but I am copying it  
> here to keep you in the loop regarding my progress with Cairo, and  
> to see if you have any suggestions for how to get me out of the weeds.
>
> Quick Comments:
>
> 1)  I've been including cairo in the opengrads releases for a couple  
> of years now and it has work reliably on all platforms, including  
> windows and freebsd. I was a little concerned in the beginning that  
> the growing dependency list for cairo was going to be a nightmare  
> but so far so good.
>
> 2) The current opengrads supplibs include cairo and its  
> dependencies, although I do not do any drawing to the screen at this  
> point. However, it would be simple to enable additional surfaces to  
> support your new features.
>
> 3) Because cairo uses pkg-config, autoconf support is rather trivial  
> (see Patrice's email earlier on).  I also include pkg-config in the  
> supplibs and it really helps ensure the consistency of the supplib/ 
> grads builds. It would be good if we could jointly maintain this  
> supplib distribution.  I got nearly 500 downloads for the latest  
> supplib release I did for 2.0.a9, so I think a lot of people  
> appreciate this semi-binary approach: grads sources, but pre- 
> compiled supplibs.
>
> 4) Most of the opengrads supplibs are in the form of static .a  
> libraries as customary in grads builds. However, in the recent  
> releases of cairo I was not able to have a portable static build  
> across all the platforms (without having to redo the build for cairo  
> and its dependencies). I ended up building cairo as a shared  
> library, and relying on wrapper scripts to ensure the correct shared  
> libraries are linked at run time. I can go over the details and  
> rationale if you are interested, but this mechanism has also  
> improved the robustness of the builds as missing .so are include  
> included in the distribution. (The users have no idea that "grads"  
> is actually a script that points to the real binary down below.)   
> The wrapper script is written in perl except under Windows where I  
> use VBscript.
>
>   Let me know if there is anything I can do to help.
>
>      Arlindo
>
> ps: Can you explain what makes "gfast" be faster than "gslow"? Is  
> this for PNG generation or drawing on the screen?
>
>
>
>
>
>
> --Jennifer
>
>
> Begin forwarded message:
>
>> From: Jennifer Adams <jm...@co...>
>> Date: January 21, 2011 12:31:50 PM EST
>> To: cairo <ca...@ca...>
>> Subject: Issues with Store-Bought v. Home-Grown builds of Cairo
>>
>> Dear Experts,
>>
>> I apologize in advance for a long email ... I'm just trying to be  
>> thorough. The bottom line is my own build of Cairo compared with  
>> the macports/yum build is MUCH too slow, and I don't know why.
>>
>> I am working toward getting Cairo to handle all the graphics for  
>> GrADS, an open-source program for the analysis and display of  
>> meteorological data. The old way of doing graphics in GrADS was a  
>> combination of direct calls to the X11 library (for the X window  
>> interface), calls to the gd library (for image output), plus some  
>> extremely dated code to create postscript output. All text was  
>> drawn in Hershey fonts. Cairo improves on this mish-mash in so many  
>> ways; the graphics are looking absolutely fantastic, the toy font  
>> API is adequate for our needs, and I know my users are going to be  
>> very excited when they see these improvements.
>>
>> For GrADS distribution, I provide binary executables for a small  
>> set of platforms, but many users must build from source. GrADS  
>> requires a long list of supplemental libraries to fully enable all  
>> its features: the current count is 20. With the exception of X11  
>> and a few other system libs, we link statically with all these  
>> supplibs, so that our binaries are portable (some of the supplibs  
>> GrADS needs are rather obscure.) I get the impression from browsing  
>> through the forum archives that linking statically with Cairo isn't  
>> really the right way to do it, so during my development and testing  
>> I have been linking dynamically with a macports build of Cairo.  
>> It's been fine that way, a little slower than the old way of using  
>> direct X11 calls, but not deal-breakingly slow.
>>
>> Looking forward to the time when I must put out a release, I am  
>> trying to integrate Cairo into the GrADS autoconfiguration scripts  
>> and the setup we have for building all the supplibs from source. I  
>> can't assume that all my users will have macports or yum to do the  
>> dirty work for them, so I provide a set of instructions to build  
>> the libraries from source and link them with GrADS. It is something  
>> like the end-to-end build instructions on the Cairo website. I try  
>> to keep it as simple as possible, and tailor these instructions for  
>> the specific needs of GrADS.
>>
>> Testing out my home-grown Cairo recipe, it built without any  
>> problems (specifics given below). Then I linked GrADS two ways, one  
>> with the macports build (gfast), the other with my home-grown build  
>> (gslow). More specifics on how I linked the executables and output  
>> from otool are given below. The performance difference between  
>> glsow v. gfast is astonishing. Where gfast took 1-2 seconds to draw  
>> a plot, gslow took ~100 seconds to do the same thing. I reran all  
>> these steps on our 64-bit linux server running CentOS 5.4 and got  
>> similar results.
>>
>> Thanks to earlier answers I got regarding getting cairo-trace to  
>> work, I created a huge trace file, but I'm not sure how to  
>> interpret it. It contained ~77,000 fills and ~10,000 strokes. I  
>> reran cairo-trace with the --profile option and posted it at ftp://iges.org/pub/jma/gs.89039.lzma 
>>  . The output from running cairo-perf-trace on my trace file is  
>> given below. I have no idea whether the trace info is helpful.
>>
>> What I could use is some advice about linking statically v.  
>> dynamically for my binary distributions, and some guidance for how  
>> to build Cairo from source (with only as-needed features) and link  
>> it with my application so that I get the same performance as the  
>> carefully packaged, fully-enabled versions of Cairo.
>>
>> Thank you!!
>> --Jennifer
>>
>>
>>
>> --
>> Jennifer M. Adams
>> IGES/COLA
>> 4041 Powder Mill Road, Suite 302
>> Calverton, MD 20705
>> jm...@co...
>>
>>
>>
>> OS X version 10.5.8
>>
>> > uname -a
>> Darwin Atlantic-2.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul  
>> 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
>>
>> > gcc --version
>> i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)
>>
>>
>> Configuration options used to build cairo from source:
>> pkg-config-0.23
>> (I then set the environment vars PKG_CONFIG and PKG_CONFIG_PATH to  
>> the appropriate places)
>> pixman-0.21.2
>> freetype-2.4.3  --without-fsspec --without-fsref --without-ats -- 
>> without-quickdraw-toolbox --without-quickdraw-carbon
>> fontconfig-2.8.0  --enable-libxml2 --with-freetype-config=...
>> cairo-1.10.2 --disable-dependency-tracking \
>> --enable-xlib=yes \
>> --enable-xml=yes \
>> --enable-fc=yes \
>> --enable-ft=yes \
>> --enable-xlib-xrender=no \
>> --enable-xcb=no \
>> --enable-qt=no \
>> --enable-quartz=no \
>> --enable-win32=no \
>> --enable-skia=no \
>> --enable-os2=no \
>> --enable-beos=no \
>> --enable-drm=no \
>> --enable-pthread \
>> --enable-gl=no
>>
>>
>> Linking commands used to build gfast and gslow (relevant bits  
>> highlighed in red):
>>
>> gcc  -g -O2  -lSystemStubs -o gslow grads.o gxsubs.o gxmeta.o  
>> gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o  
>> gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o  
>> gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o  
>> gauser.o gasdf.o gatxt.o -L/Users/jma/supplibs/lib -lcairo -L/usr/ 
>> X11R6/lib -lX11 /Users/jma/supplibs/lib/libreadline.a /Users/jma/ 
>> supplibs/lib/libncurses.a  /Users/jma/supplibs/lib/libgd.a /Users/ 
>> jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a /Users/ 
>> jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libgrib2c.a / 
>> Users/jma/supplibs/lib/libjasper.a /Users/jma/supplibs/lib/ 
>> libpng12.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/ 
>> libmfhdf.a /Users/jma/supplibs/lib/libdf.a /Users/jma/supplibs/lib/ 
>> libudunits.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/ 
>> lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/ 
>> lib/libhdf5.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/ 
>> lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/ 
>> lib/libudunits.a /Users/jma/supplibs/lib/libnetcdf.a /Users/jma/ 
>> supplibs/lib/libhdf5_hl.a /Users/jma/supplibs/lib/libhdf5.a /Users/ 
>> jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libsz.a /Users/jma/ 
>> supplibs/lib/libcurl.a  /Users/jma/supplibs/lib/libtiff.a /Users/ 
>> jma/supplibs/lib/libgeotiff.a /Users/jma/supplibs/lib/libshp.a  -lm
>>
>> gcc  -g -O2  -lSystemStubs -o gfast grads.o gxsubs.o gxmeta.o  
>> gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o  
>> gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o  
>> gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o  
>> gauser.o gasdf.o gatxt.o -L/opt/local/lib -lcairo -lX11 /Users/jma/ 
>> supplibs/lib/libreadline.a /Users/jma/supplibs/lib/libncurses.a  / 
>> Users/jma/supplibs/lib/libgd.a /Users/jma/supplibs/lib/libpng12.a / 
>> Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libjpeg.a / 
>> Users/jma/supplibs/lib/libgrib2c.a /Users/jma/supplibs/lib/ 
>> libjasper.a /Users/jma/supplibs/lib/libpng12.a /Users/jma/supplibs/ 
>> lib/libz.a /Users/jma/supplibs/lib/libmfhdf.a /Users/jma/supplibs/ 
>> lib/libdf.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/ 
>> supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/ 
>> supplibs/lib/libz.a /Users/jma/supplibs/lib/libhdf5.a /Users/jma/ 
>> supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/ 
>> supplibs/lib/libz.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/ 
>> supplibs/lib/libnetcdf.a /Users/jma/supplibs/lib/libhdf5_hl.a / 
>> Users/jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libz.a / 
>> Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libcurl.a  / 
>> Users/jma/supplibs/lib/libtiff.a /Users/jma/supplibs/lib/ 
>> libgeotiff.a /Users/jma/supplibs/lib/libshp.a  -lm
>>
>>
>> > otool -L gslow
>> gslow:
>>         /Users/jma/supplibs/src/cairo/lib/libcairo.2.dylib  
>> (compatibility version 11003.0.0, current version 11003.2.0)
>>         /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0,  
>> current version 9.0.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
>> current version 111.1.5)
>>         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,  
>> current version 1.0.0)
>> > otool -L gfast
>> gfast:
>>         /opt/local/lib/libcairo.2.dylib (compatibility version  
>> 11003.0.0, current version 11003.0.0)
>>         /opt/local/lib/libX11.6.dylib (compatibility version  
>> 10.0.0, current version 10.0.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
>> current version 111.1.5)
>>         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,  
>> current version 1.0.0)
>>
>>
>> > cairo-perf-trace gg.88743.trace
>> [ # ]  backend                         test   min(s) median(s)  
>> stddev. count
>> [ # ]    image: pixman 0.21.2
>> [  0]    image                           gg    0.691    0.696    
>> 0.30%    6/6
>> [ # ]  image16: pixman 0.21.2
>> [  0]  image16                           gg    0.692    0.696    
>> 0.21%    6/6
>>
>>
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better  
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>
>
>
>
> -- 
> Arlindo da Silva
> da...@al...
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better  
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d_______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel

--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...

[Opengrads-devel] GrADS Downloads at SF by Country

[Arlindo da S. <da...@al...>]

All,

  Here what is SourceForge reports as the GrADS v2 download breakdown by
country:

1) For Linux/Unix:

http://sourceforge.net/projects/opengrads/files/grads2/stats/map?dates=2006-03-06%20to%202011-01-24

<http://sourceforge.net/projects/opengrads/files/grads2/stats/map?dates=2006-03-06%20to%202011-01-24>2)
For Windows:

http://sourceforge.net/projects/opengrads/files/grads2-windows/stats/map?dates=2006-03-06%20to%202011-01-24


I never realized GrADS was so popular in China. It is also very popular in
Brazil.

Brian, Jennifer: do the COLA web stats show similar breakdown?

    Arlindo
<http://sourceforge.net/projects/opengrads/files/grads2-windows/stats/map?dates=2006-03-06%20to%202011-01-24>

-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Fwd: Issues with Store-Bought v. Home-Grown builds of Cairo

[Arlindo da S. <da...@al...>]

On Sun, Jan 23, 2011 at 1:11 PM, Mike Fiorino <mfi...@gm...> wrote:

> hi Brian,
>
> of course performance is critical to me too; i use printim for my
> production, mainly because i do layers (-t and -b).  i use gxyat on
> occasion and it is slower (uses Cairo?)


Yep, cairo.


> but the graphics better (but
> bigger)


There is a trick to make the files smaller. The reason is that anti-aliasing
requires 32-bit graphics but once the image is rendered you can quantize it
down to 8-bits (as in printim). By piping to the included "pngquant" utility
(gxyat -o "|pngquant 256> myfile.png") you get a much smaller file with
negligible loss in quality.


> and -t


Transparency in gxyat is actually a lot more flexible as you can define an
alpha channel for each color...


> and -b don't work.


Yes, I never got around to implementing this...


>  so for production, it'd be important
> for me to have the fast gd printim.
>

I second that, although at GMAO we do use gxyat for production. I don't
remember the performance penalty being that prohibitive. It would be good to
benchmark gxyat vs printim. I was not aware the performance is system
dependent as pointed out by Brian.


> thanks /r mike
>
> p.s. are any of you in seattle for the ams?  i'm giving a talk in the
> python symposium about my wxmaps and how i use grads.py to give grads an
> oop interface
>
>
Sorry to miss your talk but I am skipping the AMS this year, just too busy
around here. I've been slowing evolving pygrads, not too many features of
lately. Next on my list is to add volumetric visualization through MayaVi,
the so-called gaya.py.

           Arlindo


>
>
> On 1/22/11 1:45 PM, Brian Doty wrote:
> > Hi Gary, performance is a high priority. We depend on grads'
> > performance in many ways. So we plan on maintaining a "native" X
> > interface, similar to what exists in grads now. None of the new
> > functionality would be available when the "native" interface is being
> > used. But the performance should be essentially the same as is the
> > case currently.
> >
> > Do you do all your graphics through X? Or do you also use printim?
> > We are currently planning to drop the GD library in favor of Cairo for
> > image production, and that would be a loss of performance. We gain
> > anti-aliasing, raster fonts, and transparency. We are not sure as yet
> > of the performance implications; if significant we may need to keep
> > the GD interface around. We are still figuring these things out.
> > Unfortunately we are finding that Cairo performance characteristics
> > are platform dependent.... Brian
> >
> > On Jan 22, 2011, at 4:01 AM, Love, Mr. Gary, Contractor, Code 7542
> > wrote:
> >
> >> Hi Jennifer,
> >>
> >> I like the sound of improved graphics, but even gfast will not be
> >> fast enough. The current X11 library version generates a plot in
> >> 200-300 milliseconds, 5 times faster. GrADS' current speed is one
> >> of its best features which has always been very important to NRL and
> >> FNMOC, since our post processing for just one project already takes
> >> 30 minutes because so many plots are needed.
> >>
> >> I hope newer versions of GrADS can still be compiled with the X11
> >> libs.
> >>
> >> Gary
> >>
> >> From: Jennifer Adams [mailto:jm...@co...]
> >> Sent: Friday, January 21, 2011 9:36 AM
> >> To: ope...@li...
> >> Cc: Brian Doty
> >> Subject: [Opengrads-devel] Fwd: Issues with Store-Bought v. Home-
> >> Grown builds of Cairo
> >>
> >> Dear All,
> >> I just sent this message to the Cairo forum, but I am copying it
> >> here to keep you in the loop regarding my progress with Cairo, and
> >> to see if you have any suggestions for how to get me out of the weeds.
> >> --Jennifer
> >>
> >>
> >> Begin forwarded message:
> >>
> >>> From: Jennifer Adams <jm...@co...>
> >>> Date: January 21, 2011 12:31:50 PM EST
> >>> To: cairo <ca...@ca...>
> >>> Subject: Issues with Store-Bought v. Home-Grown builds of Cairo
> >>>
> >>> Dear Experts,
> >>>
> >>> I apologize in advance for a long email ... I'm just trying to be
> >>> thorough. The bottom line is my own build of Cairo compared with
> >>> the macports/yum build is MUCH too slow, and I don't know why.
> >>>
> >>> I am working toward getting Cairo to handle all the graphics for
> >>> GrADS, an open-source program for the analysis and display of
> >>> meteorological data. The old way of doing graphics in GrADS was a
> >>> combination of direct calls to the X11 library (for the X window
> >>> interface), calls to the gd library (for image output), plus some
> >>> extremely dated code to create postscript output. All text was
> >>> drawn in Hershey fonts. Cairo improves on this mish-mash in so many
> >>> ways; the graphics are looking absolutely fantastic, the toy font
> >>> API is adequate for our needs, and I know my users are going to be
> >>> very excited when they see these improvements.
> >>>
> >>> For GrADS distribution, I provide binary executables for a small
> >>> set of platforms, but many users must build from source. GrADS
> >>> requires a long list of supplemental libraries to fully enable all
> >>> its features: the current count is 20. With the exception of X11
> >>> and a few other system libs, we link statically with all these
> >>> supplibs, so that our binaries are portable (some of the supplibs
> >>> GrADS needs are rather obscure.) I get the impression from browsing
> >>> through the forum archives that linking statically with Cairo isn't
> >>> really the right way to do it, so during my development and testing
> >>> I have been linking dynamically with a macports build of Cairo.
> >>> It's been fine that way, a little slower than the old way of using
> >>> direct X11 calls, but not deal-breakingly slow.
> >>>
> >>> Looking forward to the time when I must put out a release, I am
> >>> trying to integrate Cairo into the GrADS autoconfiguration scripts
> >>> and the setup we have for building all the supplibs from source. I
> >>> can't assume that all my users will have macports or yum to do the
> >>> dirty work for them, so I provide a set of instructions to build
> >>> the libraries from source and link them with GrADS. It is something
> >>> like the end-to-end build instructions on the Cairo website. I try
> >>> to keep it as simple as possible, and tailor these instructions for
> >>> the specific needs of GrADS.
> >>>
> >>> Testing out my home-grown Cairo recipe, it built without any
> >>> problems (specifics given below). Then I linked GrADS two ways, one
> >>> with the macports build (gfast), the other with my home-grown build
> >>> (gslow). More specifics on how I linked the executables and output
> >>> from otool are given below. The performance difference between
> >>> glsow v. gfast is astonishing. Where gfast took 1-2 seconds to draw
> >>> a plot, gslow took ~100 seconds to do the same thing. I reran all
> >>> these steps on our 64-bit linux server running CentOS 5.4 and got
> >>> similar results.
> >>>
> >>> Thanks to earlier answers I got regarding getting cairo-trace to
> >>> work, I created a huge trace file, but I'm not sure how to
> >>> interpret it. It contained ~77,000 fills and ~10,000 strokes. I
> >>> reran cairo-trace with the --profile option and posted it at
> ftp://iges.org/pub/jma/gs.89039.lzma
> >>> . The output from running cairo-perf-trace on my trace file is
> >>> given below. I have no idea whether the trace info is helpful.
> >>>
> >>> What I could use is some advice about linking statically v.
> >>> dynamically for my binary distributions, and some guidance for how
> >>> to build Cairo from source (with only as-needed features) and
> >>> link it with my application so that I get the same performance as
> >>> the carefully packaged, fully-enabled versions of Cairo.
> >>>
> >>> Thank you!!
> >>> --Jennifer
> >>>
> >>>
> >>>
> >>> --
> >>> Jennifer M. Adams
> >>> IGES/COLA
> >>> 4041 Powder Mill Road, Suite 302
> >>> Calverton, MD 20705
> >>> jm...@co...
> >>>
> >>>
> >>>
> >>> OS X version 10.5.8
> >>>
> >>>> uname -a
> >>> Darwin Atlantic-2.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul
> >>> 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
> >>>
> >>>> gcc --version
> >>> i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)
> >>>
> >>>
> >>> Configuration options used to build cairo from source:
> >>> pkg-config-0.23
> >>> (I then set the environment vars PKG_CONFIG and PKG_CONFIG_PATH to
> >>> the appropriate places)
> >>> pixman-0.21.2
> >>> freetype-2.4.3 --without-fsspec --without-fsref --without-ats --
> >>> without-quickdraw-toolbox --without-quickdraw-carbon
> >>> fontconfig-2.8.0 --enable-libxml2 --with-freetype-config=...
> >>> cairo-1.10.2 --disable-dependency-tracking \
> >>> --enable-xlib=yes \
> >>> --enable-xml=yes \
> >>> --enable-fc=yes \
> >>> --enable-ft=yes \
> >>> --enable-xlib-xrender=no \
> >>> --enable-xcb=no \
> >>> --enable-qt=no \
> >>> --enable-quartz=no \
> >>> --enable-win32=no \
> >>> --enable-skia=no \
> >>> --enable-os2=no \
> >>> --enable-beos=no \
> >>> --enable-drm=no \
> >>> --enable-pthread \
> >>> --enable-gl=no
> >>>
> >>>
> >>> Linking commands used to build gfast and gslow (relevant bits
> >>> highlighed in red):
> >>>
> >>> gcc -g -O2 -lSystemStubs -o gslow grads.o gxsubs.o gxmeta.o
> >>> gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o
> >>> gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o
> >>> gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o
> >>> gauser.o gasdf.o gatxt.o -L/Users/jma/supplibs/lib -lcairo -L/usr/
> >>> X11R6/lib -lX11 /Users/jma/supplibs/lib/libreadline.a /Users/jma/
> >>> supplibs/lib/libncurses.a /Users/jma/supplibs/lib/libgd.a /Users/
> >>> jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a /Users/
> >>> jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libgrib2c.a /
> >>> Users/jma/supplibs/lib/libjasper.a /Users/jma/supplibs/lib/
> >>> libpng12.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/
> >>> libmfhdf.a /Users/jma/supplibs/lib/libdf.a /Users/jma/supplibs/lib/
> >>> libudunits.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/
> >>> lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/
> >>> lib/libhdf5.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/
> >>> lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/
> >>> lib/libudunits.a /Users/jma/supplibs/lib/libnetcdf.a /Users/jma/
> >>> supplibs/lib/libhdf5_hl.a /Users/jma/supplibs/lib/libhdf5.a /Users/
> >>> jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libsz.a /Users/jma/
> >>> supplibs/lib/libcurl.a /Users/jma/supplibs/lib/libtiff.a /Users/
> >>> jma/supplibs/lib/libgeotiff.a /Users/jma/supplibs/lib/libshp.a -lm
> >>>
> >>> gcc -g -O2 -lSystemStubs -o gfast grads.o gxsubs.o gxmeta.o
> >>> gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o
> >>> gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o
> >>> gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o
> >>> gauser.o gasdf.o gatxt.o -L/opt/local/lib -lcairo -lX11 /Users/jma/
> >>> supplibs/lib/libreadline.a /Users/jma/supplibs/lib/libncurses.a /
> >>> Users/jma/supplibs/lib/libgd.a /Users/jma/supplibs/lib/libpng12.a /
> >>> Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libjpeg.a /
> >>> Users/jma/supplibs/lib/libgrib2c.a /Users/jma/supplibs/lib/
> >>> libjasper.a /Users/jma/supplibs/lib/libpng12.a /Users/jma/supplibs/
> >>> lib/libz.a /Users/jma/supplibs/lib/libmfhdf.a /Users/jma/supplibs/
> >>> lib/libdf.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/
> >>> supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/
> >>> supplibs/lib/libz.a /Users/jma/supplibs/lib/libhdf5.a /Users/jma/
> >>> supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/
> >>> supplibs/lib/libz.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/
> >>> supplibs/lib/libnetcdf.a /Users/jma/supplibs/lib/libhdf5_hl.a /
> >>> Users/jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libz.a /
> >>> Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libcurl.a /
> >>> Users/jma/supplibs/lib/libtiff.a /Users/jma/supplibs/lib/
> >>> libgeotiff.a /Users/jma/supplibs/lib/libshp.a -lm
> >>>
> >>>
> >>>> otool -L gslow
> >>> gslow:
> >>> /Users/jma/supplibs/src/cairo/lib/libcairo.2.dylib
> >>> (compatibility version 11003.0.0, current version 11003.2.0)
> >>> /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0,
> >>> current version 9.0.0)
> >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
> >>> current version 111.1.5)
> >>> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
> >>> current version 1.0.0)
> >>>> otool -L gfast
> >>> gfast:
> >>> /opt/local/lib/libcairo.2.dylib (compatibility version
> >>> 11003.0.0, current version 11003.0.0)
> >>> /opt/local/lib/libX11.6.dylib (compatibility version
> >>> 10.0.0, current version 10.0.0)
> >>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
> >>> current version 111.1.5)
> >>> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
> >>> current version 1.0.0)
> >>>
> >>>
> >>>> cairo-perf-trace gg.88743.trace
> >>> [ # ] backend test min(s) median(s)
> >>> stddev. count
> >>> [ # ] image: pixman 0.21.2
> >>> [ 0] image gg 0.691 0.696
> >>> 0.30% 6/6
> >>> [ # ] image16: pixman 0.21.2
> >>> [ 0] image16 gg 0.692 0.696
> >>> 0.21% 6/6
> >>>
> >>>
> >>
> >
> >
> >
> ------------------------------------------------------------------------------
> > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> > Finally, a world-class log management solution at an even better
> price-free!
> > Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> > February 28th, so secure your free ArcSight Logger TODAY!
> > http://p.sf.net/sfu/arcsight-sfd2d
> > _______________________________________________
> > Opengrads-devel mailing list
> > Ope...@li...
> > https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>



-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Fwd: Issues with Store-Bought v. Home-Grown builds of Cairo

[Arlindo da S. <da...@al...>]

On Fri, Jan 21, 2011 at 12:36 PM, Jennifer Adams <jm...@co...> wrote:

> Dear All,
> I just sent this message to the Cairo forum, but I am copying it here to
> keep you in the loop regarding my progress with Cairo, and to see if you
> have any suggestions for how to get me out of the weeds.
>

Quick Comments:

1)  I've been including cairo in the opengrads releases for a couple of
years now and it has work reliably on all platforms, including windows and
freebsd. I was a little concerned in the beginning that the growing
dependency list for cairo was going to be a nightmare but so far so good.

2) The current opengrads supplibs include cairo and its dependencies,
although I do not do any drawing to the screen at this point. However, it
would be simple to enable additional surfaces to support your new features.

3) Because cairo uses pkg-config, autoconf support is rather trivial (see
Patrice's email earlier on).  I also include pkg-config in the supplibs and
it really helps ensure the consistency of the supplib/grads builds. It would
be good if we could jointly maintain this supplib distribution.  I got
nearly 500 downloads for the latest supplib release I did for 2.0.a9, so I
think a lot of people appreciate this semi-binary approach: grads sources,
but pre-compiled supplibs.

4) Most of the opengrads supplibs are in the form of static .a libraries as
customary in grads builds. However, in the recent releases of cairo I was
not able to have a portable static build across all the platforms (without
having to redo the build for cairo and its dependencies). I ended up
building cairo as a shared library, and relying on wrapper scripts to ensure
the correct shared libraries are linked at run time. I can go over the
details and rationale if you are interested, but this mechanism has also
improved the robustness of the builds as missing .so are include included in
the distribution. (The users have no idea that "grads" is actually a script
that points to the real binary down below.)  The wrapper script is written
in perl except under Windows where I use VBscript.

  Let me know if there is anything I can do to help.

     Arlindo

ps: Can you explain what makes "gfast" be faster than "gslow"? Is this for
PNG generation or drawing on the screen?







> --Jennifer
>
>
> Begin forwarded message:
>
> *From: *Jennifer Adams <jm...@co...>
> *Date: *January 21, 2011 12:31:50 PM EST
> *To: *cairo <ca...@ca...>
> *Subject: **Issues with Store-Bought v. Home-Grown builds of Cairo *
>
> Dear Experts,
>
> I apologize in advance for a long email ... I'm just trying to be thorough.
> The bottom line is my own build of Cairo compared with the macports/yum
> build is MUCH too slow, and I don't know why.
>
> I am working toward getting Cairo to handle all the graphics for GrADS, an
> open-source program for the analysis and display of meteorological data. The
> old way of doing graphics in GrADS was a combination of direct calls to the
> X11 library (for the X window interface), calls to the gd library (for image
> output), plus some extremely dated code to create postscript output. All
> text was drawn in Hershey fonts. Cairo improves on this mish-mash in so many
> ways; the graphics are looking absolutely fantastic, the toy font API is
> adequate for our needs, and I know my users are going to be very excited
> when they see these improvements.
>
> For GrADS distribution, I provide binary executables for a small set of
> platforms, but many users must build from source. GrADS requires a long list
> of supplemental libraries to fully enable all its features: the current
> count is 20. With the exception of X11 and a few other system libs, we link
> statically with all these supplibs, so that our binaries are portable (some
> of the supplibs GrADS needs are rather obscure.) I get the impression from
> browsing through the forum archives that linking statically with Cairo isn't
> really the right way to do it, so during my development and testing I have
> been linking dynamically with a macports build of Cairo. It's been fine that
> way, a little slower than the old way of using direct X11 calls, but not
> deal-breakingly slow.
>
> Looking forward to the time when I must put out a release, I am trying to
> integrate Cairo into the GrADS autoconfiguration scripts and the setup we
> have for building all the supplibs from source. I can't assume that all my
> users will have macports or yum to do the dirty work for them, so I provide
> a set of instructions to build the libraries from source and link them with
> GrADS. It is something like the end-to-end build instructions on the Cairo
> website. I try to keep it as simple as possible, and tailor these
> instructions for the specific needs of GrADS.
>
> Testing out my home-grown Cairo recipe, it built without any problems
> (specifics given below). Then I linked GrADS two ways, one with the macports
> build (gfast), the other with my home-grown build (gslow). More specifics on
> how I linked the executables and output from otool are given below. The
> performance difference between glsow v. gfast is astonishing. Where gfast
> took 1-2 seconds to draw a plot, gslow took ~100 seconds to do the same
> thing. I reran all these steps on our 64-bit linux server running CentOS 5.4
> and got similar results.
>
> Thanks to earlier answers I got regarding getting cairo-trace to work, I
> created a huge trace file, but I'm not sure how to interpret it. It
> contained ~77,000 fills and ~10,000 strokes. I reran cairo-trace with the
> --profile option and posted it at ftp://iges.org/pub/jma/gs.89039.lzma .
> The output from running cairo-perf-trace on my trace file is given below. I
> have no idea whether the trace info is helpful.
>
> What I could use is some advice about linking statically v. dynamically for
> my binary distributions, and some guidance for how to build Cairo from
> source (with only as-needed features) and link it with my application so
> that I get the same performance as the carefully packaged, fully-enabled
> versions of Cairo.
>
> Thank you!!
> --Jennifer
>
>
>
> --
> Jennifer M. Adams
> IGES/COLA
> 4041 Powder Mill Road, Suite 302
> Calverton, MD 20705
> jm...@co...
>
>
>
> OS X version 10.5.8
>
> > uname -a
> Darwin Atlantic-2.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15
> 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
>
> > gcc --version
> i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)
>
>
> Configuration options used to build cairo from source:
> pkg-config-0.23
> (I then set the environment vars PKG_CONFIG and PKG_CONFIG_PATH to the
> appropriate places)
> pixman-0.21.2
> freetype-2.4.3  --without-fsspec --without-fsref
> --without-ats --without-quickdraw-toolbox --without-quickdraw-carbon
> fontconfig-2.8.0  --enable-libxml2 --with-freetype-config=...
> cairo-1.10.2 --disable-dependency-tracking \
> --enable-xlib=yes \
> --enable-xml=yes \
> --enable-fc=yes \
> --enable-ft=yes \
> --enable-xlib-xrender=no \
> --enable-xcb=no \
> --enable-qt=no \
> --enable-quartz=no \
> --enable-win32=no \
> --enable-skia=no \
> --enable-os2=no \
> --enable-beos=no \
> --enable-drm=no \
> --enable-pthread \
> --enable-gl=no
>
>
> Linking commands used to build gfast and gslow (relevant bits highlighed in
> red):
>
> gcc  -g -O2  -lSystemStubs -o gslow grads.o gxsubs.o gxmeta.o gxchpl.o
> gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o gafunc.o gautil.o
> gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o gabufrtbl.o gxX.o gxdxwd.o
> galloc.o gaddes.o gaio.o gacfg.o gauser.o gasdf.o gatxt.o -L/Users/jma/supplibs/lib
> -lcairo -L/usr/X11R6/lib -lX11 /Users/jma/supplibs/lib/libreadline.a
> /Users/jma/supplibs/lib/libncurses.a  /Users/jma/supplibs/lib/libgd.a
> /Users/jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a
> /Users/jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libgrib2c.a
> /Users/jma/supplibs/lib/libjasper.a /Users/jma/supplibs/lib/libpng12.a
> /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libmfhdf.a
> /Users/jma/supplibs/lib/libdf.a /Users/jma/supplibs/lib/libudunits.a
> /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a
> /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libhdf5.a
> /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a
> /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libudunits.a
> /Users/jma/supplibs/lib/libnetcdf.a /Users/jma/supplibs/lib/libhdf5_hl.a
> /Users/jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libz.a
> /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libcurl.a
>  /Users/jma/supplibs/lib/libtiff.a /Users/jma/supplibs/lib/libgeotiff.a
> /Users/jma/supplibs/lib/libshp.a  -lm
>
> gcc  -g -O2  -lSystemStubs -o gfast grads.o gxsubs.o gxmeta.o gxchpl.o
> gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o gafunc.o gautil.o
> gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o gabufrtbl.o gxX.o gxdxwd.o
> galloc.o gaddes.o gaio.o gacfg.o gauser.o gasdf.o gatxt.o -L/opt/local/lib
> -lcairo -lX11 /Users/jma/supplibs/lib/libreadline.a
> /Users/jma/supplibs/lib/libncurses.a  /Users/jma/supplibs/lib/libgd.a
> /Users/jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a
> /Users/jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libgrib2c.a
> /Users/jma/supplibs/lib/libjasper.a /Users/jma/supplibs/lib/libpng12.a
> /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libmfhdf.a
> /Users/jma/supplibs/lib/libdf.a /Users/jma/supplibs/lib/libudunits.a
> /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a
> /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libhdf5.a
> /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a
> /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libudunits.a
> /Users/jma/supplibs/lib/libnetcdf.a /Users/jma/supplibs/lib/libhdf5_hl.a
> /Users/jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libz.a
> /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libcurl.a
>  /Users/jma/supplibs/lib/libtiff.a /Users/jma/supplibs/lib/libgeotiff.a
> /Users/jma/supplibs/lib/libshp.a  -lm
>
>
> > otool -L gslow
> gslow:
>         /Users/jma/supplibs/src/cairo/lib/libcairo.2.dylib (compatibility
> version 11003.0.0, current version 11003.2.0)
>         /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current
> version 9.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 111.1.5)
>         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
> version 1.0.0)
> > otool -L gfast
> gfast:
>         /opt/local/lib/libcairo.2.dylib (compatibility version 11003.0.0,
> current version 11003.0.0)
>         /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0,
> current version 10.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 111.1.5)
>         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current
> version 1.0.0)
>
>
> > cairo-perf-trace gg.88743.trace
> [ # ]  backend                         test   min(s) median(s) stddev.
> count
> [ # ]    image: pixman 0.21.2
> [  0]    image                           gg    0.691    0.696   0.30%
>  6/6
> [ # ]  image16: pixman 0.21.2
> [  0]  image16                           gg    0.692    0.696   0.21%
>  6/6
>
>
>
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>
>


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Fwd: Issues with Store-Bought v. Home-Grown builds of Cairo

[Mike F. <mfi...@gm...>]

hi Brian,

of course performance is critical to me too; i use printim for my
production, mainly because i do layers (-t and -b).  i use gxyat on
occasion and it is slower (uses Cairo?) but the graphics better (but
bigger) and -t and -b don't work.  so for production, it'd be important
for me to have the fast gd printim.

thanks /r mike

p.s. are any of you in seattle for the ams?  i'm giving a talk in the
python symposium about my wxmaps and how i use grads.py to give grads an
oop interface



On 1/22/11 1:45 PM, Brian Doty wrote:
> Hi Gary, performance is a high priority. We depend on grads'
> performance in many ways. So we plan on maintaining a "native" X
> interface, similar to what exists in grads now. None of the new
> functionality would be available when the "native" interface is being
> used. But the performance should be essentially the same as is the
> case currently.
>
> Do you do all your graphics through X? Or do you also use printim?
> We are currently planning to drop the GD library in favor of Cairo for
> image production, and that would be a loss of performance. We gain
> anti-aliasing, raster fonts, and transparency. We are not sure as yet
> of the performance implications; if significant we may need to keep
> the GD interface around. We are still figuring these things out.
> Unfortunately we are finding that Cairo performance characteristics
> are platform dependent.... Brian
>
> On Jan 22, 2011, at 4:01 AM, Love, Mr. Gary, Contractor, Code 7542
> wrote:
>
>> Hi Jennifer,
>>
>> I like the sound of improved graphics, but even gfast will not be
>> fast enough. The current X11 library version generates a plot in
>> 200-300 milliseconds, 5 times faster. GrADS' current speed is one
>> of its best features which has always been very important to NRL and
>> FNMOC, since our post processing for just one project already takes
>> 30 minutes because so many plots are needed.
>>
>> I hope newer versions of GrADS can still be compiled with the X11
>> libs.
>>
>> Gary
>>
>> From: Jennifer Adams [mailto:jm...@co...]
>> Sent: Friday, January 21, 2011 9:36 AM
>> To: ope...@li...
>> Cc: Brian Doty
>> Subject: [Opengrads-devel] Fwd: Issues with Store-Bought v. Home-
>> Grown builds of Cairo
>>
>> Dear All,
>> I just sent this message to the Cairo forum, but I am copying it
>> here to keep you in the loop regarding my progress with Cairo, and
>> to see if you have any suggestions for how to get me out of the weeds.
>> --Jennifer
>>
>>
>> Begin forwarded message:
>>
>>> From: Jennifer Adams <jm...@co...>
>>> Date: January 21, 2011 12:31:50 PM EST
>>> To: cairo <ca...@ca...>
>>> Subject: Issues with Store-Bought v. Home-Grown builds of Cairo
>>>
>>> Dear Experts,
>>>
>>> I apologize in advance for a long email ... I'm just trying to be
>>> thorough. The bottom line is my own build of Cairo compared with
>>> the macports/yum build is MUCH too slow, and I don't know why.
>>>
>>> I am working toward getting Cairo to handle all the graphics for
>>> GrADS, an open-source program for the analysis and display of
>>> meteorological data. The old way of doing graphics in GrADS was a
>>> combination of direct calls to the X11 library (for the X window
>>> interface), calls to the gd library (for image output), plus some
>>> extremely dated code to create postscript output. All text was
>>> drawn in Hershey fonts. Cairo improves on this mish-mash in so many
>>> ways; the graphics are looking absolutely fantastic, the toy font
>>> API is adequate for our needs, and I know my users are going to be
>>> very excited when they see these improvements.
>>>
>>> For GrADS distribution, I provide binary executables for a small
>>> set of platforms, but many users must build from source. GrADS
>>> requires a long list of supplemental libraries to fully enable all
>>> its features: the current count is 20. With the exception of X11
>>> and a few other system libs, we link statically with all these
>>> supplibs, so that our binaries are portable (some of the supplibs
>>> GrADS needs are rather obscure.) I get the impression from browsing
>>> through the forum archives that linking statically with Cairo isn't
>>> really the right way to do it, so during my development and testing
>>> I have been linking dynamically with a macports build of Cairo.
>>> It's been fine that way, a little slower than the old way of using
>>> direct X11 calls, but not deal-breakingly slow.
>>>
>>> Looking forward to the time when I must put out a release, I am
>>> trying to integrate Cairo into the GrADS autoconfiguration scripts
>>> and the setup we have for building all the supplibs from source. I
>>> can't assume that all my users will have macports or yum to do the
>>> dirty work for them, so I provide a set of instructions to build
>>> the libraries from source and link them with GrADS. It is something
>>> like the end-to-end build instructions on the Cairo website. I try
>>> to keep it as simple as possible, and tailor these instructions for
>>> the specific needs of GrADS.
>>>
>>> Testing out my home-grown Cairo recipe, it built without any
>>> problems (specifics given below). Then I linked GrADS two ways, one
>>> with the macports build (gfast), the other with my home-grown build
>>> (gslow). More specifics on how I linked the executables and output
>>> from otool are given below. The performance difference between
>>> glsow v. gfast is astonishing. Where gfast took 1-2 seconds to draw
>>> a plot, gslow took ~100 seconds to do the same thing. I reran all
>>> these steps on our 64-bit linux server running CentOS 5.4 and got
>>> similar results.
>>>
>>> Thanks to earlier answers I got regarding getting cairo-trace to
>>> work, I created a huge trace file, but I'm not sure how to
>>> interpret it. It contained ~77,000 fills and ~10,000 strokes. I
>>> reran cairo-trace with the --profile option and posted it at
ftp://iges.org/pub/jma/gs.89039.lzma
>>> . The output from running cairo-perf-trace on my trace file is
>>> given below. I have no idea whether the trace info is helpful.
>>>
>>> What I could use is some advice about linking statically v.
>>> dynamically for my binary distributions, and some guidance for how
>>> to build Cairo from source (with only as-needed features) and
>>> link it with my application so that I get the same performance as
>>> the carefully packaged, fully-enabled versions of Cairo.
>>>
>>> Thank you!!
>>> --Jennifer
>>>
>>>
>>>
>>> --
>>> Jennifer M. Adams
>>> IGES/COLA
>>> 4041 Powder Mill Road, Suite 302
>>> Calverton, MD 20705
>>> jm...@co...
>>>
>>>
>>>
>>> OS X version 10.5.8
>>>
>>>> uname -a
>>> Darwin Atlantic-2.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul
>>> 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
>>>
>>>> gcc --version
>>> i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)
>>>
>>>
>>> Configuration options used to build cairo from source:
>>> pkg-config-0.23
>>> (I then set the environment vars PKG_CONFIG and PKG_CONFIG_PATH to
>>> the appropriate places)
>>> pixman-0.21.2
>>> freetype-2.4.3 --without-fsspec --without-fsref --without-ats --
>>> without-quickdraw-toolbox --without-quickdraw-carbon
>>> fontconfig-2.8.0 --enable-libxml2 --with-freetype-config=...
>>> cairo-1.10.2 --disable-dependency-tracking \
>>> --enable-xlib=yes \
>>> --enable-xml=yes \
>>> --enable-fc=yes \
>>> --enable-ft=yes \
>>> --enable-xlib-xrender=no \
>>> --enable-xcb=no \
>>> --enable-qt=no \
>>> --enable-quartz=no \
>>> --enable-win32=no \
>>> --enable-skia=no \
>>> --enable-os2=no \
>>> --enable-beos=no \
>>> --enable-drm=no \
>>> --enable-pthread \
>>> --enable-gl=no
>>>
>>>
>>> Linking commands used to build gfast and gslow (relevant bits
>>> highlighed in red):
>>>
>>> gcc -g -O2 -lSystemStubs -o gslow grads.o gxsubs.o gxmeta.o
>>> gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o
>>> gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o
>>> gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o
>>> gauser.o gasdf.o gatxt.o -L/Users/jma/supplibs/lib -lcairo -L/usr/
>>> X11R6/lib -lX11 /Users/jma/supplibs/lib/libreadline.a /Users/jma/
>>> supplibs/lib/libncurses.a /Users/jma/supplibs/lib/libgd.a /Users/
>>> jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a /Users/
>>> jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libgrib2c.a /
>>> Users/jma/supplibs/lib/libjasper.a /Users/jma/supplibs/lib/
>>> libpng12.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/
>>> libmfhdf.a /Users/jma/supplibs/lib/libdf.a /Users/jma/supplibs/lib/
>>> libudunits.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/
>>> lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/
>>> lib/libhdf5.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/
>>> lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/
>>> lib/libudunits.a /Users/jma/supplibs/lib/libnetcdf.a /Users/jma/
>>> supplibs/lib/libhdf5_hl.a /Users/jma/supplibs/lib/libhdf5.a /Users/
>>> jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libsz.a /Users/jma/
>>> supplibs/lib/libcurl.a /Users/jma/supplibs/lib/libtiff.a /Users/
>>> jma/supplibs/lib/libgeotiff.a /Users/jma/supplibs/lib/libshp.a -lm
>>>
>>> gcc -g -O2 -lSystemStubs -o gfast grads.o gxsubs.o gxmeta.o
>>> gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o
>>> gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o
>>> gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o
>>> gauser.o gasdf.o gatxt.o -L/opt/local/lib -lcairo -lX11 /Users/jma/
>>> supplibs/lib/libreadline.a /Users/jma/supplibs/lib/libncurses.a /
>>> Users/jma/supplibs/lib/libgd.a /Users/jma/supplibs/lib/libpng12.a /
>>> Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libjpeg.a /
>>> Users/jma/supplibs/lib/libgrib2c.a /Users/jma/supplibs/lib/
>>> libjasper.a /Users/jma/supplibs/lib/libpng12.a /Users/jma/supplibs/
>>> lib/libz.a /Users/jma/supplibs/lib/libmfhdf.a /Users/jma/supplibs/
>>> lib/libdf.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/
>>> supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/
>>> supplibs/lib/libz.a /Users/jma/supplibs/lib/libhdf5.a /Users/jma/
>>> supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/
>>> supplibs/lib/libz.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/
>>> supplibs/lib/libnetcdf.a /Users/jma/supplibs/lib/libhdf5_hl.a /
>>> Users/jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libz.a /
>>> Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libcurl.a /
>>> Users/jma/supplibs/lib/libtiff.a /Users/jma/supplibs/lib/
>>> libgeotiff.a /Users/jma/supplibs/lib/libshp.a -lm
>>>
>>>
>>>> otool -L gslow
>>> gslow:
>>> /Users/jma/supplibs/src/cairo/lib/libcairo.2.dylib
>>> (compatibility version 11003.0.0, current version 11003.2.0)
>>> /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0,
>>> current version 9.0.0)
>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
>>> current version 111.1.5)
>>> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
>>> current version 1.0.0)
>>>> otool -L gfast
>>> gfast:
>>> /opt/local/lib/libcairo.2.dylib (compatibility version
>>> 11003.0.0, current version 11003.0.0)
>>> /opt/local/lib/libX11.6.dylib (compatibility version
>>> 10.0.0, current version 10.0.0)
>>> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,
>>> current version 111.1.5)
>>> /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,
>>> current version 1.0.0)
>>>
>>>
>>>> cairo-perf-trace gg.88743.trace
>>> [ # ] backend test min(s) median(s)
>>> stddev. count
>>> [ # ] image: pixman 0.21.2
>>> [ 0] image gg 0.691 0.696
>>> 0.30% 6/6
>>> [ # ] image16: pixman 0.21.2
>>> [ 0] image16 gg 0.692 0.696
>>> 0.21% 6/6
>>>
>>>
>>
>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel

Re: [Opengrads-devel] Fwd: Issues with Store-Bought v. Home-Grown builds of Cairo

[Jennifer A. <jm...@co...>]

Hi, Gary --
Don't worry, maintaining the performance level of GrADS is important  
to me and Brian too. We are keeping the old X11 drawing code, so you  
can switch back to the old way of drawing to the X window if you want  
to by using a 'set' command. As for the image rendering in batch mode,  
I have no idea at this time whether cairo will be slower than gd. We  
haven't got there yet because of the necessary wholesale changes to  
the metafile structure. And if, in the end, you're unhappy with the  
speed of Cairo graphics, you will always have the option to stick with  
version 2.0.
--Jennifer

p.s. Got some advice back from the Cairo forum: If I build Cairo with  
libXrender enabled, the intolerable slowness goes away. And static  
linking should be okay, although I haven't got it working yet.




On Jan 22, 2011, at 4:01 AM, Love, Mr. Gary, Contractor, Code 7542  
wrote:

> Hi Jennifer,
>
> I like the sound of improved graphics, but even gfast will not be  
> fast enough.  The current X11 library version generates a plot in  
> 200-300 milliseconds, 5 times faster.  GrADS' current speed is one  
> of its best features which has always been very important to NRL and  
> FNMOC, since our post processing for just one project already takes  
> 30 minutes because so many plots are needed.
>
> I hope newer versions of GrADS can still be compiled with the X11  
> libs.
>
> Gary
>
> From: Jennifer Adams [mailto:jm...@co...]
> Sent: Friday, January 21, 2011 9:36 AM
> To: ope...@li...
> Cc: Brian Doty
> Subject: [Opengrads-devel] Fwd: Issues with Store-Bought v. Home- 
> Grown builds of Cairo
>
> Dear All,
> I just sent this message to the Cairo forum, but I am copying it  
> here to keep you in the loop regarding my progress with Cairo, and  
> to see if you have any suggestions for how to get me out of the weeds.
> --Jennifer
>
>
> Begin forwarded message:
>
>> From: Jennifer Adams <jm...@co...>
>> Date: January 21, 2011 12:31:50 PM EST
>> To: cairo <ca...@ca...>
>> Subject: Issues with Store-Bought v. Home-Grown builds of Cairo
>>
>> Dear Experts,
>>
>> I apologize in advance for a long email ... I'm just trying to be  
>> thorough. The bottom line is my own build of Cairo compared with  
>> the macports/yum build is MUCH too slow, and I don't know why.
>>
>> I am working toward getting Cairo to handle all the graphics for  
>> GrADS, an open-source program for the analysis and display of  
>> meteorological data. The old way of doing graphics in GrADS was a  
>> combination of direct calls to the X11 library (for the X window  
>> interface), calls to the gd library (for image output), plus some  
>> extremely dated code to create postscript output. All text was  
>> drawn in Hershey fonts. Cairo improves on this mish-mash in so many  
>> ways; the graphics are looking absolutely fantastic, the toy font  
>> API is adequate for our needs, and I know my users are going to be  
>> very excited when they see these improvements.
>>
>> For GrADS distribution, I provide binary executables for a small  
>> set of platforms, but many users must build from source. GrADS  
>> requires a long list of supplemental libraries to fully enable all  
>> its features: the current count is 20. With the exception of X11  
>> and a few other system libs, we link statically with all these  
>> supplibs, so that our binaries are portable (some of the supplibs  
>> GrADS needs are rather obscure.) I get the impression from browsing  
>> through the forum archives that linking statically with Cairo isn't  
>> really the right way to do it, so during my development and testing  
>> I have been linking dynamically with a macports build of Cairo.  
>> It's been fine that way, a little slower than the old way of using  
>> direct X11 calls, but not deal-breakingly slow.
>>
>> Looking forward to the time when I must put out a release, I am  
>> trying to integrate Cairo into the GrADS autoconfiguration scripts  
>> and the setup we have for building all the supplibs from source. I  
>> can't assume that all my users will have macports or yum to do the  
>> dirty work for them, so I provide a set of instructions to build  
>> the libraries from source and link them with GrADS. It is something  
>> like the end-to-end build instructions on the Cairo website. I try  
>> to keep it as simple as possible, and tailor these instructions for  
>> the specific needs of GrADS.
>>
>> Testing out my home-grown Cairo recipe, it built without any  
>> problems (specifics given below). Then I linked GrADS two ways, one  
>> with the macports build (gfast), the other with my home-grown build  
>> (gslow). More specifics on how I linked the executables and output  
>> from otool are given below. The performance difference between  
>> glsow v. gfast is astonishing. Where gfast took 1-2 seconds to draw  
>> a plot, gslow took ~100 seconds to do the same thing. I reran all  
>> these steps on our 64-bit linux server running CentOS 5.4 and got  
>> similar results.
>>
>> Thanks to earlier answers I got regarding getting cairo-trace to  
>> work, I created a huge trace file, but I'm not sure how to  
>> interpret it. It contained ~77,000 fills and ~10,000 strokes. I  
>> reran cairo-trace with the --profile option and posted it at ftp://iges.org/pub/jma/gs.89039.lzma 
>>    . The output from running cairo-perf-trace on my trace file is  
>> given below. I have no idea whether the trace info is helpful.
>>
>> What I could use is some advice about linking statically v.  
>> dynamically for my binary distributions, and some guidance for how  
>> to build Cairo from source (with only as-needed features) and link  
>> it with my application so that I get the same performance as the  
>> carefully packaged, fully-enabled versions of Cairo.
>>
>> Thank you!!
>> --Jennifer
>>
>>
>>
>> --
>> Jennifer M. Adams
>> IGES/COLA
>> 4041 Powder Mill Road, Suite 302
>> Calverton, MD 20705
>> jm...@co...
>>
>>
>>
>> OS X version 10.5.8
>>
>> > uname -a
>> Darwin Atlantic-2.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul  
>> 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
>>
>> > gcc --version
>> i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)
>>
>>
>> Configuration options used to build cairo from source:
>> pkg-config-0.23
>> (I then set the environment vars PKG_CONFIG and PKG_CONFIG_PATH to  
>> the appropriate places)
>> pixman-0.21.2
>> freetype-2.4.3  --without-fsspec --without-fsref --without-ats -- 
>> without-quickdraw-toolbox --without-quickdraw-carbon
>> fontconfig-2.8.0  --enable-libxml2 --with-freetype-config=...
>> cairo-1.10.2 --disable-dependency-tracking \
>> --enable-xlib=yes \
>> --enable-xml=yes \
>> --enable-fc=yes \
>> --enable-ft=yes \
>> --enable-xlib-xrender=no \
>> --enable-xcb=no \
>> --enable-qt=no \
>> --enable-quartz=no \
>> --enable-win32=no \
>> --enable-skia=no \
>> --enable-os2=no \
>> --enable-beos=no \
>> --enable-drm=no \
>> --enable-pthread \
>> --enable-gl=no
>>
>>
>> Linking commands used to build gfast and gslow (relevant bits  
>> highlighed in red):
>>
>> gcc  -g -O2  -lSystemStubs -o gslow grads.o gxsubs.o gxmeta.o  
>> gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o  
>> gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o  
>> gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o  
>> gauser.o gasdf.o gatxt.o -L/Users/jma/supplibs/lib -lcairo -L/usr/ 
>> X11R6/lib -lX11 /Users/jma/supplibs/lib/libreadline.a /Users/jma/ 
>> supplibs/lib/libncurses.a  /Users/jma/supplibs/lib/libgd.a /Users/ 
>> jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a /Users/ 
>> jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libgrib2c.a / 
>> Users/jma/supplibs/lib/libjasper.a /Users/jma/supplibs/lib/ 
>> libpng12.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/ 
>> libmfhdf.a /Users/jma/supplibs/lib/libdf.a /Users/jma/supplibs/lib/ 
>> libudunits.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/ 
>> lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/ 
>> lib/libhdf5.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/ 
>> lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/ 
>> lib/libudunits.a /Users/jma/supplibs/lib/libnetcdf.a /Users/jma/ 
>> supplibs/lib/libhdf5_hl.a /Users/jma/supplibs/lib/libhdf5.a /Users/ 
>> jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libsz.a /Users/jma/ 
>> supplibs/lib/libcurl.a  /Users/jma/supplibs/lib/libtiff.a /Users/ 
>> jma/supplibs/lib/libgeotiff.a /Users/jma/supplibs/lib/libshp.a  -lm
>>
>> gcc  -g -O2  -lSystemStubs -o gfast grads.o gxsubs.o gxmeta.o  
>> gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o  
>> gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o  
>> gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o  
>> gauser.o gasdf.o gatxt.o -L/opt/local/lib -lcairo -lX11 /Users/jma/ 
>> supplibs/lib/libreadline.a /Users/jma/supplibs/lib/libncurses.a  / 
>> Users/jma/supplibs/lib/libgd.a /Users/jma/supplibs/lib/libpng12.a / 
>> Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libjpeg.a / 
>> Users/jma/supplibs/lib/libgrib2c.a /Users/jma/supplibs/lib/ 
>> libjasper.a /Users/jma/supplibs/lib/libpng12.a /Users/jma/supplibs/ 
>> lib/libz.a /Users/jma/supplibs/lib/libmfhdf.a /Users/jma/supplibs/ 
>> lib/libdf.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/ 
>> supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/ 
>> supplibs/lib/libz.a /Users/jma/supplibs/lib/libhdf5.a /Users/jma/ 
>> supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/ 
>> supplibs/lib/libz.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/ 
>> supplibs/lib/libnetcdf.a /Users/jma/supplibs/lib/libhdf5_hl.a / 
>> Users/jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libz.a / 
>> Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libcurl.a  / 
>> Users/jma/supplibs/lib/libtiff.a /Users/jma/supplibs/lib/ 
>> libgeotiff.a /Users/jma/supplibs/lib/libshp.a  -lm
>>
>>
>> > otool -L gslow
>> gslow:
>>         /Users/jma/supplibs/src/cairo/lib/libcairo.2.dylib  
>> (compatibility version 11003.0.0, current version 11003.2.0)
>>         /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0,  
>> current version 9.0.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
>> current version 111.1.5)
>>         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,  
>> current version 1.0.0)
>> > otool -L gfast
>> gfast:
>>         /opt/local/lib/libcairo.2.dylib (compatibility version  
>> 11003.0.0, current version 11003.0.0)
>>         /opt/local/lib/libX11.6.dylib (compatibility version  
>> 10.0.0, current version 10.0.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
>> current version 111.1.5)
>>         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,  
>> current version 1.0.0)
>>
>>
>> > cairo-perf-trace gg.88743.trace
>> [ # ]  backend                         test   min(s) median(s)  
>> stddev. count
>> [ # ]    image: pixman 0.21.2
>> [  0]    image                           gg    0.691    0.696    
>> 0.30%    6/6
>> [ # ]  image16: pixman 0.21.2
>> [  0]  image16                           gg    0.692    0.696    
>> 0.21%    6/6
>>
>>
>
> ------------------------------------------------------------------------------
> Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)!
> Finally, a world-class log management solution at an even better  
> price-free!
> Download using promo code Free_Logger_4_Dev2Dev. Offer expires
> February 28th, so secure your free ArcSight Logger TODAY!
> http://p.sf.net/sfu/arcsight-sfd2d_______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel

--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...

Re: [Opengrads-devel] Fwd: Issues with Store-Bought v. Home-Grown builds of Cairo

[Brian D. <do...@co...>]

Hi Gary, performance is a high priority.  We depend on grads'  
performance in many ways.  So we plan on maintaining a "native" X  
interface, similar to what exists in grads now.  None of the new  
functionality would be available when the "native" interface is being  
used.  But the performance should be essentially the same as is the  
case currently.

Do you do all your graphics through X?  Or do you also use printim?   
We are currently planning to drop the GD library in favor of Cairo for  
image production, and that would be a loss of performance.  We gain  
anti-aliasing, raster fonts, and transparency. We are not sure as yet  
of the performance implications; if significant we may need to keep  
the GD interface around.  We are still figuring these things out.   
Unfortunately we are finding that Cairo performance characteristics  
are platform dependent.... Brian

On Jan 22, 2011, at 4:01 AM, Love, Mr. Gary, Contractor, Code 7542  
wrote:

> Hi Jennifer,
>
> I like the sound of improved graphics, but even gfast will not be  
> fast enough.  The current X11 library version generates a plot in  
> 200-300 milliseconds, 5 times faster.  GrADS' current speed is one  
> of its best features which has always been very important to NRL and  
> FNMOC, since our post processing for just one project already takes  
> 30 minutes because so many plots are needed.
>
> I hope newer versions of GrADS can still be compiled with the X11  
> libs.
>
> Gary
>
> From: Jennifer Adams [mailto:jm...@co...]
> Sent: Friday, January 21, 2011 9:36 AM
> To: ope...@li...
> Cc: Brian Doty
> Subject: [Opengrads-devel] Fwd: Issues with Store-Bought v. Home- 
> Grown builds of Cairo
>
> Dear All,
> I just sent this message to the Cairo forum, but I am copying it  
> here to keep you in the loop regarding my progress with Cairo, and  
> to see if you have any suggestions for how to get me out of the weeds.
> --Jennifer
>
>
> Begin forwarded message:
>
>> From: Jennifer Adams <jm...@co...>
>> Date: January 21, 2011 12:31:50 PM EST
>> To: cairo <ca...@ca...>
>> Subject: Issues with Store-Bought v. Home-Grown builds of Cairo
>>
>> Dear Experts,
>>
>> I apologize in advance for a long email ... I'm just trying to be  
>> thorough. The bottom line is my own build of Cairo compared with  
>> the macports/yum build is MUCH too slow, and I don't know why.
>>
>> I am working toward getting Cairo to handle all the graphics for  
>> GrADS, an open-source program for the analysis and display of  
>> meteorological data. The old way of doing graphics in GrADS was a  
>> combination of direct calls to the X11 library (for the X window  
>> interface), calls to the gd library (for image output), plus some  
>> extremely dated code to create postscript output. All text was  
>> drawn in Hershey fonts. Cairo improves on this mish-mash in so many  
>> ways; the graphics are looking absolutely fantastic, the toy font  
>> API is adequate for our needs, and I know my users are going to be  
>> very excited when they see these improvements.
>>
>> For GrADS distribution, I provide binary executables for a small  
>> set of platforms, but many users must build from source. GrADS  
>> requires a long list of supplemental libraries to fully enable all  
>> its features: the current count is 20. With the exception of X11  
>> and a few other system libs, we link   statically with all these  
>> supplibs, so that our binaries are portable (some of the supplibs  
>> GrADS needs are rather obscure.) I get the impression from browsing  
>> through the forum archives that linking statically with Cairo isn't  
>> really the right way to do it, so during my development and testing  
>> I have been linking dynamically with a macports build of Cairo.  
>> It's been fine that way, a little slower than the old way of using  
>> direct X11 calls, but not deal-breakingly slow.
>>
>> Looking forward to the time when I must put out a release, I am  
>> trying to integrate Cairo into the GrADS autoconfiguration scripts  
>> and the setup we have for building all the supplibs from source. I  
>> can't assume that all my users will have macports or yum to do the  
>> dirty work for them, so I provide a set of instructions to build  
>> the libraries from source and link them with GrADS. It is something  
>> like the end-to-end build instructions on the Cairo website. I try  
>> to keep it as simple as possible, and tailor these instructions for  
>> the specific needs of GrADS.
>>
>> Testing out my home-grown Cairo recipe, it built without any  
>> problems (specifics given below). Then I linked GrADS two ways, one  
>> with the macports build (gfast), the other with my home-grown build  
>> (gslow). More specifics on how I linked the executables and output  
>> from otool are given   below. The performance difference between  
>> glsow v. gfast is astonishing. Where gfast took 1-2 seconds to draw  
>> a plot, gslow took ~100 seconds to do the same thing. I reran all  
>> these steps on our 64-bit linux server running CentOS 5.4 and got  
>> similar results.
>>
>> Thanks to earlier answers I got regarding getting cairo-trace to  
>> work, I created a huge trace file, but I'm not sure how to  
>> interpret it. It contained ~77,000 fills and ~10,000 strokes. I  
>> reran cairo-trace with the --profile option and posted it at ftp://iges.org/pub/jma/gs.89039.lzma 
>>  . The output from running cairo-perf-trace on my trace file is  
>> given below. I have no idea whether the trace info is helpful.
>>
>> What I could use is some advice about linking statically v.  
>> dynamically for my binary distributions, and some guidance for how  
>> to build Cairo from   source (with only as-needed features) and  
>> link it with my application so that I get the same performance as  
>> the carefully packaged, fully-enabled versions of Cairo.
>>
>> Thank you!!
>> --Jennifer
>>
>>
>>
>> --
>> Jennifer M. Adams
>> IGES/COLA
>> 4041 Powder Mill Road, Suite 302
>> Calverton, MD 20705
>> jm...@co...
>>
>>
>>
>> OS X version 10.5.8
>>
>> > uname -a
>> Darwin Atlantic-2.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul  
>> 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
>>
>> > gcc --version
>> i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)
>>
>>
>> Configuration options used to build cairo from source:
>> pkg-config-0.23
>> (I then set the environment vars PKG_CONFIG and PKG_CONFIG_PATH to  
>> the appropriate places)
>> pixman-0.21.2
>> freetype-2.4.3  --without-fsspec --without-fsref --without-ats -- 
>> without-quickdraw-toolbox --without-quickdraw-carbon
>> fontconfig-2.8.0  --enable-libxml2 --with-freetype-config=...
>> cairo-1.10.2 --disable-dependency-tracking \
>> --enable-xlib=yes \
>> --enable-xml=yes \
>> --enable-fc=yes \
>> --enable-ft=yes \
>> --enable-xlib-xrender=no \
>> --enable-xcb=no \
>> --enable-qt=no \
>> --enable-quartz=no \
>> --enable-win32=no \
>> --enable-skia=no \
>> --enable-os2=no \
>> --enable-beos=no \
>> --enable-drm=no \
>> --enable-pthread \
>> --enable-gl=no
>>
>>
>> Linking commands used to build gfast and gslow (relevant bits  
>> highlighed in red):
>>
>> gcc  -g -O2  -lSystemStubs -o gslow grads.o gxsubs.o gxmeta.o  
>> gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o  
>> gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o  
>> gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o  
>> gauser.o gasdf.o gatxt.o -L/Users/jma/supplibs/lib -lcairo -L/usr/ 
>> X11R6/lib -lX11 /Users/jma/supplibs/lib/libreadline.a /Users/jma/ 
>> supplibs/lib/libncurses.a  /Users/jma/supplibs/lib/libgd.a /Users/ 
>> jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a /Users/ 
>> jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libgrib2c.a / 
>> Users/jma/supplibs/lib/libjasper.a /Users/jma/supplibs/lib/ 
>> libpng12.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/ 
>> libmfhdf.a /Users/jma/supplibs/lib/libdf.a /Users/jma/supplibs/lib/ 
>> libudunits.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/ 
>> lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/ 
>> lib/libhdf5.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/ 
>> lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/ 
>> lib/libudunits.a /Users/jma/supplibs/lib/libnetcdf.a /Users/jma/ 
>> supplibs/lib/libhdf5_hl.a /Users/jma/supplibs/lib/libhdf5.a /Users/ 
>> jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libsz.a /Users/jma/ 
>> supplibs/lib/libcurl.a  /Users/jma/supplibs/lib/libtiff.a /Users/ 
>> jma/supplibs/lib/libgeotiff.a /Users/jma/supplibs/lib/libshp.a  -lm
>>
>> gcc  -g -O2  -lSystemStubs -o gfast grads.o gxsubs.o gxmeta.o  
>> gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o  
>> gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o  
>> gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o  
>> gauser.o gasdf.o gatxt.o -L/opt/local/lib -lcairo -lX11 /Users/jma/ 
>> supplibs/lib/libreadline.a /Users/jma/supplibs/lib/libncurses.a  / 
>> Users/jma/supplibs/lib/libgd.a /Users/jma/supplibs/lib/libpng12.a / 
>> Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libjpeg.a / 
>> Users/jma/supplibs/lib/libgrib2c.a /Users/jma/supplibs/lib/ 
>> libjasper.a /Users/jma/supplibs/lib/libpng12.a /Users/jma/supplibs/ 
>> lib/libz.a /Users/jma/supplibs/lib/libmfhdf.a /Users/jma/supplibs/ 
>> lib/libdf.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/ 
>> supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/ 
>> supplibs/lib/libz.a /Users/jma/supplibs/lib/libhdf5.a /Users/jma/ 
>> supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/ 
>> supplibs/lib/libz.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/ 
>> supplibs/lib/libnetcdf.a /Users/jma/supplibs/lib/libhdf5_hl.a / 
>> Users/jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libz.a / 
>> Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libcurl.a  / 
>> Users/jma/supplibs/lib/libtiff.a /Users/jma/supplibs/lib/ 
>> libgeotiff.a /Users/jma/supplibs/lib/libshp.a  -lm
>>
>>
>> > otool -L gslow
>> gslow:
>>         /Users/jma/supplibs/src/cairo/lib/libcairo.2.dylib  
>> (compatibility version 11003.0.0, current version 11003.2.0)
>>         /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0,  
>> current version 9.0.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
>> current version 111.1.5)
>>         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,  
>> current version 1.0.0)
>> > otool -L gfast
>> gfast:
>>         /opt/local/lib/libcairo.2.dylib (compatibility version  
>> 11003.0.0, current version 11003.0.0)
>>         /opt/local/lib/libX11.6.dylib (compatibility version  
>> 10.0.0, current version 10.0.0)
>>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
>> current version 111.1.5)
>>         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,  
>> current version 1.0.0)
>>
>>
>> > cairo-perf-trace gg.88743.trace
>> [ # ]  backend                         test   min(s) median(s)  
>> stddev. count
>> [ # ]    image: pixman 0.21.2
>> [  0]    image                           gg    0.691    0.696    
>> 0.30%    6/6
>> [ # ]  image16: pixman 0.21.2
>> [  0]  image16                           gg    0.692    0.696    
>> 0.21%    6/6
>>
>>
>

Re: [Opengrads-devel] Fwd: Issues with Store-Bought v. Home-Grown builds of Cairo

[Love, M. G. C. C. 7. <gar...@nr...>]

Hi Jennifer,

I like the sound of improved graphics, but even gfast will not be fast enough.  The current X11 library version generates a plot in 200-300 milliseconds, 5 times faster.  GrADS' current speed is one of its best features which has always been very important to NRL and FNMOC, since our post processing for just one project already takes 30 minutes because so many plots are needed.

I hope newer versions of GrADS can still be compiled with the X11 libs.

Gary

________________________________
From: Jennifer Adams [mailto:jm...@co...]
Sent: Friday, January 21, 2011 9:36 AM
To: ope...@li...
Cc: Brian Doty
Subject: [Opengrads-devel] Fwd: Issues with Store-Bought v. Home-Grown builds of Cairo

Dear All,
I just sent this message to the Cairo forum, but I am copying it here to keep you in the loop regarding my progress with Cairo, and to see if you have any suggestions for how to get me out of the weeds.
--Jennifer


Begin forwarded message:

From: Jennifer Adams <jm...@co...<mailto:jm...@co...>>
Date: January 21, 2011 12:31:50 PM EST
To: cairo <ca...@ca...<mailto:ca...@ca...>>
Subject: Issues with Store-Bought v. Home-Grown builds of Cairo

Dear Experts,

I apologize in advance for a long email ... I'm just trying to be thorough. The bottom line is my own build of Cairo compared with the macports/yum build is MUCH too slow, and I don't know why.

I am working toward getting Cairo to handle all the graphics for GrADS, an open-source program for the analysis and display of meteorological data. The old way of doing graphics in GrADS was a combination of direct calls to the X11 library (for the X window interface), calls to the gd library (for image output), plus some extremely dated code to create postscript output. All text was drawn in Hershey fonts. Cairo improves on this mish-mash in so many ways; the graphics are looking absolutely fantastic, the toy font API is adequate for our needs, and I know my users are going to be very excited when they see these improvements.

For GrADS distribution, I provide binary executables for a small set of platforms, but many users must build from source. GrADS requires a long list of supplemental libraries to fully enable all its features: the current count is 20. With the exception of X11 and a few other system libs, we link statically with all these supplibs, so that our binaries are portable (some of the supplibs GrADS needs are rather obscure.) I get the impression from browsing through the forum archives that linking statically with Cairo isn't really the right way to do it, so during my development and testing I have been linking dynamically with a macports build of Cairo. It's been fine that way, a little slower than the old way of using direct X11 calls, but not deal-breakingly slow.

Looking forward to the time when I must put out a release, I am trying to integrate Cairo into the GrADS autoconfiguration scripts and the setup we have for building all the supplibs from source. I can't assume that all my users will have macports or yum to do the dirty work for them, so I provide a set of instructions to build the libraries from source and link them with GrADS. It is something like the end-to-end build instructions on the Cairo website. I try to keep it as simple as possible, and tailor these instructions for the specific needs of GrADS.

Testing out my home-grown Cairo recipe, it built without any problems (specifics given below). Then I linked GrADS two ways, one with the macports build (gfast), the other with my home-grown build (gslow). More specifics on how I linked the executables and output from otool are given below. The performance difference between glsow v. gfast is astonishing. Where gfast took 1-2 seconds to draw a plot, gslow took ~100 seconds to do the same thing. I reran all these steps on our 64-bit linux server running CentOS 5.4 and got similar results.

Thanks to earlier answers I got regarding getting cairo-trace to work, I created a huge trace file, but I'm not sure how to interpret it. It contained ~77,000 fills and ~10,000 strokes. I reran cairo-trace with the --profile option and posted it at ftp://iges.org/pub/jma/gs.89039.lzma . The output from running cairo-perf-trace on my trace file is given below. I have no idea whether the trace info is helpful.

What I could use is some advice about linking statically v. dynamically for my binary distributions, and some guidance for how to build Cairo from source (with only as-needed features) and link it with my application so that I get the same performance as the carefully packaged, fully-enabled versions of Cairo.

Thank you!!
--Jennifer



--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...<mailto:jm...@co...>



OS X version 10.5.8

> uname -a
Darwin Atlantic-2.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386

> gcc --version
i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)


Configuration options used to build cairo from source:
pkg-config-0.23
(I then set the environment vars PKG_CONFIG and PKG_CONFIG_PATH to the appropriate places)
pixman-0.21.2
freetype-2.4.3  --without-fsspec --without-fsref --without-ats --without-quickdraw-toolbox --without-quickdraw-carbon
fontconfig-2.8.0  --enable-libxml2 --with-freetype-config=...
cairo-1.10.2 --disable-dependency-tracking \
--enable-xlib=yes \
--enable-xml=yes \
--enable-fc=yes \
--enable-ft=yes \
--enable-xlib-xrender=no \
--enable-xcb=no \
--enable-qt=no \
--enable-quartz=no \
--enable-win32=no \
--enable-skia=no \
--enable-os2=no \
--enable-beos=no \
--enable-drm=no \
--enable-pthread \
--enable-gl=no


Linking commands used to build gfast and gslow (relevant bits highlighed in red):

gcc  -g -O2  -lSystemStubs -o gslow grads.o gxsubs.o gxmeta.o gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o gauser.o gasdf.o gatxt.o -L/Users/jma/supplibs/lib -lcairo -L/usr/X11R6/lib -lX11 /Users/jma/supplibs/lib/libreadline.a /Users/jma/supplibs/lib/libncurses.a  /Users/jma/supplibs/lib/libgd.a /Users/jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libgrib2c.a /Users/jma/supplibs/lib/libjasper.a /Users/jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libmfhdf.a /Users/jma/supplibs/lib/libdf.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/supplibs/lib/libnetcdf.a /Users/jma/supplibs/lib/libhdf5_hl.a /Users/jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libcurl.a  /Users/jma/supplibs/lib/libtiff.a /Users/jma/supplibs/lib/libgeotiff.a /Users/jma/supplibs/lib/libshp.a  -lm

gcc  -g -O2  -lSystemStubs -o gfast grads.o gxsubs.o gxmeta.o gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o gauser.o gasdf.o gatxt.o -L/opt/local/lib -lcairo -lX11 /Users/jma/supplibs/lib/libreadline.a /Users/jma/supplibs/lib/libncurses.a  /Users/jma/supplibs/lib/libgd.a /Users/jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libgrib2c.a /Users/jma/supplibs/lib/libjasper.a /Users/jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libmfhdf.a /Users/jma/supplibs/lib/libdf.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/supplibs/lib/libnetcdf.a /Users/jma/supplibs/lib/libhdf5_hl.a /Users/jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libcurl.a  /Users/jma/supplibs/lib/libtiff.a /Users/jma/supplibs/lib/libgeotiff.a /Users/jma/supplibs/lib/libshp.a  -lm


> otool -L gslow
gslow:
        /Users/jma/supplibs/src/cairo/lib/libcairo.2.dylib (compatibility version 11003.0.0, current version 11003.2.0)
        /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0, current version 9.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.5)
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
> otool -L gfast
gfast:
        /opt/local/lib/libcairo.2.dylib (compatibility version 11003.0.0, current version 11003.0.0)
        /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0, current version 10.0.0)
        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.1.5)
        /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)


> cairo-perf-trace gg.88743.trace
[ # ]  backend                         test   min(s) median(s) stddev. count
[ # ]    image: pixman 0.21.2
[  0]    image                           gg    0.691    0.696   0.30%    6/6
[ # ]  image16: pixman 0.21.2
[  0]  image16                           gg    0.692    0.696   0.21%    6/6

[Opengrads-devel] Fwd: Issues with Store-Bought v. Home-Grown builds of Cairo

[Jennifer A. <jm...@co...>]

Dear All,
I just sent this message to the Cairo forum, but I am copying it here  
to keep you in the loop regarding my progress with Cairo, and to see  
if you have any suggestions for how to get me out of the weeds.
--Jennifer


Begin forwarded message:

> From: Jennifer Adams <jm...@co...>
> Date: January 21, 2011 12:31:50 PM EST
> To: cairo <ca...@ca...>
> Subject: Issues with Store-Bought v. Home-Grown builds of Cairo
>
> Dear Experts,
>
> I apologize in advance for a long email ... I'm just trying to be  
> thorough. The bottom line is my own build of Cairo compared with the  
> macports/yum build is MUCH too slow, and I don't know why.
>
> I am working toward getting Cairo to handle all the graphics for  
> GrADS, an open-source program for the analysis and display of  
> meteorological data. The old way of doing graphics in GrADS was a  
> combination of direct calls to the X11 library (for the X window  
> interface), calls to the gd library (for image output), plus some  
> extremely dated code to create postscript output. All text was drawn  
> in Hershey fonts. Cairo improves on this mish-mash in so many ways;  
> the graphics are looking absolutely fantastic, the toy font API is  
> adequate for our needs, and I know my users are going to be very  
> excited when they see these improvements.
>
> For GrADS distribution, I provide binary executables for a small set  
> of platforms, but many users must build from source. GrADS requires  
> a long list of supplemental libraries to fully enable all its  
> features: the current count is 20. With the exception of X11 and a  
> few other system libs, we link statically with all these supplibs,  
> so that our binaries are portable (some of the supplibs GrADS needs  
> are rather obscure.) I get the impression from browsing through the  
> forum archives that linking statically with Cairo isn't really the  
> right way to do it, so during my development and testing I have been  
> linking dynamically with a macports build of Cairo. It's been fine  
> that way, a little slower than the old way of using direct X11  
> calls, but not deal-breakingly slow.
>
> Looking forward to the time when I must put out a release, I am  
> trying to integrate Cairo into the GrADS autoconfiguration scripts  
> and the setup we have for building all the supplibs from source. I  
> can't assume that all my users will have macports or yum to do the  
> dirty work for them, so I provide a set of instructions to build the  
> libraries from source and link them with GrADS. It is something like  
> the end-to-end build instructions on the Cairo website. I try to  
> keep it as simple as possible, and tailor these instructions for the  
> specific needs of GrADS.
>
> Testing out my home-grown Cairo recipe, it built without any  
> problems (specifics given below). Then I linked GrADS two ways, one  
> with the macports build (gfast), the other with my home-grown build  
> (gslow). More specifics on how I linked the executables and output  
> from otool are given below. The performance difference between glsow  
> v. gfast is astonishing. Where gfast took 1-2 seconds to draw a  
> plot, gslow took ~100 seconds to do the same thing. I reran all  
> these steps on our 64-bit linux server running CentOS 5.4 and got  
> similar results.
>
> Thanks to earlier answers I got regarding getting cairo-trace to  
> work, I created a huge trace file, but I'm not sure how to interpret  
> it. It contained ~77,000 fills and ~10,000 strokes. I reran cairo- 
> trace with the --profile option and posted it at ftp://iges.org/pub/jma/gs.89039.lzma 
>  . The output from running cairo-perf-trace on my trace file is  
> given below. I have no idea whether the trace info is helpful.
>
> What I could use is some advice about linking statically v.  
> dynamically for my binary distributions, and some guidance for how  
> to build Cairo from source (with only as-needed features) and link  
> it with my application so that I get the same performance as the  
> carefully packaged, fully-enabled versions of Cairo.
>
> Thank you!!
> --Jennifer
>
>
>
> --
> Jennifer M. Adams
> IGES/COLA
> 4041 Powder Mill Road, Suite 302
> Calverton, MD 20705
> jm...@co...
>
>
>
> OS X version 10.5.8
>
> > uname -a
> Darwin Atlantic-2.local 9.8.0 Darwin Kernel Version 9.8.0: Wed Jul  
> 15 16:55:01 PDT 2009; root:xnu-1228.15.4~1/RELEASE_I386 i386
>
> > gcc --version
> i686-apple-darwin9-gcc-4.0.1 (GCC) 4.0.1 (Apple Inc. build 5490)
>
>
> Configuration options used to build cairo from source:
> pkg-config-0.23
> (I then set the environment vars PKG_CONFIG and PKG_CONFIG_PATH to  
> the appropriate places)
> pixman-0.21.2
> freetype-2.4.3  --without-fsspec --without-fsref --without-ats -- 
> without-quickdraw-toolbox --without-quickdraw-carbon
> fontconfig-2.8.0  --enable-libxml2 --with-freetype-config=...
> cairo-1.10.2 --disable-dependency-tracking \
> --enable-xlib=yes \
> --enable-xml=yes \
> --enable-fc=yes \
> --enable-ft=yes \
> --enable-xlib-xrender=no \
> --enable-xcb=no \
> --enable-qt=no \
> --enable-quartz=no \
> --enable-win32=no \
> --enable-skia=no \
> --enable-os2=no \
> --enable-beos=no \
> --enable-drm=no \
> --enable-pthread \
> --enable-gl=no
>
>
> Linking commands used to build gfast and gslow (relevant bits  
> highlighed in red):
>
> gcc  -g -O2  -lSystemStubs -o gslow grads.o gxsubs.o gxmeta.o  
> gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o  
> gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o  
> gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o gauser.o  
> gasdf.o gatxt.o -L/Users/jma/supplibs/lib -lcairo -L/usr/X11R6/lib - 
> lX11 /Users/jma/supplibs/lib/libreadline.a /Users/jma/supplibs/lib/ 
> libncurses.a  /Users/jma/supplibs/lib/libgd.a /Users/jma/supplibs/ 
> lib/libpng12.a /Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/ 
> lib/libjpeg.a /Users/jma/supplibs/lib/libgrib2c.a /Users/jma/ 
> supplibs/lib/libjasper.a /Users/jma/supplibs/lib/libpng12.a /Users/ 
> jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libmfhdf.a /Users/ 
> jma/supplibs/lib/libdf.a /Users/jma/supplibs/lib/libudunits.a /Users/ 
> jma/supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/ 
> jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libhdf5.a /Users/jma/ 
> supplibs/lib/libsz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/ 
> supplibs/lib/libz.a /Users/jma/supplibs/lib/libudunits.a /Users/jma/ 
> supplibs/lib/libnetcdf.a /Users/jma/supplibs/lib/libhdf5_hl.a /Users/ 
> jma/supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libz.a /Users/jma/ 
> supplibs/lib/libsz.a /Users/jma/supplibs/lib/libcurl.a  /Users/jma/ 
> supplibs/lib/libtiff.a /Users/jma/supplibs/lib/libgeotiff.a /Users/ 
> jma/supplibs/lib/libshp.a  -lm
>
> gcc  -g -O2  -lSystemStubs -o gfast grads.o gxsubs.o gxmeta.o  
> gxchpl.o gxcntr.o gxstrm.o gxwmap.o gxshad.o gxshad2.o gaexpr.o  
> gafunc.o gautil.o gagx.o gscrpt.o gamach.o bufrstn.o gabufr.o  
> gabufrtbl.o gxX.o gxdxwd.o galloc.o gaddes.o gaio.o gacfg.o gauser.o  
> gasdf.o gatxt.o -L/opt/local/lib -lcairo -lX11 /Users/jma/supplibs/ 
> lib/libreadline.a /Users/jma/supplibs/lib/libncurses.a  /Users/jma/ 
> supplibs/lib/libgd.a /Users/jma/supplibs/lib/libpng12.a /Users/jma/ 
> supplibs/lib/libz.a /Users/jma/supplibs/lib/libjpeg.a /Users/jma/ 
> supplibs/lib/libgrib2c.a /Users/jma/supplibs/lib/libjasper.a /Users/ 
> jma/supplibs/lib/libpng12.a /Users/jma/supplibs/lib/libz.a /Users/ 
> jma/supplibs/lib/libmfhdf.a /Users/jma/supplibs/lib/libdf.a /Users/ 
> jma/supplibs/lib/libudunits.a /Users/jma/supplibs/lib/libsz.a /Users/ 
> jma/supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/ 
> supplibs/lib/libhdf5.a /Users/jma/supplibs/lib/libsz.a /Users/jma/ 
> supplibs/lib/libjpeg.a /Users/jma/supplibs/lib/libz.a /Users/jma/ 
> supplibs/lib/libudunits.a /Users/jma/supplibs/lib/libnetcdf.a /Users/ 
> jma/supplibs/lib/libhdf5_hl.a /Users/jma/supplibs/lib/libhdf5.a / 
> Users/jma/supplibs/lib/libz.a /Users/jma/supplibs/lib/libsz.a /Users/ 
> jma/supplibs/lib/libcurl.a  /Users/jma/supplibs/lib/libtiff.a /Users/ 
> jma/supplibs/lib/libgeotiff.a /Users/jma/supplibs/lib/libshp.a  -lm
>
>
> > otool -L gslow
> gslow:
>         /Users/jma/supplibs/src/cairo/lib/libcairo.2.dylib  
> (compatibility version 11003.0.0, current version 11003.2.0)
>         /usr/X11/lib/libX11.6.dylib (compatibility version 9.0.0,  
> current version 9.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
> current version 111.1.5)
>         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,  
> current version 1.0.0)
> > otool -L gfast
> gfast:
>         /opt/local/lib/libcairo.2.dylib (compatibility version  
> 11003.0.0, current version 11003.0.0)
>         /opt/local/lib/libX11.6.dylib (compatibility version 10.0.0,  
> current version 10.0.0)
>         /usr/lib/libSystem.B.dylib (compatibility version 1.0.0,  
> current version 111.1.5)
>         /usr/lib/libgcc_s.1.dylib (compatibility version 1.0.0,  
> current version 1.0.0)
>
>
> > cairo-perf-trace gg.88743.trace
> [ # ]  backend                         test   min(s) median(s)  
> stddev. count
> [ # ]    image: pixman 0.21.2
> [  0]    image                           gg    0.691    0.696    
> 0.30%    6/6
> [ # ]  image16: pixman 0.21.2
> [  0]  image16                           gg    0.692    0.696    
> 0.21%    6/6
>
>

[Opengrads-devel] Java build updated to 2.0.a9

[Arlindo da S. <da...@al...>]

All,

  I have made a Java build of 2.0.a9. The jar is here:

          http://opengrads.org/devel/java/grads-2.0.a9.oga.1.jar

At this point there is no Netcdf-4 or opendap support, but a bunch of the
new features are there, see below. (Although readline is disabled, there is
command line editing through java.) To run it, set GADDIR and GASCRp as
usual and enter

% java -jar grads-2.0.a9.oga.1.jar

It should work on any platform java is present.  There is no good reason for
using this grads version (it is a bit slower) except if you do not have a
build for your platform. It is sort of a fallback.

Jennifer: if you a have chance, could you run it through your kml/shapefile
testing scripts?

   Should I release this?

       Arlindo


Built Wed Oct 13 23:16:55 EDT 2010 for java-vm-nestedvm

This version of GrADS has been configured with the following options:
  o Built on a BIG ENDIAN machine
  o Athena Widget GUI DISABLED
  o Command line editing DISABLED
  o printim command for image output ENABLED
      http://www.zlib.net
      http://www.libpng.org/pub/png/libpng.html
      http://www.libgd.org/Main_Page
  o GRIB2 interface ENABLED
      http://www.ijg.org
      http://www.ece.uvic.ca/~mdadams/jasper
      http://www.nco.ncep.noaa.gov/pmb/codes/GRIB2
      g2clib-1.0.5
  o NetCDF interface ENABLED
      http://www.unidata.ucar.edu/software/netcdf
      netcdf "3.6.2" of Dec 11 2008 22:17:25 $
  o OPeNDAP gridded data interface DISABLED
  o OPeNDAP station data interface DISABLED
  o HDF4 interface ENABLED
      http://hdfgroup.org
      HDF 4.2r3
  o GeoTIFF and KML/TIFF output ENABLED
      http://www.libtiff.org
      http://geotiff.osgeo.org
  o KML contour output ENABLED
  o Shapefile interface ENABLED
      http://shapelib.maptools.org

For additional information please consult http://iges.org/grads


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Fwd: Opengrads bundle 2.0.a9 being uploaded

[Jennifer A. <jm...@co...>]

Pat,
That is a very helpful explanation! I will be more appreciative of my  
dynamic linker from now on. I will also try linking my test program  
statically and see what libraries I am going to have to add manually  
to get it to work. You are correct, we do dynamically link with X11,  
since we assume that is installed on every system where users are  
running GrADS. As for cairo, it seems like we should use xlib and not  
xcb. I am not expecting to have to change a lot of code in gxX.c, but  
I'll know better when we are done testing with stand-alone programs  
and are ready to begin integrating cairo into GrADS.
--Jennifer



On Oct 5, 2010, at 4:36 PM, Patrice Dumas wrote:

> On Tue, Oct 05, 2010 at 11:37:27AM -0400, Jennifer Adams wrote:
>> will have to figure out how to link statically. That long list of
>> dependent libraries is daunting! In my simple test program (rmf.c),
>> I am compiling/linking with this command:
>>
>> gcc -g rmf.c -o rmf -I/opt/local/include/cairo -L/opt/local/lib -
>> lcairo -L/usr/X11/lib -lX11
>
> Indeed, with gcc, you only need to link dynamically against a
> library when you use a symbol from that library.  But The library
> itself may need more symbols.  When linking dynamically, you don't  
> need
> to care, taking care of all the library dynamic dependency is the
> dynamic linker job.
>
> When you link statically, you have to do the job of the dynamic linker
> yourself, so that you need to supply all the libraries indirectly
> needed.
>
>> I have some more testing to do with fonts, and so I may have to add
>> some more libs to that list, but if my code doesn't require all
>> those dependent libs, I don't have to statically link them, do I?
>
> If the library you use require those dependent libs, you have to
> statically link them, even if your conde don't require them...
> You can laso link some libraries statically, and other dynamically.
> For example, the X libraries may be linked dynamically, even when
> most of th eother libraries are statically linked, and, unless I am
> wrong it is what is done for grads/opengrads.
>
>> As for backends, I am planning to use cairo to draw to an X window,
>> PNG, Postscript, PDF, and SVG. I do not see why it's necessary to
>> add the platform-specific window backends; X has been working fine
>> for GrADS all these years.
>
> Beware that there are 2 X backends:
>
> * xlib: Uses the Xlib interface to the X Window System. This backend  
> can target Windows or Pixmaps. The Render extension is used if  
> available, but is not required.
>
> * xcb: Provides support similar to the xlib backend, but uses the  
> XCB interface rather than Xlib.
>
> I guess that for maximal portability you should use the xlib backend
> when compiling cairo, and not the xcb backend.
>
> -- 
> Pat
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating  
> great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel

--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...

Re: [Opengrads-devel] Fwd: Opengrads bundle 2.0.a9 being uploaded

[Patrice D. <per...@fr...>]

On Tue, Oct 05, 2010 at 11:37:27AM -0400, Jennifer Adams wrote:
> will have to figure out how to link statically. That long list of
> dependent libraries is daunting! In my simple test program (rmf.c),
> I am compiling/linking with this command:
> 
> gcc -g rmf.c -o rmf -I/opt/local/include/cairo -L/opt/local/lib -
> lcairo -L/usr/X11/lib -lX11

Indeed, with gcc, you only need to link dynamically against a
library when you use a symbol from that library.  But The library
itself may need more symbols.  When linking dynamically, you don't need
to care, taking care of all the library dynamic dependency is the
dynamic linker job.

When you link statically, you have to do the job of the dynamic linker
yourself, so that you need to supply all the libraries indirectly
needed.

> I have some more testing to do with fonts, and so I may have to add
> some more libs to that list, but if my code doesn't require all
> those dependent libs, I don't have to statically link them, do I?

If the library you use require those dependent libs, you have to 
statically link them, even if your conde don't require them...
You can laso link some libraries statically, and other dynamically.
For example, the X libraries may be linked dynamically, even when
most of th eother libraries are statically linked, and, unless I am
wrong it is what is done for grads/opengrads.

> As for backends, I am planning to use cairo to draw to an X window,
> PNG, Postscript, PDF, and SVG. I do not see why it's necessary to
> add the platform-specific window backends; X has been working fine
> for GrADS all these years.

Beware that there are 2 X backends:

* xlib: Uses the Xlib interface to the X Window System. This backend can target Windows or Pixmaps. The Render extension is used if available, but is not required.

* xcb: Provides support similar to the xlib backend, but uses the XCB interface rather than Xlib.

I guess that for maximal portability you should use the xlib backend
when compiling cairo, and not the xcb backend.

-- 
Pat

Re: [Opengrads-devel] Fwd: Opengrads bundle 2.0.a9 being uploaded

[Jennifer A. <jm...@co...>]

On Oct 5, 2010, at 1:10 PM, Arlindo da Silva wrote:

>
>
> On Tue, Oct 5, 2010 at 11:37 AM, Jennifer Adams <jm...@co...>  
> wrote:
> Thanks for the comments. This is NOT my area of expertise, and I  
> welcome your guidance. Clearly, the dynamic linking against system  
> installations is the easiest, but for the binary distributions, I  
> will have to figure out how to link statically. That long list of  
> dependent libraries is daunting! In my simple test program (rmf.c),  
> I am compiling/linking with this command:
>
> gcc -g rmf.c -o rmf -I/opt/local/include/cairo -L/opt/local/lib - 
> lcairo -L/usr/X11/lib -lX11
>
> I have some more testing to do with fonts, and so I may have to add  
> some more libs to that list, but if my code doesn't require all  
> those dependent libs, I don't have to statically link them, do I?
>
>
> At a minimum you *must* have: fontconfig, freetype, pixman; other  
> libraries such as jpeg, libpng, etc., we already have.
Well, this is a basic question, but why don't I have to add -lpng12 to  
my test program if it is writing out PNG files? Is that somehow  
bundled into the macports version of libcairo.a?

>
> As for backends, I am planning to use cairo to draw to an X window,  
> PNG, Postscript, PDF, and SVG. I do not see why it's necessary to  
> add the platform-specific window backends; X has been working fine  
> for GrADS all these years.
>
> I'd love to be able to use a native Windows backend and get rid of  
> the X server...
You can do whatever you want with the Windows builds. I don't want to  
hold you back you from making Windows builds easier to  generate and  
use, but I am an MS nothing, and I can't support Windows code, so  
it'll have to be an opengrads feature. We haven't implemented anything  
in GrADS yet, but I don't see how we could close the door on the  
possibility of alternatives to X.

> The Quartz backend would also give it a more native look on Mac OS  
> X, but that is less critical.
Yeah, I really don't care about that as long as X11 is supported in OS  
X.

--Jennifer

Re: [Opengrads-devel] Fwd: Opengrads bundle 2.0.a9 being uploaded

[Arlindo da S. <da...@al...>]

On Tue, Oct 5, 2010 at 11:37 AM, Jennifer Adams <jm...@co...> wrote:

> Thanks for the comments. This is NOT my area of expertise, and I welcome
> your guidance. Clearly, the dynamic linking against system installations is
> the easiest, but for the binary distributions, I will have to figure out how
> to link statically. That long list of dependent libraries is daunting! In my
> simple test program (rmf.c), I am compiling/linking with this command:
>
> gcc -g rmf.c -o rmf -I/opt/local/include/cairo -L/opt/local/lib -lcairo
> -L/usr/X11/lib -lX11
>
> I have some more testing to do with fonts, and so I may have to add some
> more libs to that list, but if my code doesn't require all those dependent
> libs, I don't have to statically link them, do I?
>
>
At a minimum you *must* have: fontconfig, freetype, pixman; other libraries
such as jpeg, libpng, etc., we already have.


> As for backends, I am planning to use cairo to draw to an X window, PNG,
> Postscript, PDF, and SVG. I do not see why it's necessary to add the
> platform-specific window backends; X has been working fine for GrADS all
> these years.
>

I'd love to be able to use a native Windows backend and get rid of the X
server... The Quartz backend would also give it a more native look on Mac OS
X, but that is less critical. So, if you could leave the door open to the
possibility of an alternative to X that would be good.

     Arlindo




> --Jennifer
>
>
> On Oct 5, 2010, at 10:03 AM, Arlindo da Silva wrote:
>
>
>
> On Tue, Oct 5, 2010 at 5:16 AM, Patrice Dumas <per...@fr...> wrote:
>
>> On Mon, Oct 04, 2010 at 04:40:17PM -0400, Jennifer Adams wrote:
>> > >
>> > >Regarding the supplibs, I have been working on the switch to cairo
>> > >for graphics rendering. At the moment, I am only working in the
>> > >mac environment, using the macports installation of cairo, so I
>> > >don't really know what the issues are regarding building from
>> > >source, or for the autoconfiguration. If any of you can provide
>> > >some guidance, especially for the autoconf stuff, it would be most
>> > >welcome. There must be some existing code out there that does
>> > >this, maybe already in opengrads, but I haven't looked for it yet.
>>
>> cairo uses pkgconfig.  So something like
>>
>>  cairo_pkgconfig=yes
>>  PKG_CHECK_MODULES([CAIRO],[cairo >= $cairo_min_version],,
>>    [cairo_pkgconfig=no])
>>
>> should set CAIRO_LIBS and CAIRO_CFLAGS.  This should be enough for
>> linking dynamically against the system library.
>>
>>
>> The libs it requires when statically linking should be listed in
>> Requires.private:. To link statically against the supplibs, I guess that
>> you have 2 options.  Either simply supply the right link flags and
>> include dirs, either hardcoded or using GA_SET_FLAGS and similar.  Or
>> put the .pc files obtained when compiling supplibs in a specific
>> directory in the supplibs, set PKG_CONFIG_PATH to this directory, and
>> use a pkg-config call, like
>>  pkg-config --static cairo --libs
>>
>> I don't know if you'd want to put pkg-config in the supplibs too, then,
>> but, in case you wonder, on my debian squeeze box, pkg-config links
>> against
>> glib, which in turns requires libpcre, and no other dependency (besides
>> a C library) seems to be involved.
>>
>>
>> (Cairo, however needs quite a bit of depednecies, but it is not clear to
>> me
>> how you want to handle the backends of cairo?  On my box, the xcb backend
>> is used:
>>
>> pkg-config --static cairo --libs
>> -lcairo -lpixman-1 -lfontconfig -lexpat -lfreetype -lpng12 -lz -lm
>> -lxcb-render-util -lXrender -lxcb-render -lX11 -lpthread -lxcb -lXau -lXdmcp
>>
>> But I guess that on MacOSX the Quartz backend should be used, on Windows
>> the win32 backend, on other UNIX the xlib backend?)
>>
>>
> Nice to hear form you!
>
> The opengrads supplibs includes pkg-config and builds  (whenever possible)
> builds all packages with it. The main reason being this autoconf
> integration.
>
> As for my experience building cairo in the supplibs. This is the only
> library that I have *not* succeeded to build statically on all platforms.
> Not quite sure what the issues are. Since the opengrads wrappers
> automatically sets LD_LIBRARY_PATH, this have not been a problem. So far I
> have used cairo primarily for gxyat with only 4 backends: PNG, SVG, ps and
> pdf. I disable everything else to avoid any unnecessary dependency.
>
>  Jennifer: which back ends do you intend to use?
>
>    Arlindo
>
> --
> Arlindo da Silva
> da...@al...
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
>
> http://p.sf.net/sfu/beautyoftheweb_______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>
>
> --
> Jennifer M. Adams
> IGES/COLA
> 4041 Powder Mill Road, Suite 302
> Calverton, MD 20705
> jm...@co...
>
>
>
>
>
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb
> _______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel
>
>


-- 
Arlindo da Silva
da...@al...

Re: [Opengrads-devel] Fwd: Opengrads bundle 2.0.a9 being uploaded

[Jennifer A. <jm...@co...>]

Thanks for the comments. This is NOT my area of expertise, and I  
welcome your guidance. Clearly, the dynamic linking against system  
installations is the easiest, but for the binary distributions, I will  
have to figure out how to link statically. That long list of dependent  
libraries is daunting! In my simple test program (rmf.c), I am  
compiling/linking with this command:

gcc -g rmf.c -o rmf -I/opt/local/include/cairo -L/opt/local/lib - 
lcairo -L/usr/X11/lib -lX11

I have some more testing to do with fonts, and so I may have to add  
some more libs to that list, but if my code doesn't require all those  
dependent libs, I don't have to statically link them, do I?

As for backends, I am planning to use cairo to draw to an X window,  
PNG, Postscript, PDF, and SVG. I do not see why it's necessary to add  
the platform-specific window backends; X has been working fine for  
GrADS all these years.
--Jennifer


On Oct 5, 2010, at 10:03 AM, Arlindo da Silva wrote:

>
>
> On Tue, Oct 5, 2010 at 5:16 AM, Patrice Dumas <per...@fr...>  
> wrote:
> On Mon, Oct 04, 2010 at 04:40:17PM -0400, Jennifer Adams wrote:
> > >
> > >Regarding the supplibs, I have been working on the switch to cairo
> > >for graphics rendering. At the moment, I am only working in the
> > >mac environment, using the macports installation of cairo, so I
> > >don't really know what the issues are regarding building from
> > >source, or for the autoconfiguration. If any of you can provide
> > >some guidance, especially for the autoconf stuff, it would be most
> > >welcome. There must be some existing code out there that does
> > >this, maybe already in opengrads, but I haven't looked for it yet.
>
> cairo uses pkgconfig.  So something like
>
>  cairo_pkgconfig=yes
>  PKG_CHECK_MODULES([CAIRO],[cairo >= $cairo_min_version],,
>    [cairo_pkgconfig=no])
>
> should set CAIRO_LIBS and CAIRO_CFLAGS.  This should be enough for
> linking dynamically against the system library.
>
>
> The libs it requires when statically linking should be listed in
> Requires.private:. To link statically against the supplibs, I guess  
> that
> you have 2 options.  Either simply supply the right link flags and
> include dirs, either hardcoded or using GA_SET_FLAGS and similar.  Or
> put the .pc files obtained when compiling supplibs in a specific
> directory in the supplibs, set PKG_CONFIG_PATH to this directory, and
> use a pkg-config call, like
>  pkg-config --static cairo --libs
>
> I don't know if you'd want to put pkg-config in the supplibs too,  
> then,
> but, in case you wonder, on my debian squeeze box, pkg-config links  
> against
> glib, which in turns requires libpcre, and no other dependency  
> (besides
> a C library) seems to be involved.
>
>
> (Cairo, however needs quite a bit of depednecies, but it is not  
> clear to me
> how you want to handle the backends of cairo?  On my box, the xcb  
> backend
> is used:
>
> pkg-config --static cairo --libs
> -lcairo -lpixman-1 -lfontconfig -lexpat -lfreetype -lpng12 -lz -lm - 
> lxcb-render-util -lXrender -lxcb-render -lX11 -lpthread -lxcb -lXau - 
> lXdmcp
>
> But I guess that on MacOSX the Quartz backend should be used, on  
> Windows
> the win32 backend, on other UNIX the xlib backend?)
>
>
> Nice to hear form you!
>
> The opengrads supplibs includes pkg-config and builds  (whenever  
> possible) builds all packages with it. The main reason being this  
> autoconf integration.
>
> As for my experience building cairo in the supplibs. This is the  
> only library that I have *not* succeeded to build statically on all  
> platforms. Not quite sure what the issues are. Since the opengrads  
> wrappers automatically sets LD_LIBRARY_PATH, this have not been a  
> problem. So far I have used cairo primarily for gxyat with only 4  
> backends: PNG, SVG, ps and pdf. I disable everything else to avoid  
> any unnecessary dependency.
>
>  Jennifer: which back ends do you intend to use?
>
>    Arlindo
>
> -- 
> Arlindo da Silva
> da...@al...
> ------------------------------------------------------------------------------
> Beautiful is writing same markup. Internet Explorer 9 supports
> standards for HTML5, CSS3, SVG 1.1,  ECMAScript5, and DOM L2 & L3.
> Spend less time writing and  rewriting code and more time creating  
> great
> experiences on the web. Be a part of the beta today.
> http://p.sf.net/sfu/beautyoftheweb_______________________________________________
> Opengrads-devel mailing list
> Ope...@li...
> https://lists.sourceforge.net/lists/listinfo/opengrads-devel

--
Jennifer M. Adams
IGES/COLA
4041 Powder Mill Road, Suite 302
Calverton, MD 20705
jm...@co...