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
__________________________
------------------------------------------------------------------------------
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
