Hi Alan
xGCDC is available in 2.8, but looking at 2.9 it seems that it is being slowly expanded to enable it to wrap other wxDCs. My comments about 2.9 were just regarding future proofing.

On Wednesday, 16 October 2013, 1:58, Alan W. Irwin <irwin@beluga.phys.uvic.ca> wrote:
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

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 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