On 2015-07-04 14:57-0400 Jim Dishaw wrote:
> As for example 17, what should the behavior be on a resize event?
Right now I play the back the entire buffer, which shows all the
rescalings. I think the correct behavior on a resize would be to
render the most recent frame.
Hi Jim:
I have (slightly) changed the subject line for this subtopic of your
post.
The answer to your question is you should model resizes for your new
device on what happens for -dev xwin. In that case, a resize during
the course of example 17 resizes the current version of the plot
(which is what I assume you mean by "the most recent frame") and then
continues from there.
As I have mentioned before there is still a long-standing resize
scaling bug for -dev xwin where the scaling is appropriate to the size
of the last resize rather than the current resize. So small resizes
look OK, but large ones do not. We can continue to live with this
long-standing bug if necessary in -dev xwin, but I hope your new
device does not have this issue so you will know the right fix for
-dev xwin and be able to get that fix into the forthcoming 5.11.1.
The other resizing issue I have remarked on before concerns the xcairo
device. The plD_eop_xcairo function currently reads as follows:
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 my concern is the last two statements in this function since they
make no difference, i.e., the return occurs regardless of whether
aStream->xdrawable_mode is true or not.
Note, that plD_bop_xcairo has a similar test of
aStream->xdrawable_mode, but in that case if aStream->xdrawable_mode
is true there is an immediate return and otherwise there is a call to
XFlush( aStream->XDisplay ) before the return. I am pretty sure that
same logic should be used in the above case as well so I tried that
change in hopes that it would solve the current resizing issues with
xcairo, but it made no difference and resizing for xcairo continues to
leave the scale and origin of the rendered graphics completely
unaffected. Nevertheless, I think this fix should be part of the
complete cure for this issue so I hope you will consider it when you
go ahead with your plan to fix this issue.
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
__________________________
------------------------------------------------------------------------------
Don't Limit Your Business. Reach for the Cloud.
GigeNET's Cloud Solutions provide you with the tools and support that
you need to offload your IT needs and focus on growing your business.
Configured For All Businesses. Start Your Cloud Today.
https://www.gigenetcloud.com/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
