On 4/16/2011 1:11 PM, Alan W. Irwin wrote: > On 2011-04-16 11:44-0400 chm wrote: > >> I'm starting to develop an OpenGL driver for >> PLplot > > We would welcome such a driver, but there are some fundamental issues > with OpenGL to be aware of. I have no practical experience with OpenGL > myself, but my understanding from reading phoronix (e.g., see the > lead-in paragraph to > http://www.phoronix.com/scan.php?page=news_item&px=OTI1OA which > summarizes the Linux OpenGL situation in preparation for an article on > OpenCL) is that later versions of OpenGL are not supported by Linux. > (I have heard elsewhere that is because those later versions are under > patent threat.) So my advice would be to stick to the OpenGL 1 and 2 > standards rather than using anything shiny and new from OpenGL 3 or 4.
The non-interactive driver would be using the framebuffer extension with fallback to a pixel buffer or even direct copy as a last resort. The drawing commands are all OpenGL 1.x and, to my knowledge, OpenGL 2.x is supported most everywhere. >> and would like to know the best way >> to participate as a PLplot developer for this >> contribution. My current plan is as follows: >> >> (1) get PLplot SVN to build on cygwin > > Why Cygwin? That is one of our least-tested platforms so you may run > into trouble there. I hope to help out with Cygwin testing myself > (see below), but that wine idea might not work. Yes, I know. I use PDL on cygwin when I am on windows if I need its full capabilities. One of the goals of the OpenGL driver for PLplot is to have a portable and available everywhere device on which I to standardize for 2D graphics in PDL. I don't expect that getting PLplot to build on cygwin to be too difficult, it will most likely be a sequence of figuring out how and what to enable/disable to get it to build. Once it builds, then adding in the various other languages and drivers can be done over time. Still, I expect this process to be much less difficult than it would be for me to get a PLplot development environment working on windows. >> (2) get PLplot on cygwin to work with PDL >> (I'll be working on #3 and #4 below in >> parallel to this) > > Why PDL? The issues in that external project are being currently > worked on by Doug Hunt, but until he resolves those it is going to be > quite complicated (see examples/perl/README.perldemos) to even test > PDL. I would stick to the C version of PLplot for your initial > experiments. We have a whole host of C examples which "just work". > If you use the cmake option -DBUILD_TEST=ON, then I've been a PDL developer for a number of years and have been the release manager for the last few releases. My goal is to make PDL build out-of-the-box on all the major perl system platforms: * windows * cygwin * linux/unix/*bsd/solaris * mac os x for which the chief sticking point is getting the external dependencies for PDL on the given platform. For windows, this is particularly tricky as it has no native package capability and most/all of the options boil down to becoming a win32 program developer first (not the best way to introduce users to PDL as a scientific programming language if they have to become a perl and C guru first!). > make test_c_psc > > automatically builds all the C examples (and also runs them for -dev > psc). > > After that, you can simply try your own experimental device instead, e.g., by > running > > examples/c/x01c -dev opengl > > >> >> (3) implement a non-interactive opengl driver >> (kind of like the mem driver on steroids) >> >> (4) add interactive support to the new driver >> >> I took a look at the wiki and it looks like >> you have a patches-only mode for developers. >> If so, at what time should I provide the new >> code patch? > > We accept patches submitted to us under the LGPL license any time. We > have a nice architecture so that driver code does not affect anything > else, and if there are problems with a particular immature driver's > code so it won't even build without issues, then we can disable it by > default. Great! > We probably won't apply your patch immediately if we are in the last > distracted week before a release, but otherwise there are no timing > constraints. > >> >> Also, I was wondering what the schedule was >> for the 5.9.8 release (I was thinking it might >> be possible for a preliminary opengl driver to >> be available for that if it is not immediately >> being release). > > Our release process is informal. Basically we release when ready and > finalize release dates typically a couple of weeks in advance. We are > not ready yet to set the date for the 5.9.8 release because there is > some open-ended work Hez and I are still doing on plcolorbar, some > open-ended work on the qt device driver that Hazen is doing, and I > also need some additional time to pursue my idea that it might be > possible to test PLplot on Cygwin under wine. I don't think cygwin testing under wine has much chance of working as cygwin makes aggressive use of many of the win32 programming API and so is sensitive to things that are only slightly different from real windows... Is there a standard user interface for interactive widgets for PLplot, e.g., keyboard and mouse controls, user options,...? Thanks much for the context and information. I look forward to my first alpha release. Cheers, Chris ------------------------------------------------------------------------------ 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 _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
