👍

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

Reply via email to