> On Jul 30, 2015, at 3:21 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
>
>> 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 the
> XOpenDisplay() 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
That patch fixes the problem when PLPlot is creating the window. Try adding one
more inside the "then" case at line 1983.
> 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.
>
That would work and we wouldn't be any worse off then we were before.
> 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>
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
