From: phil r. <phi...@ya...> - 2013-10-15 20:09:15
|
I've started this with a new thread title as it had deviated significantly from the original topic. Given the suggestion that we streamline the wxWidgets driver I've been looking into wxGCDC which provides access to wxGraphicsContext but via a wxDC interface. On my Windows system I can create a wxGCDC using wxMemoryDC memdc; //some code to select in an appropriately sized wxBitmap wxGCDC gcdc(memdc); //some code to draw on gcdc then blit the result to screen This works fine giving antialiased results and support for alpha. However there is a negative which is that wxGCDC does not support subpixel points for line ends. It also does not support floating point widths for lines, but neither does wxGraphicsContext so this isn't so much of a problem. I don't see this as a massive problem. I'm also not sure if linux users can construct a wxGCDC from a wxMemoryDC as this constructor seems to be wrapped in a #ifdef __WXMSW__, maybe a linux user can check. If it doesn't work then can you instead create a wxGraphicsContext from a wxMemoryDC, then create a wxGCDC using the default constructor and then call SetGraphicsContext? The last hurdle is that when I pass a wxGCDC to plplot I seem to get a blank screen. In fact even if I draw on the wxGCDC then pass it to Plplot I still get a blank screen. I'm not sure why, but I imagine this is fixable. So I guess to sumarise, if we can live with losing subpixel accuracy and if Linux users can create wxGCDC from a wxMemoryDC then this should all be possible. Phil |
From: phil r. <phi...@ya...> - 2013-10-15 23:42:02
|
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. Phil |
From: Alan W. I. <ir...@be...> - 2013-10-16 00:58:54
|
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 __________________________ |
From: phil r. <phi...@ya...> - 2013-10-16 06:41:30
|
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. Phil On Wednesday, 16 October 2013, 1:58, Alan W. Irwin <ir...@be...> 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 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 __________________________ |