👍 On 5 October 2017 at 00:38, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > On 2017-10-05 00:28+0100 Phil Rosenberg wrote: > >>> >>> Once confirmed, then the obvious next question is why are we using a >>> subset of the wxGraphicsContext class indirectly via the wxGCDC class >>> rather than using the wxGraphicsContext class directly (which would >>> provide important native gradient capability for the new wxwidgets >>> device driver)? >>> >> >> Ah, there are some good reasons. Because by using a wxDC we get access >> to the following derived classes which render to the following formats >> wxGCDC (GraphicsContext, which renders to memory or to a printer) >> wxMemoryDC (memory which can then be saved as a bitmap (bmp, jpg, >> tiff, png) or blitted to a window - on windows lower quality than GCDC >> but hardware accelerated) >> wxMetafileDC (Windows metafile) >> wxMirrorDC (reflects allong x=y line and passes to another wxDC) >> wxPostscriptDC (postscript files) >> wxPrinterDC (Printing) >> wxScreenDC (Rendering directly onto the screen rather than a window) >> wxSVGFileDC (SVG file output) >> wxPaintDC (Rendering to a window) >> Plus quite possibly other people's custom wxDCs - for example I once >> started writing a Direct2D wxDC, but never finished it. >> >> Thats kind of how OO programming works. A base class defines a common >> structure and the derived classes expand that base structure. But if I >> do not care what kind of DC I am working with then I just request a >> wxDC* and use just that common base structure can deal with all the >> derived classes equally. Then when I call wxDC->DrawRectangle() I >> neither know nor care whether that writes text to a ps file, sends a >> command to a printer or sets pixels in memory. >> >> As it happens when I slimmed things down to just accepting wxDCs in >> the wxWidgets driver, the wxGCDC had just become available which was >> brilliant, but either wxGraphicsContexts were not able to render to a >> printer or I wasn't aware of that option. So those things swung me in >> favour of wxDC over wxGraphicsContext. >> >> So having access to all the derived classes is one reason. The other >> is that if we swapped to using a wxGraphicsContext we would silently >> break everyone's code because of our casting of a void* to a wxDC, >> that would instead get cast to a wxGraphicsContext, this would just >> generate segfaults in all our users' code. The final reason is time. I >> don't have time to rewrite the driver again using wxGraphicsContext >> and I deliberately went for only wxDC at the last rewrite because >> wxGCDC had become available and it halved the maintenance time >> compared to having two separate backends. >> >> Lastly I will say that it is possible to check if we are dealing with >> a wxGCDC and get access to the underlying wxGraphicsContext. I have >> done this for text rendering because wxDC does not support arbitrary >> affine transformations as needed for the 3D style text. But I really >> don't want to make a habit of it. I'd much rather try the rotated >> clipped rectangle and keep total consistency. >> >> Anyway that was a much longer explanation than intended ;-) > > > That's fine. I liked all those details in your good answer to my > question. :-) > > > 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 > __________________________
------------------------------------------------------------------------------ Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
