Hazen, I have an evolving binding for Pharo, but it currently gives me no choice but to save graphs to disk. It is also allowing me to generate numbers in memory and create graphs from them without turning it all into text and/or fighting with pipes to get to gnuplot, so it's a win even now. memcairo is a new to me, so I will have a look and see if it will do the job.
Making a long story short, in an ideal world, I will be able to create an image (RGBA array or whatever makes sense to both systems) in memory, have PLplot scrawl data all over it, and then do further processing without writing a file until it suits me, if ever. It is partly perfectionism, and a lot of removing a potentially troublesome limitation. Things that I might want to do with an image include arraying graphs to create a multi-plot structure that might be much more easily created in Smalltalk than in PLplot, and going directly from data in memory to a preview plot in the IDE. My immediate goal is to hit a proposal deadline, and for that it's fine/preferred to write files. That will change as I turn to more interactive analysis of these and other data sets. Bill ________________________________________ From: Hazen Babcock [hbabc...@mac.com] Sent: Monday, September 20, 2010 6:40 PM To: Schwab,Wilhelm K Cc: plplot-devel@lists.sourceforge.net Subject: Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB? Schwab,Wilhelm K wrote: > First, are any of you using plsmem() to obtain graphs w/o saving them to a > file? Encouragement in the form of success stories or warnings of trouble > spots would be greatly appreciated. > > Another question that has arisen come in the form of image formats readily > understood by the Smalltalk environment I am using, called Pharo and > available at http://pharo-project.org/home. I am still struggling slightly > to understand the various twists, but it appears that it is willing readily > absorb images made up of RGB and an alpha value (4 bytes per pixel instead of > 3). > > If I am reading thing correctly, I could allocate an array of RGB values, let > PLplot draw on it, then use a C function to copy the memory into RGB+Alpha > array for Pharo. Could Smalltalk do the memory manipulation? Yes, but there > are usually great speed gains to be had by doing such looping in C, > regardless of the details of how that is accomplished. > > The question for you is whether adding an alpha value has any interest to the > future of PLplot? I think that an alpha value would be a fine addition to the memory (mem) driver, but the mem driver is pretty basic and unlikely to get improved much as we would just be duplicating functionality provided by a number of different 3rd party graphics libraries. You might also look at the memcairo driver, as this already supports both alpha values and fills, as well as unicode fonts, anti-aliasing and a bunch of other nice stuff. Of course it requires installing the Cairo library which is not always entirely straightforward depending on your OS. Could you describe a little bit more about what you want to do? It sounds like you already have some sort of language bindings for Smalltalk, but you'd like to use the graphs in some sort of GUI? On the off-chance that the Smalltalk GUI is built on GTK I would look at the extcairo driver, or if it is based on Qt then the extqt driver might be an option. -Hazen ------------------------------------------------------------------------------ Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
