On 2013-10-15 16:41-0700 phil rosenberg wrote: > After a bit of playing around it seems that wxGCDC uses a similar trick to some Plplot drivers in that it pretends to have a bigger size than the bitmap it is drawing on (10000x10000 units). This means we do get subpixel accuracy and better than 1 pixel accuracy line widths. However it is up to the user to define the scale factor to convert to bitmap pixels which is why I was getting a blank canvas - my drawing was based on the "fake" size so missed the bitmap. Now I have this worked out I can now send a wxGCDC to plplot using backend=0 and get sensible output. There may be some tweeks needed to ensure the line width is correct. But providing things work on Linux I think the wxGraphicsContext backend can be made essentially redundant.
> The only issue is implementation. Looking at some wxWidgets 2.9 code it seems wxGCDC is able to wrap other wxDCs such as wxPrintDC as well as wxMemoryDC, and the list is likely to expand I imagine. I think the user might want three options: > 1) Pass an ordinary wxDC to Plplot > 2) Pass a wxMemoryDC to Plplot but get wxGCDC rendering - i.e. identical > functionality to current backend=2 functionality. > 3a) Pass another wxDC in and have it wrapped by wxGCDC or > 3b) have users wrap a wxDC in a wxGCDC themselves and pass this to Plplot. > 1) and 2) can be acheived by keeping the backend flag and replacing private Plplot code. This would maintain backwards compatibility for users of the current system. > We probably should support 3b) better than we currently do as currently the user has to set the scaling before passing the wxGCDC to Plplot. It would be better if Plplot did this and it would be easy to do I think. 3a) could be done, but we'd need the user to pass another flag indicating what type of wxDC they have passed so that it can be cast as the correct pointer. If the number of wxDCs which can be wrapped by wxGCDC increases then we'd need to add extra options. This doesn't sound like a good plan to me. > All these options could be implemented with one set of rendering code and an if statement at initialisation. So much cleaner in terms of maintenance. Hi Phil: I am glad to hear you got your proposed wxGCDC approach working. One issue you should be aware of is that even Debian unstable does not have wxwidgets 2.9 packaged yet, and other Linux distros may be similarly behind what is being released upstream by the wxwidgets developers. So is 2.9 a requirement for your new approach or could you base your work on 2.8 for now? If 2.9 is a requirement, it means I would have to build that myself (at least until Debian packages wxwidgets 2.9) to test your work, but that should be straightforward (I am already building 2.8.12 without issues as part of build_projects), and I am willing to do such builds if necessary. But it does mean your work will be mostly ignored in the Linux world until 2.9 is packaged so I would advise using 2.8.x for now if it supports the wxGCDC approach you want to take. 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); the Time Ephemerides project (timeephem.sf.net); PLplot scientific plotting software package (plplot.sf.net); 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 __________________________ ------------------------------------------------------------------------------ October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60135031&iu=/4140/ostg.clktrk _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
