> On Jun 10, 2015, at 11:30 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: > > 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. >
I never was able to reproduce the problem reliably. It was working fine and then as I added features to the text processing in wingdi, the problem would manifest on some of the examples. > 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. > I think this problem is the plP_eop() that was inserted in the plRemakePlot() to make sure the BOP would perform as expected. For the GUI drivers this will trigger another wait for input, which ends up blocking redraw messages. I will verify by using git bisect. > 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. > The problem most likely is in the driver because plbuf is agnostic on the device dimension and scaling. I have a couple of guesses on the cause of this bug. I will investigate and see if I can patch. It will be good to look at xwin because I want to add the ability to open and save plot metafiles for the new version of plrender. I need to add menus and callback functions to the GUI drivers that plrender can use. My thought is to have a driver option that would enable that feature. ------------------------------------------------------------------------------ _______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
