Re: [Plplot-devel] Further to your recent comment for wxwidgets gradient bug 173

[Alan W. I. <ir...@be...>]

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
__________________________