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
