On 2009-08-23 18:40+0100 Andrew Ross wrote:
> On Sat, Aug 22, 2009 at 06:42:21PM -0700, Alan Irwin wrote:
>> On 2009-08-22 16:57-0500 Hezekiah M. Carty wrote:
>>
>>>
>>> I do not have a working Ada install yet, so I can not test the effect [of
>> this patch]
>>> this has on the Ada bindings. I can, however, call plscmap0n with 0,
>>> negative and positive values before calling plinit from OCaml,
>>> resulting in a proper palette of colors.
>>>
>>> If it works for you and/or others I will go ahead and commit the change.
>>
>> The patch solves the Ada colour initialization problems for me. However,
>> the
>>
>> if (ncol0 == 0 || first_allocation == TRUE) {
>> plspal0("");
>> }
>>
>> logic in plscmap0n is going to sometimes have quite a different effect than
>> the old logic that always initialized colours for the part of the cmap0
>> palette that was expanded from the previous call. For example, for the old
>> logic if the users code called plscmap0n(3), made some changes to the first
>> 3 colours, then followed by plscmap0n(13), the expanded colours (i.e., the
>> 4th through 13th colours) would get properly initialized to their default
>> values without messing with the first 3 colours. For the new logic the
>> expanded colours will just be red. I am having a hard time wrapping my head
>> around all the implications of the above if statement so there may be other
>> user scenarios where the results are different than before.
>>
>> Therefore, I think we should do something that mimics the effect of the old
>> plscmap0n code much better. The current coding logic is already pretty
>> messy because plspal0 calls plscmap0n and vice versa and adding logic to
>> plspal0 so that it only overwrites the expanded range of cmap0 indices is
>> only going to make it worse. Thus, perhaps the best way out of this mess is
>> to go back to what I said I didn't want before which is hard-coded colours
>> set inside plcmap0_def (but this time with a comment they must be consistent
>> with data/cmap0_default.pal).
>>
>> If upon reflection you (and others here who are interested) also feel the
>> safest thing to do is go back to hard-coded colours, I am willing to take
>> your patched version of plctrl.c and do the editing of plscmap0n (to remove
>> the call to plspal0) and plcmap0_def (to put back the default colours) but
>> otherwise leave your patched version alone (e.g., the is_cmap0_ready logic
>> which I like better than the previous logic) to make up for the wasted work
>> I caused you. :-)
>>
>> Let me know what you think.
>
> Let's not have a mix of palette files and hard coded otherwise it will produce
> very unexpected results where the user has changed the default palette from
> that hard coded into plplot. It may need a little more thought but the right
> solution is definitely to disentagle and loops from plspal / plscmap0n.
>
Thanks, Andrew, for your thoughts on this. Motivated by your strong vote for
a pure palette file approach, I believe I have thought of a nice way to
implement that. Implement a static function cmap0_palette_read (consisting of
most of the code in plspal0 now) that reads/checks the cmap0 palette files
and which returns r,g,b,a data without messing with cmap0. plsscmap0n calls
plcmap0_def which is updated (if imin <= imax) to call cmap0_palette_read to
always fill in the r,g,b,a data from imin to imax with default colours. An
updated version of plspal0 merely calls cmap0_palette_read, optionally calls
plsscmap0n to establish a cmap0 of the right size, and copies the r,g,b,a
data delivered by cmap0_palette_read to cmap0.
Note with this approach we don't need logic to avoid potential recursion
issues (since plsscmap0n does not call plspal0) and we go back to exactly
the behaviour we had before for plsscmap0n but implemented using a pure
palette file approach.
I will try my hand at implementing this approach today, and if it works
without problems I will commit it. I will check the list periodically today
if you have some additional advice about this approach (the best way to
handle the r,g,b,a data returned by cmap0_palette_read, for example).
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); PLplot scientific plotting software
package (plplot.org); 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
__________________________
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
