On 2015-06-10 19:58-0400 Jim Dishaw wrote: >> On Jun 10, 2015, at 3:57 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
>> I am sufficiently concerned by your explanation of this fix above that >> I am now beginning to wonder a bit if it was necessary. Of course, I >> could be just missing something, but I would appreciate a fuller >> explanation of the fix to make sure of its necessity. >> > > The fix is still necessary to replay the plot buffer with a device that uses char strings vice the Unicode string. In EscText there are two different ways of storing strings. Hi Jim: Thanks for that additional explanation. To be clear about that, input strings in PLplot are a null-terminated series of bytes that unicode-unaware devices use directly, and those are always also transformed to a known-length array of 32-bit integers that unicode-aware devices use. And I guess I can see why you want to store both results in the buffer rather than recreating the known-length array from the null-terminated series of bytes for each resizing event. Anyhow, if previously you were ignoring the NULL termination on the representation using a series of bytes, that is indeed a bug, and I am glad you fixed it. > Without the patch text strings could show random characters on redraw events. With this patch all the strings display correctly on resize events. I never noticed character problems like that when resizing -dev xwin, but my eye may have just missed it. Just to confirm that I just now played a lot with resizing of examples/c/x01c -dev xwin for 5.10.0, 5.11.0, and git master tip (including your recent commit), and I found no specific string issues for any of those cases. So it appears hard (at least with this example) to demonstrate a rendering bug due to this issue that you just fixed, but your fix seems logical to me (now) and certainly does not introduce any bad string rendering that I can spot. However, when doing those checks I did notice other resizing issues that do need to be addressed. 1. As a resize is occurring (typically by dragging one edge or one corner of the GUI to make the whole thing smaller or larger) sometimes the displayed GUI is a scaled plot and sometimes it is black (which is OK). But on some occasions when I stop resizing (by releasing the mouse button) the result remains black for 5.11.0 and the master tip version (which is not OK). But 5.10.0 is fine in this regard. So this issue is a regression introduced into PLplot between 5.10.0 and 5.11.0 and probably due to the flurry of changes you and Phil made in plbuf before we released 5.11.0. Please verify the good result for 5.10.0 and bad result for 5.11.0, git bisect to figure out what commit has caused the issue, and then make the appropriate plbuf fix to get rid of this regression. 2. For certain rare patterns of resizing the displayed plot results are not scaled properly to fit into the resized GUI so that the plot is larger than the resized GUI and clipped at its edges. Changing the resizing slightly immediately fixes the issue completely. The badly scaled result is rare so you sometimes have to play around with resizing a minute or so until you see it. This effect is seen in all versions of PLplot that I tested. So this issue is a long-standing bug in -dev xwin or else the plbuf code rather than a recently introduced regression. To help pin this long-standing bug down further, please check if it also occurs for either/both wingcc or your new GDI device. If so then this is probably a long-standing plbuf bug you will want to address with much higher priority (since it likely affects all interactive results that are displayed with the help of plbuf) than a bug in just -dev xwin. 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 __________________________ ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
