From: Alan W. I. <ir...@be...> - 2011-05-02 01:51:24
|
The ability mentioned in the subject line is an unpublished PLplot feature that I have used recently for the -colorbar subset of C example 33. Since this is an unpublished feature (the documentation says plscolbg should be called before plinit), I have tried example 33 (using the -colorbar option) for a number of different devices. All the modern devices I have tried (xcairo, qt_widget, psc, wxwidgets, svg) work fine with the specified different background colour starting on the first page of the -colorbar pages (the fifth page of example 33 if the -colorbar example option is used), but -dev xwin (and -dev tk which uses -dev xwin code) do not work properly. For those devices the -colorbar pages of example 33 initially have black backgrounds rather than the specified (unsaturated green) background. However, you get the correct background if you resize the plot. Also, if you attempt to resize page 4 the initially correct black background for that page is turned into the background colour appropriate to page 5. pladv(0) is largely equivalent to a call to pleop() followed by a call to plbop(). Thus, I suspect the trouble might be that -dev xwin handles end of page and beginning of page with a different style than the modern devices, e.g., by not setting the background colour properly at the correct place. Could somebody with knowledge of -dev xwin take a look to see if it can be brought into line with the style of modern devices with regard to page and background colour handling? The ability to set different background colours for different pages of a multi-page plot is well worth publicizing since the ability is quite useful, but I would like to hold off on changing the plscolbg documentation until we completely understand (and fix) why -dev xwin (and -dev tk) don't respond the same way as modern devices to a call to plscolbg (just before a call to pladv(0) in the example 33 case). So I hope somebody with knowledge of -dev xwin will take on this issue. 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 __________________________ |
From: Andrew R. <and...@us...> - 2011-05-04 18:41:46
|
Alan, A simple change - now committed. Other devices explicitly set the background colour with each call to plD_bop_xw. Incidentally the old version worked with the -db option (double buffering) since the buffer pixmap was set to the background colour for each page, but the non-buffered version didn't work as in this case the background colour wasn't being set for each page. The xwin fix also fixes the tk device. Andrew On Sun, May 01, 2011 at 06:51:15PM -0700, Alan Irwin wrote: > The ability mentioned in the subject line is an unpublished PLplot > feature that I have used recently for the -colorbar subset of C > example 33. Since this is an unpublished feature (the documentation > says plscolbg should be called before plinit), I have tried example 33 > (using the -colorbar option) for a number of different devices. All > the modern devices I have tried (xcairo, qt_widget, psc, wxwidgets, > svg) work fine with the specified different background colour starting > on the first page of the -colorbar pages (the fifth page of example 33 > if the -colorbar example option is used), but -dev xwin (and -dev tk > which uses -dev xwin code) do not work properly. For those devices > the -colorbar pages of example 33 initially have black backgrounds > rather than the specified (unsaturated green) background. However, you > get the correct background if you resize the plot. Also, if you > attempt to resize page 4 the initially correct black background > for that page is turned into the background colour appropriate > to page 5. > > pladv(0) is largely equivalent to a call to pleop() followed by a call > to plbop(). Thus, I suspect the trouble might be that -dev xwin handles end > of page and beginning of page with a different style than the modern > devices, e.g., by not setting the background colour properly at the > correct place. Could somebody with knowledge of -dev xwin take a look > to see if it can be brought into line with the style of modern devices > with regard to page and background colour handling? > > The ability to set different background colours for different pages of > a multi-page plot is well worth publicizing since the ability is quite > useful, but I would like to hold off on changing the plscolbg > documentation until we completely understand (and fix) why -dev xwin > (and -dev tk) don't respond the same way as modern devices to a call > to plscolbg (just before a call to pladv(0) in the example 33 case). > So I hope somebody with knowledge of -dev xwin will take on this > issue. > > 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 > __________________________ > > ------------------------------------------------------------------------------ > WhatsUp Gold - Download Free Network Management Software > The most intuitive, comprehensive, and cost-effective network > management toolset available today. Delivers lowest initial > acquisition cost and overall TCO of any competing solution. > http://p.sf.net/sfu/whatsupgold-sd > _______________________________________________ > Plplot-devel mailing list > Plp...@li... > https://lists.sourceforge.net/lists/listinfo/plplot-devel > |
From: Alan W. I. <ir...@be...> - 2011-05-04 20:11:51
|
On 2011-05-04 19:41+0100 Andrew Ross wrote: > > Alan, > > A simple change - now committed. Other devices explicitly set the > background colour with each call to plD_bop_xw. Incidentally the > old version worked with the -db option (double buffering) since > the buffer pixmap was set to the background colour for each page, > but the non-buffered version didn't work as in this case the > background colour wasn't being set for each page. The xwin fix also > fixes the tk device. Hi Andrew: Thanks for solving the principal issue. However, the fix is still not quite right. If you use the -colorbar option and resize page 4 (the last of the pllegend pages, but not the earlier ones), then the background colour changes incorrectly to green. This also happens for -dev wxwidgets, but doesn't happen, e.g, for -dev xcairo or -dev qtwidget. So it is likely there is some difference in style between how colours are handled for resizes between the xwin and wxwidgets interactive devices on the one hand and the xcairo and qtwidget devices on the other. BTW, I am using the wxGC version of the wxwidgets device just in case that matters. 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 __________________________ |
From: Andrew R. <and...@us...> - 2011-05-06 20:24:11
|
On Wed, May 04, 2011 at 01:11:43PM -0700, Alan Irwin wrote: > On 2011-05-04 19:41+0100 Andrew Ross wrote: > >> >> Alan, >> >> A simple change - now committed. Other devices explicitly set the >> background colour with each call to plD_bop_xw. Incidentally the >> old version worked with the -db option (double buffering) since >> the buffer pixmap was set to the background colour for each page, >> but the non-buffered version didn't work as in this case the >> background colour wasn't being set for each page. The xwin fix also >> fixes the tk device. > > Hi Andrew: > > Thanks for solving the principal issue. However, the fix is still not > quite right. If you use the -colorbar option and resize page 4 (the > last of the pllegend pages, but not the earlier ones), then the > background colour changes incorrectly to green. This also happens for > -dev wxwidgets, but doesn't happen, e.g, for -dev xcairo or -dev > qtwidget. > > So it is likely there is some difference in style between how colours > are handled for resizes between the xwin and wxwidgets interactive > devices on the one hand and the xcairo and qtwidget devices on the > other. > > BTW, I am using the wxGC version of the wxwidgets device just in > case that matters. Hm. Well it seems that xwin code has some "quirks" to it. Currently the resize / redraw code calls plD_bop_xw to reset the page. This seems an overkill, for example it increases the page count. The problem is that it resets the background to the current background colour rather than the one originally used to produce the page (as you spotted). The code now caches the background colour at the start of the page and uses this for redraws / resizes. It seems to work ok for me. A further quirk that has come to light is that the xwin driver actually uses a single colourmap for all windows / streams, whereas plplot has individual colourmaps for each stream. This is only an issue if you have multiple windows and change the colours. I suspect this "feature" was initially for 8-bit displays and avoids the annoying flashing colours when you switched windows (anyone still remember that?) These days it is probably not really an issue. I'm tempted to clean this up to make a per stream colourmap. Any strong opinions? I've never actually encountered this problem, but I imagine for interactive use like octave it could potentially be an issue. Andrew |
From: Alan W. I. <ir...@be...> - 2011-05-06 21:44:03
|
On 2011-05-06 21:24+0100 Andrew Ross wrote: > [...] I suspect this "feature" was > initially for 8-bit displays and avoids the annoying flashing colours > when you switched windows (anyone still remember that?) I am afraid I do, but I usually don't admit to it. :-) Thanks for this -dev xwin cleanup. 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 __________________________ |
From: Maurice L. <mj...@br...> - 2011-05-07 00:40:59
|
On Friday, May 6, 2011 at 21:24:03 (+0100) Andrew Ross writes: > A further quirk that has come to light is that the xwin driver actually > uses a single colourmap for all windows / streams, whereas plplot has > individual colourmaps for each stream. This is only an issue if you have > multiple windows and change the colours. I suspect this "feature" was > initially for 8-bit displays and avoids the annoying flashing colours > when you switched windows (anyone still remember that?) These days it is > probably not really an issue. I'm tempted to clean this up to make a > per stream colourmap. Any strong opinions? > > I've never actually encountered this problem, but I imagine for > interactive use like octave it could potentially be an issue. It should definitely be changed to per-stream colormaps if you've got a hankerin' to do it. It's been an issue that did annoy me at times when using multiple plframe widgets in an application. -- Maurice LeBrun |