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

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

On 2017-10-04 11:53+0100 Phil Rosenberg wrote:

> On 3 October 2017 at 18:00, Alan W. Irwin <ir...@be...> wrote:
>> On 2017-10-03 11:24+0100 Phil Rosenberg wrote:
>>
>>> Hi Alan
>>> It may be possible to do as you said with a clip region and an affine
>>> transform. I did consider this but I am not sure if the gradient gets
>>> transformed or just the polygon shape. I would have to check.
>>>
>>> Regarding inheritance, you have the correct syntax. wxDC and
>>> wxGraphicsContext are pretty close to top level classes so only
>>> inherit from wxObject, which many wxWidgets classes inherit from and I
>>> think it basically allows conversion between classes and strings which
>>> specify the class name. If you look in the docs,
>>> e.g.http://docs.wxwidgets.org/3.1/classwx_d_c.html, there is usually
>>> an inheritance diagram. You have access to all the functions towards
>>> the base of the tree, but the magic of C++ is that the behaviour of
>>> some of the functions can be redefined towards the branches of a tree
>>> by using the virtual specifier. So for example wxDC has a virtual
>>> function DrawLines. So if I have a pointer to a wxDC I can always call
>>> myDcPointer->DrawLines(/*params*/). But then if that pointer actually
>>> points to an inherited class then the inherited class's version of
>>> that function is called, so a wxPostscriptDC would write the vector to
>>> the file, a wxMemoryDC would work out which pixels need shading and
>>> shade them, etc.
>>
>>
>> Hi Phil:
>>
>> I don't claim to understand everything you have said above in your
>> second paragraph, but if the upshot is there are C++ ways to give us
>> access to all wxWidget library methods regardless of the class they
>> are in, then I suggest the most promising way forward (since the
>> documentation does not mention any limitations on this brush) is
>> likely to be to use wxGraphicsContext::CreateLinearGradientBrush
>> rather than wxDC::GradientFillLinear (which does have many documented
>> limitations).
>
> No, sadly it does not. I can only access functions that are in wxDC.
> wxGraphicsContext is neither a parent nor a child class to wxDC, it is
> totally unrelated.
> The wxGCDC class is a child of wxDC. It takes wxDC commands and then
> calls equivalent wxGraphicsContext commands. This is how we make use
> of the wxGraphicsContexts rendering.

Hi Phil:

Please follow up with the
wxWidgets gurus you know to confirm whether
wxGraphicsContext::CreateLinearGradientBrush would provide linear
gradients in arbitrary directions to fill an arbitrary polygon. The
SVG file format as well as pango/cairo and Qt libraries support such
gradients so our standalone svg device and all our "cairo" and "qt"
devices support native gradients. So I am pretty sure that
wxGraphicsContext::CreateLinearGradientBrush does support such
gradients (because the documentation mentioning no limitations and I
assume the wxWidgets developers would like to keep up with their
competition). But it is essential to get that confirmed.

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)?

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
__________________________