Re: [Plplot-devel] [ plplot-Bugs-3474186 ] wxWidgets dc and gc driver on

[phil r. <phi...@ya...>]

As far as adding to the documentation is concerned, something that I found quite confusing is that nowhere does it state that calls to plcol0 or plcol1 change the current colour an this colour is then used for all subsequent drawing actions until the colour is changed again. Might I suggest a slight alteration to the second paragraph of the "Setting Color" section.

First replace the 1st sentence with:


The PLplot colour model utilizes the concepts of a background color, a current color and two color maps to allow the user to select from a large range of colours.

Then append the following to the end


The user can change the background color by setting the index 0 color of color map0 (as described in the section Color Map0) and can change the current color by selecting any of the colors from either color map using calls to plcol0 or plcol1. When the current color is changed all subsequent drawing actions will utilise the new color until it is changed again.

As far as submitting a patch is concerned I haven't done this before. Am I correct in saying that I simply do

diff -cr ~/plplot-5.9.9 ~/plplot-5.9.9 > wxwidgetscolourfix.patch

then submit the patch via the sourceforge site?


Phil




________________________________
 From: Alan W. Irwin <ir...@be...>
To: phil rosenberg <phi...@ya...> 
Cc: "plp...@li..." <plp...@li...> 
Sent: Thursday, 19 January 2012, 19:22
Subject: Re: [Plplot-devel] [ plplot-Bugs-3474186 ] wxWidgets dc and gc driver on
 
On 2012-01-18 19:12-0800 Alan W. Irwin wrote:

> Just to jump in late here, it is worth looking at what
> standard example 12 (examples/c/x12c.c) does.  It first plots
> a box with default cmap0 colour (red).  Then it does the
> following two commands:
>
> plcol0( 2 );
> pllab( "Year", "Widget Sales (millions)", "#frPLplot Example 12" );
>
> That first command changes the colour to yellow, and the second plots
> those strings in that designated colour.  So far, so good.
>
> Then it goes through a loop which contains calls to plcol1 with
> changing argument. Although the loop plot commands include both fills
> and text, only the fills seem to be affected by the plcol1 call, _BUT_
> the text comes out as red.  I am virtually positive that is a bug
> in the core PLplot library.
>
> I suppose one possibility is the text should be in the current
> (yellow) cmap0 colour, but I think behind the scenes the two colour
> maps are setting the same ultimate colour in two different ways so I
> think what should happen here is the text should also be displayed in
> the cmap1 colour in that loop.  We need a volunteer to look carefully
> at our core colour code to figure this out with a reliable device (
> probably anything but the AGG version of wxwidgets, see below).

Out of curiosity, I looked further into this, and all is well in our
basic colour handling.  plcol0 and plcol1 are designed to produce
equivalent results for text and line colours.

From the code in src/plctrl.c, both plcol0 and plcol1 set
plsc->curcolor.[rgba].  Then if you look at well-maintained drivers
such as svg.c, it refers exclusively to curcolor.[rgba] except when
setting the background colour.  For example, when it writes text is
does this.  Then I looked more closely at example 12, and there is a
call to plcol0(1) in plfbox to force the text to be red (which
explains that result which was puzzling me).  If you temporarily
remove that call, then the plcol1 call in the loop controls curcolor,
and the result is the text matches the fill colours.

That is the expected behaviour, and it some driver doesn't produce
text and lines that follow whatever colour is specified by the last
call to _either_ plcol0 or plcol1, then it is a driver bug.

Phil, I think you have already come to similar conclusions.  Having
just read through our colour documentation, do you have a suggestion
about where we could make the equivalence of plcol0 and plcol1 for
setting the colour of text and lines a lot clearer?

Also, you apparently spotted a bug in the wxwidgets code where it
refers to cmap0 rather than curcolor.  I confirm that with the
following command that shows there are lots of instances of this bug.

software@raven> grep cmap0 drivers/wxwidgets* |wc -l
28

Could you send a patch to fix that in all places other than where the
background is set?

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
__________________________