Re: [Plplot-devel] Need help with test_extXdrawable target regression introduced by "Fix to the multiple keypress bug on page advance"

[Jim D. <ji...@di...>]

> On Jul 30, 2015, at 3:21 AM, Alan W. Irwin <ir...@be...> wrote:
> 
>> On 2015-07-30 01:08-0400 Jim Dishaw wrote:
>> 
>> 
>>> On Jul 29, 2015, at 7:56 PM, Alan W. Irwin <ir...@be...> 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>