[Plplot-devel] Capturing output in memory
I have a "working" interface to PLplot, but it relies on temporary disk files, which is not at all attractive. Some time ago, I asked how to avoid this and there were solutions, but not ones that were within easy reach. IIRC, one option was to set up a quad RGB buffer and use (Cairo?) to draw on it. The problem was that I could not (or did not know how to) readily use the data to draw (quickly at least) in my preferred Smalltalk environment. Recently, there are rumblings of Cairo support in Pharo Smalltalk, and I am starting to wonder whether I might be able to connect the dots in the near future. Am I describing something that makes any sense? Another option might to to create my own device driver. The web site says how easy it is to do, but does not go into detail that I could find. For example, Pharo readily uses some variations on RGB that I might be able to exploit with a suitable driver?? Comments/advice are welcome. This is something that will happen when the pieces come together; for now, temp files are UGLY but work. Another topic: multiple plots at one time. IIRC, PLplot was not threadsafe when I last checked. It would be nice to have a way to open a few plots at one time and work on them "at leisure." Is that possible to do? The fact that I do not recall obtaining and passing "plot IDs" suggests to me that there are global data structures and associated limitations?? Bill -- For Developers, A Lot Can Happen In A Second. Boundary is the first to Know...and Tell You. Monitor Your Applications in Ultra-Fine Resolution. Try it FREE! http://p.sf.net/sfu/Boundary-d2dvs2___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
Re: [Plplot-devel] Legends
Dave, I'm content to be voted down on this, but a performance argument is a stretch: how can one possibly fit enough legend text on a graph to cause a CPU any stress at all? The first real use I made of PLplot was to plot 500,000 sample time series; copying a few hundred bytes (max) of text will not make a bit of difference by comparison. Bill From: David MacMahon [dav...@astro.berkeley.edu] Sent: Wednesday, October 06, 2010 12:59 AM To: Alan W. Irwin Cc: Schwab,Wilhelm K; Plplot-devel@lists.sourceforge.net Subject: Re: [Plplot-devel] Legends On Oct 5, 2010, at 21:42 , Alan W. Irwin wrote: > On 2010-10-05 22:19-0400 Schwab,Wilhelm K wrote: > >> I was interested in building it (5.9.7) to try the legend code. >> Is there a reason for the double pointer? It seems that >> >> this part\0that part\0...\0and the last part\0\0 >> >> would do the job just as easily?? > > I am willing to keep an open mind about changing the > present approach if we run into trouble interfacing const char ** > text to > other languages. FWIW, I vote for keeping it as char**. For the smallish amounts of legend text it probably doesn't matter that much either way, but with more and/or larger strings that might come from different locations, the cost of copying into one buffer can become significant. Creating an array of char* and populating with pointers into a long buffer containing back-to-back strings is not nearly so onerous (presuming you know how many strings you have to begin with so you can allocate a big enough char* array). Does the library strdup the passed in strings, render them before returning, or just copy the pointers for later rendering? Thanks, Dave (who has obviously not examined the legend implementation!) -- 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 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] Legends
I started out trying to build the new release and did not get far with the instructions on the wiki. Then I found this: http://www.linuxquestions.org/questions/linux-newbie-8/unable-to-install-and-build-plplot-5-9-a-789425/ Building plplot-5.9.5 : 1) cd plplot-5.9.5/ , 2) mkdir build 3) cd build/ , 4) cmake .. ( cmake ) The text output in the terminal will show, what's included in the configuration / Makefile : tcl/tk , wxwidgets, pyqt4, python, etc. 4) make : will build the binaries and the libraries. My own addition was then sudo make install which *appears* to have worked. I was interested in building it to try the legend code. Is there a reason for the double pointer? It seems that this part\0that part\0...\0and the last part\0\0 would do the job just as easily?? Bill -- 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 ___ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
[Plplot-devel] FW: [Plplot-general] Error using threads, GTK and Cairo driver
From: Schwab,Wilhelm K Sent: Wednesday, September 29, 2010 10:11 AM To: Johan Mazel Subject: RE: [Plplot-general] Error using threads, GTK and Cairo driver John, I would be happy with anything (Ocaml is fine) any time (not in a big rush); if you have a plan for turning it into a useful example, all the better. Your idea of a descriptor sounds reasonable. Hopefully something like that, or maybe just turning globals into thread-local items(??) will make threading easier. Bill From: Johan Mazel [johan.ma...@gmail.com] Sent: Wednesday, September 29, 2010 9:54 AM To: Schwab,Wilhelm K Subject: Re: [Plplot-general] Error using threads, GTK and Cairo driver Hi 2010/9/29 Schwab,Wilhelm K mailto:bsch...@anest.ufl.edu>> Is there/will there be code somewhere? Right now, nothing is directly available. In the future, I will try to make it available. However, If you want to take a look at my code right now, I can provide you with the (Ocaml) sources. Is your code OS specific? I ask in the spirit of a Windows escapee trying to understand how to do this sort of thing on Linux. There is no urgency, and even snippets could be helpful. My code is not specific to an OS, however, I don't know wether each used library has an available version for every OS. The library that I use are lablgtk and, of course, plplot and its bindings. Should there need to be one mutex to protect the entire library? I could see it for protecting a collection of open streams, but ideally once created and until closed (global again), the streams would be freely accessible from different threads?? Bill Actually, I didn't found a way to cleanly reopen a stream after a first plinit (or plinit_cairo in my case). Therefore, I don't see how several thread could access the same plplot stream. I think the multiple access through several thread could be possible if your program would handle only one plplot stream. But even in this case, you would have to be very careful about what each thread is doing on the plplot stream. In my opinion, the hidden problem behind this is the fact that plplot does not allow the user to access a kind of descriptor on a plplot stream. The type of this descriptor could be plplot_t for example and that would allow one to use plplot in a much simpler way when dealing with GUI. I am not a specialist of plplot and its history but I think that is linked to the way plplot has originally been designed: something closer to script programming and Matlab for example than something to be used inside GUIs. In my case, I solved this limitation by destroying everything and redrawing everything again whenever I want to draw something on a curve. Same thing apply when I am handling signals for GTK (expose, etc...). I basically tried to build something on top of PLplot that would allow me to use something similar to the couple Qt/Qwt. On a long term perspective I have really no idea of the interest of this solution. The main problem being the lack performance induced by the full init/redraw in case of modifications. A much cleaner solution would be to use descriptor as I previously stated but I don't know whether plplot is heading towards this. Regards. Johan Mazel -- 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
Re: [Plplot-devel] Volunteer requested to implement legend-drawing capability for the PLplot core library.
RE map0 vs. 1, with the understanding that I have no idea what I am talking about, the maps are global, right? Could the answer be to pass a function pointer instead of the array? That would get around the void pointer because the common denominator would instead be a function that translates colors, not the colors themselves. There would hopefully be only two of them that are part of the library and hide any details. Sorry if that's missing the point(er). Bill -Original Message- From: Alan W. Irwin [mailto:ir...@beluga.phys.uvic.ca] Sent: Tuesday, September 28, 2010 1:03 PM To: Hezekiah M. Carty Cc: PLplot development list Subject: Re: [Plplot-devel] Volunteer requested to implement legend-drawing capability for the PLplot core library. On 2010-09-28 08:43-0400 Hezekiah M. Carty wrote: > On Sun, Sep 26, 2010 at 12:50 AM, Alan W. Irwin > wrote: >> On 2010-09-25 15:32-0700 Alan W. Irwin wrote: >>> and then move on to designing and >>> implementing the cmap1 part of that API (after reviewing your ideas >>> on >>> that) by early next week assuming it fits in nicely with pllegend. >> >> I plan to start on the cmap1 part tomorrow (Sunday). I feel >> confident the end result will be a powerful legend capability for >> PLplot that should satisfy virtually everybody's legend needs. >> > > Aside from the question about the cmap[01]_colors, cmap_patterns, > cmap_scales questions I brought up in the 5.9.7 release thread, my > main concerns come down to types: > > 1. text_justification is defined as a PLINT, but from the doxygen > documentation it looks like it should be a PLFT. Good catch! Fixed as of revision 11230. > 2. With support for cmap1 elsewhere in pllegend, would it be > reasonable to add support for cmap1 line and symbol colors? Yes. > Do people > generally use cmap1 for line or symbol plots? I think we only have one instance of that in our examples so users may not have picked up on this possibility, but it has long been the case that plcol0 and plcol1 could be used interchangably so perhaps we should arrange that for pllegend as well. To implement this, I think we need an overall PL_LEGEND_CMAP1 opt flag and we should replace PL_LEGEND_CMAP0 and PL_LEGEND_CMAP1 in opt_array with PL_LEGEND_DISCRETE_COLOR. If the overall PL_LEGEND_CMAP1 opt flag is set, _all_ color indices are interpreted as PLFLT cmap1 values in the range from 0. to 1., but otherwise they are interpreted as PLINT cmap0 index values. One potential downside to having cmap0 and cmap1 alternatives for all colors is a proliferation of alternative PLINT cmap0 or PLFLT cmap1 arguments such as the current PLINT *cmap0_colors, PLFLT * cmap1_colors arguments. Could we just use generic pointer (void *) arguments to stand in for either kind of cmap index/value to halve the number of color arguments? I have very little experience with using void *, so if you think this idea would work, could you illustrate what to do with a commit that replaces the current PLINT *cmap0_colors, PLFLT * cmap1_colors arguments with one generic pointer argument? Then I could propagate that idea to all our other color arguments, e.g., bg_color, text_colors, line_colors, symbol_colors (which are currently restricted to just cmap0). Are there any downsides to using generic pointers for something like this? For example, will such pointers make it difficult to propagate pllegend to some of our languages? Whatever we decide to do here, I think we should be consistent. So if you don't think it is a good idea to provide both cmap0 and cmap1 alternatives for all colour arguments (through generic pointers), then I think we should probably consistently use cmap0 arguments for all colors, i.e., drop the PLFLT * cmap1_colors argument and replace the current PL_LEGEND_CMAP0 and PL_LEGEND_CMAP1 flags in opt_array with PL_LEGEND_DISCRETE_COLOR. > 3. In the 5.9.7 release thread you mentioned the ability to skip > entries when using pllegend interactively. Could this be specified > explicitly? Should there be a PL_LEGEND_NONE option defined (= 0 I > think) for opt_array? This isn't strictly necessary as passing 0 > would do the same thing, but it would make the intent of code using > this skipping functionality a bit easier to see. PL_LEGEND_NONE > wouldn't need a special case in the pllegend implementation, just a > #define along with the other PL_LEGEND_* options. Good catch. Fixed as of revision 11230. > > I like pllegend in its current state overall. I do, however, think > that it is worth encouraging the PLplot developers and interested > users to try out the pllegend API post-5.9.7 before we commit to > keeping the API as-is. In particular, some real-world use and a > plcolorbar implementation may expose other options we would like to > provide in pllegend. Agreed. (See my post in the 5.9.7 thread on this issue.) So it appears the only outstanding issue is issue 2, mentioned above. Your
[Plplot-devel] Timing of plsfnam()
The ultimate fix to my concern here will be to move to a memory device driver, but for right now I am trying to distract myself from that and get some much needed work done (small grant proposal). The question is one of design in my Smalltalk binding: how should it work? How can it work? One consideration is how and when a plot gets created and initialized. In object oriented terms, "who" creates it? Yes, I personify objects: deal with it :) The less that needs to be specified at that time, the better. I can understand needing to specify the device early on, but why is the file name required before initialization? Could that be relaxed? Could it be relaxed wisely? One possible reason not to relax it could surround vector graphics. I have not yet figured out when the file is created and when data is written to it. Early in my experiments, I had success only with .svg files, and my 500,000 sample time series predictably created big files. I quickly found and installed the remaining pieces and got png working, but I could see how one might want (or perhaps need) to write the file as elements are being drawn. For the moment, I am simply trying to reduce the amount of duplicate code I am creating before I end with a lot of it that I later have to fix. My interactive plots get written to a most-recent graph file (yuk, but it gets the job done for now). When the goal is to create an image on disk, it still might be nice to be able to defer the decision about the name. My horrible handling of interactive plots makes it all the more obvious, because one has to know the plot is interactive when it is created rather than being able to make that decision (shamelessly save a temp file and load it from disk to view it) at the last minute. Obviously, when I get to the point of using a memory buffer, it will indeed be possible to create the graph and only then route it to a window, disk, or use it for drawing outside of PLplot's influence. Any strong thoughts on this or similar topics would be appreciated. In particular, did you have a design turn out particularly well or poorly; if the latter, was there a fix? I am mostly thinking about friendliness of the resulting binding. Can one easily create a plot, add data to it, and have the plot either decide its own limits or, if specified, use limits that are explicitly set? What is the role of ensured execution? For now I always call plend(). Should the binding behave differently if there is an unhandled exception? Bill -- 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
[Plplot-devel] plenv() axis parameter
Is there any bit arithmetic behind this from the manual: axis = -2: No box or annotation. axis = -1: Draw box only. axis = 0: Draw box, labeled with coordinate values around edge. axis = 1: In addition to box and labels, draw the two axes X = 0 and Y = 0. axis = 2: Same as axis = 1, but also draw a grid at the major tick interval. axis = 10: Logarithmic X axis, linear Y axis. axis = 11: Logarithmic X axis, linear Y axis and draw line Y = 0. axis = 20: Linear X axis, logarithmic Y axis. axis = 21: Linear X axis, logarithmic Y axis and draw line X = 0. axis = 30: Logarithmic X and Y axes. I am wondering whether I should define the values above, or if there are more fundamental values that should then be combined to create the parameter value?? Is there a way to get ticks without labels? My question is in the spirit of hopefully setting up a condition consistent with "it's better to be lucky than good." I don't have a specific problem in mind; instead, I am reaching a point where I would naturally start to create what Smalltalk programmers call a pool dictionary, and want to get it right from the beginning (less to undo later). Bill -- 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
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
Hazen, plsmema() sounds like a/the answer. For the moment (time pressure is mounting), I am going to hack a most-recent-graph temp file, hold my nose and get some work done with a crude interactive plotting capability that will hopefully get me through the next couple of weeks. Thanks! Bill From: Hazen Babcock [hbabc...@mac.com] Sent: Wednesday, September 22, 2010 10:48 AM To: Schwab,Wilhelm K Cc: plplot-devel@lists.sourceforge.net Subject: Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB? Schwab,Wilhelm K wrote: > Alan, Hazen, > > I certainly can figure out how to build the library, but it would *really* be > nice to have it in the plplot9-driver-cairo package. Never hurts to ask :) > > However, it turns out not to be magic fix, as the memory layout is ARGB vs. > RGBA: > > /* Malloc memory the way cairo likes it. Aligned on the stride computed > by cairo_format_stride_for_width > * and in the RGB24 format (from > http://cairographics.org/manual/cairo-Image-Surfaces.html): > * Each pixel is a 32-bit quantity, with the upper 8 bits unused. > * Red, Green, and Blue are stored in the remaining 24 bits in that order > */ > > I need to read up on Pharo, what it calls Rome, and Cairo. If Pharo has or > grows a Cairo interface, then the above become a non-problem. If are willing to use bleeding edge PLplot (v11198), we now have a function called plsmema() that you can use to pass RGBA formatted memory to PLplot. You will also have to use the memcairo driver as it is the only one that can take advantage of memory formatted in this way. Don't worry though, because when you get the array back from Cairo it will still be in RGBA format, it doesn't get converted to ARGB. examples/python/test_memcairo.py shows how you might use plsmema() and plsmem() from Python to create plots in memory, then save them as .png files. -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
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
Alan, Hazen, I certainly can figure out how to build the library, but it would *really* be nice to have it in the plplot9-driver-cairo package. Never hurts to ask :) However, it turns out not to be magic fix, as the memory layout is ARGB vs. RGBA: /* Malloc memory the way cairo likes it. Aligned on the stride computed by cairo_format_stride_for_width * and in the RGB24 format (from http://cairographics.org/manual/cairo-Image-Surfaces.html): * Each pixel is a 32-bit quantity, with the upper 8 bits unused. * Red, Green, and Blue are stored in the remaining 24 bits in that order */ I need to read up on Pharo, what it calls Rome, and Cairo. If Pharo has or grows a Cairo interface, then the above become a non-problem. Thanks! Bill From: Alan W. Irwin [ir...@beluga.phys.uvic.ca] Sent: Tuesday, September 21, 2010 11:24 AM To: Schwab,Wilhelm K; Hazen Babcock Cc: plplot-devel@lists.sourceforge.net Subject: Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB? On 2010-09-21 10:43-0400 Schwab,Wilhelm K wrote: > Hazen, > > Ideally, I would prefer a cross-platform solution, but the reality is that I > work on Linux. Cairo appears to have installed vai apt-get; I have yet to do > anything with it. > > Where should I look for the memcairo driver? Hi Bill: First, make sure our cairo device driver (that contains all sorts of devices including memcairo) works. If your list of devices in the cmake output includes any device with "cairo" in the name, then that means our build system has found the development version pango/cairo libraries needed by our cairo device driver. Otherwise, look for any WARNING messages in your cmake output having to do with pango/cairo and deal with them (normally by installing the developer version of pango and cairo, cleaning out your build tree, and trying again). Once some "*cairo" devices are available, then make the memcairo device available using the cmake option -DPLD_memcairo=ON. Hi Hazen: The rest of this is directed to you. There is a note in cmake/modules/drivers-init.cmake that says "memcairo does not work so turn it off by default". Does memcairo actually work now? If so, you should remove that note, and turn memcairo on by default just like our other cairo devices so that users don't have to use -DPLD_memcairo=ON to access it. Alan __ Alan W. Irwin Astronomical research affiliation with Department of Physics and Astronomy, University of Victoria (astrowww.phys.uvic.ca). Programming affiliations with the FreeEOS equation-of-state implementation for stellar interiors (freeeos.sf.net); PLplot scientific plotting software package (plplot.org); the libLASi project (unifont.org/lasi); the Loads of Linux Links project (loll.sf.net); and the Linux Brochure Project (lbproject.sf.net). __ Linux-powered Science __ -- 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
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
Hazen, Ideally, I would prefer a cross-platform solution, but the reality is that I work on Linux. Cairo appears to have installed vai apt-get; I have yet to do anything with it. Where should I look for the memcairo driver? 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
Re: [Plplot-devel] plsmem(), RGB+alpha vs. RGB?
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
Re: [Plplot-devel] [Plplot-general] plsmem(), RGB+alpha vs. RGB?
Simon, I had found the thread, but had not noticed that you had posted a demo; I have that source now. It sounds like it works, but not particularly well and does not do fills. Is that fair? FWIW, if the memory driver were to use, conditionally or otherwiwse, RGBA, my life might get a little easier - not that it should matter too much. Perhaps a more accurate statement is that the cleaner it can be to use RGBA data, the better binding I should be able to release for Pharo. Most likely I will start with a hack and then worry about whether or not it can be packaged for wide use. Thanks! Bill From: si...@mungewell.org [si...@mungewell.org] Sent: Monday, September 20, 2010 2:35 PM To: Schwab,Wilhelm K Cc: plplot-devel@lists.sourceforge.net; plplot-gene...@lists.sourceforge.net Subject: Re: [Plplot-general] plsmem(), RGB+alpha vs. RGB? > 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. > Hi Bill, There was some discussion on the mailing list a while ago. I was adding the plsmem capability to the python drivers. Thread and demo here, if you haven't already found it: http://sourceforge.net/mailarchive/forum.php?thread_name=800ea22f22d346264ae4cd5f31f3c373.squirrel%40host171.canaca.com&forum_name=plplot-devel I never did the overlay stuff I intended Cheers, Simon -- 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
[Plplot-devel] plsmem(), RGB+alpha vs. RGB?
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? Bill -- 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
