I fixed the compilation error on cairo.c and I am working on a fix to cairo so
that it actually resizes the plot (at least for xcairo, not sure when I can fix
wincairo) when the window changes size.
I will also take a look at xwin when I get a chance. I think the problem has
to do with the sequencing of the events.
I pushed the changes to the repository.
> On Jun 20, 2015, at 3:45 AM, Alan W. Irwin <ir...@beluga.phys.uvic.ca> wrote:
>
> On 2015-06-15 12:24-0400 Jim Dishaw wrote:
>
>> Attached is a patch series that implements the second solution. I
> tested the changes to xwin driver; however, I was not able to test
> tkwin, qt, or cairo. I will provide an update to wingcc separately. I didn’t
> touch the wxwidgets driver.
>
>> The xwin driver occasionally misses some resizes, but I think that is
> some quirky behavior that existed prior to 5.10.
>
>> If someone could test the tkwin, qt, and cairo (specifically xcairo)
> that would be greatly appreciated.
>
> Hi Jim:
>
> As promised I finally have had a chance to test this patch series. It
> applies cleanly (aside for some white space issues that are
> automatically cleaned up by git) to a private topic branch based on
> git master tip. Also, I encountered no obvious issues with builds
> (other than the easily fixed cairo issue below).
>
> N.B. So once you have fixed the cairo build issue please go ahead and
> push this result as well as your other result involving wingcc
> (assuming you have testing resizing with that device).
>
> Here are some specific comments with respect to resize issues still
> encountered with the various device drivers I tested typically using the
>
> examples/c/x08c -dev <interactive device>
>
> command for various interactive devices.
>
> * qtwidget
>
> The resizing results seem _almost_ perfect to me. No black screen,
> graphical and text results scaled properly no matter how much I
> dragged the corner of the qtwidget GUI around my desktop. However, if
> I drag from a large size _rapidly to a small one, there is often no
> response, and I had to repeat the process with a slower drag. I
> believe this is what you referred to above (for the xwin device) as
> missing some resizes. Presumably this is a long-standing issue we
> should address some day. Aside from this one issue, in my opinion the
> behavior of this device on resize events should be the paradigm for
> all other interactive devices.
>
> In particular, for me text scaling on resize events is the right thing
> to do, but from recent list traffic I am still in the process of
> convincing Phil on that issue for the wxwidgets device and you on that
> issue for the new GDI device. :-) But if either of you try qtwidget,
> I think those nice scaled text results should convince you to at least
> provide a (default) option to do text scaling on resize events for the
> wxwidgets and new GDI device cases.
>
> * tk
>
> This device (although it uses ugly Hershey fonts rather than system
> fonts like qtwidget) has perfect resizing of graphics and text. And
> despite maximum violence of my mouse moves, I could not get it to miss
> any resizes (unlike qtwidgets above). However, it is not a good
> candidate for a paradigm of a typical interactive device driver
> because of all the complex interactions with Tcl, Tk, and the xwin
> device.
>
> * xwin
>
> Your fix has solved the black screen issue I reported for this device.
> and like the tk device (which is not surprising because they share
> access to some xwin features) I cannot get it to miss resizes (unlike
> what you reported above unless I am misinterpreting what you said).
> However, the scaling and centering of graphics and text is out of
> synch with the resize event, i.e., it reflects the size of the last
> GUI rather than present GUI as you should be able to prove by making a
> single large change in GUI size and releasing the mouse without
> further movement. I presume the problem here is the xwin device is
> updating the scale and size of the result using data collected prior
> to the resizing event rather than at the correct time after that event
> so the results always reflect those incorrect prior GUI sizes. If you
> can quickly figure out a fix for this specific xwin bug (presumably in
> existence for a long time), please push it, but otherwise we can
> continue to live with it.
>
> * tkwin
> The only way you can exercise this "device" is with the wish technique
> for the runAllDemos example documented in examples/tk/README.tkdemos
> and which is also run automatically (and with all dependencies
> satisfied) using
>
> make test_wish_runAllDemos
>
> There has been something wrong with this example for a while now (it
> warns about, e.g.,
>
> x08 invalid command name
>
> when you hit the button for the 8th example). So although the GUI
> exists and you can resize it, the plot window subset of that GUI
> remains blank so you cannot currently see if there are any issues with
> plot resizing with the tkwin "device".
>
> * xcairo
>
> Your change produces the following build error
>
> /home/software/plplot/HEAD/plplot.git/drivers/cairo.c: In function
> ‘plD_wait_xcairo’:
> /home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2149:5: error:
> ‘event_mask’ undeclared (first use in this function)
> /home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2149:5: note: each
> undeclared identifier is reported only once for each function it appears in
> /home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2154:41: error: ‘event’
> undeclared (first use in this function)
> /home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2158:13: error:
> ‘number_chars’ undeclared (first use in this function)
> /home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2158:65: error:
> ‘event_string’ undeclared (first use in this function)
> /home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2158:84: error:
> ‘keysym’ undeclared (first use in this function)
> /home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2158:93: error: ‘cs’
> undeclared (first use in this function)
> /home/software/plplot/HEAD/plplot.git/drivers/cairo.c:2177:13: error:
> ‘expose’ undeclared (first use in this function)
> make[3]: *** [drivers/CMakeFiles/cairo.dir/cairo.c.o] Error 1
> make[2]: *** [drivers/CMakeFiles/cairo.dir/all] Error 2
> make[1]: *** [drivers/CMakeFiles/cairo.dir/rule] Error 2
> make: *** [cairo] Error 2
>
> I believe the problem is you left your declarations in the wrong function.
> This
> patch fixes that issue:
> diff --git a/drivers/cairo.c b/drivers/cairo.c
> index c3e949a..c7f2ba9 100644
> --- a/drivers/cairo.c
> +++ b/drivers/cairo.c
> @@ -2084,13 +2084,6 @@ void plD_bop_xcairo( PLStream *pls )
>
> void plD_eop_xcairo( PLStream *pls )
> {
> - int number_chars;
> - long event_mask;
> - char event_string[10];
> - KeySym keysym;
> - XComposeStatus cs;
> - XEvent event;
> - XExposeEvent *expose;
> PLCairo *aStream;
>
> aStream = (PLCairo *) pls->dev;
> @@ -2139,6 +2132,13 @@ void plD_tidy_xcairo( PLStream *pls )
>
> void plD_wait_xcairo( PLStream *pls )
> {
> + int number_chars;
> + long event_mask;
> + char event_string[10];
> + KeySym keysym;
> + XComposeStatus cs;
> + XEvent event;
> + XExposeEvent *expose;
> PLCairo *aStream;
>
> aStream = (PLCairo *) pls->dev;
>
> After that change, the cairo device built without issues. However,
> after applying the above patch to your work, the plD_eop_xcairo function is
> reduced
> just to
>
> void plD_eop_xcairo( PLStream *pls )
> {
> PLCairo *aStream;
>
> aStream = (PLCairo *) pls->dev;
>
> // Blit the offscreen image to the X window.
> blit_to_x( pls, 0.0, 0.0, pls->xlength, pls->ylength );
>
> if ( aStream->xdrawable_mode )
> return;
> }
>
> and I assume you want to do more than the default return at the end of
> the function when that last if condition is NOT satisfied.
>
> The most important problem with the response to resize events for
> xcairo is that it is essentially nonexistent. The same plot with
> exactly the same size gets replotted so either it is smaller than the
> GUI window if you have resized larger or else it is too large for the
> GUI window (and clipped off at the edges of the GUI) if you have
> resized smaller. If you can find an easy fix for this apparently
> long-standing issue, that would be great, but otherwise we can just
> live with it until some regular user of xcairo gets fed up with this
> poor resize result.
>
> * wincairo
>
> This is a windows equivalent of xcairo so I was unable to test it, but
> presumably it needs work to deal with resizing events. I am not sure
> whether wincairo will be available on Cygwin, but it should be available
> on MSVC if you download and install GTK+ for Windows on that platform.
>
> *ntk
>
> This is an important Tk device because it is completely independent of
> X (and, for example, therefore executes much faster than the tk device
> on Cygwin which does depend on X). The ntk device obviously needs
> work to deal properly with resizing events since, for example, there
> is the same lack of resizing capability as for xcairo.
>
> 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
> __________________________
------------------------------------------------------------------------------
Monitor 25 network devices or servers for free with OpManager!
OpManager is web-based network management software that monitors
network devices and physical & virtual servers, alerts via email & sms
for fault. Monitor 25 devices for free with no restriction. Download now
http://ad.doubleclick.net/ddm/clk/292181274;119417398;o
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
