On 2015-07-30 01:08-0400 Jim Dishaw wrote:
On Jul 29, 2015, at 7:56 PM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote: Hi Jim: I have just discovered the regression mentioned by the subject line. My apologies for not spotting this issue earlier in the release cycle. I guess I did all sorts of spot checking after your multiple keypress changes to make sure the cairo device driver built and ran without issues, but I did not test all cairo capabilities like a simple build of the test_interactive target (which caught this problem now) would have done at the time.
The interesting thing is that at least one of the sources for the
error message is in the plD_init_xcairo() function. The XInternAtom() call generates some of the messages. Furthermore, the XCloseDisplay() in plD_tidy_xcairo() generates the error message. I thought it might be due to a synchronization issue with the X server, so I put an XSync() call to make sure everything was processed in the event queue. Unfortunately, the error “migrated” to the XSync() call. I then enabled synchronization via XSynchronize() (the sledgehammer approach). That eliminated some of the runtime error messages.
I think this bug is a latent problem that has not cropped up
earlier. I am not quite sure of the root cause, but I don’t think 78344df is the cause, rather it exposed the problem.
I am not familiar enough with the external drawable functionality
and, unfortunately, I don’t have time to dig into right now. If you insert "XSynchronize( aStream->Display, TRUE );” some where after theXOpenDisplay() call, I think that will fix the bug for this release. I will revisit the issue after the weekend.
I inserted the following change (which is what I think you meant
by the above suggestion, but please confirm that.
--- a/drivers/cairo.c
+++ b/drivers/cairo.c
@@ -1995,6 +1995,7 @@ void plD_init_xcairo( PLStream *pls )
plexit( "Failed to open X Windows display\n" );
// some sort of error here
}
+ XSynchronize( aStream->XDisplay, TRUE );
XScreen = DefaultScreen( aStream->XDisplay );
rootWindow = RootWindow( aStream->XDisplay, XScreen );
If that is what you had in mind, that change does not seem to affect the
ordinary use of xcairo or
the results from building the test_extcairo target. However, building
the test_extXdrawable target still generates the same error message,
i.e.,
Scanning dependencies of target test_extXdrawable
The program 'extXdrawable_demo' received an X Window System error.
This probably reflects a bug in the program.
The error was 'BadWindow (invalid Window parameter)'.
(Details: serial 178 error_code 3 request_code 2 minor_code 0)
(Note to programmers: normally, X errors are reported asynchronously;
that is, you will receive the error a while after causing it.
To debug your program, run it with the --sync command line
option to change this behavior. You can then get a meaningful
backtrace from your debugger if you break on the gdk_x_error() function.)
make[3]: *** [examples/CMakeFiles/test_extXdrawable] Error 1
make[2]: *** [examples/CMakeFiles/test_extXdrawable.dir/all] Error 2
make[1]: *** [examples/CMakeFiles/test_extXdrawable.dir/rule] Error 2
make: *** [test_extXdrawable] Error 2
Jim, since the above idea does not appear to work do you see any issue
with instead reverting your changes just for the cairo device driver
using the attached patch?
That patch is, of course, just a temporary measure until you can look
in more detail at this whole problem post-release, but it does seem to
give good results for all of the test_c_xcairo, test_extcairo, and
test_extXdrawable targets consistent with what we had before for 5.11.0.
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
__________________________
cairo.patch.gz
Description: patch reverting Jim's cairo fixes
------------------------------------------------------------------------------
_______________________________________________ Plplot-devel mailing list Plplot-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/plplot-devel
