Content-Type: multipart/alternative; boundary="-679638972-1971002086-1353108007=:19755" ---679638972-1971002086-1353108007=:19755 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable Thanks (yet again) Andrew=0AThat will presumably again let AGG use subpixel= accuracy (if it is supported in the rest of the code).=0A=A0=0AI've attach= ed a suggestion for a change to the arrow scale algorithm. It is just a sug= gestion though - it's not exactly clever, but it worked for my situation. I= t's basically the same as yours, but it only checks adjacent points and tri= es to distinguish between the x and y direction.=0A=A0=0AWhat are your thou= ghts on the best output scheme for the interactive drivers? If we come up w= ith a standard I'll happily have a look at the wxwidgets driver.=0A=A0=0ATh= anks and have a good weekend=0A=A0=0APhil=0A =0A=0A________________________= ________=0A From: Andrew Ross =0ATo: phil= rosenberg =0ACc: "plplot-devel@lists.sourcefo= rge.net" =0ASent: Friday, 16 November = 2012, 21:07=0ASubject: Re: [Plplot-devel] poor vectors when using wxwidgets= =0A =0A=0APhil,=0A=0AYour original patch didn't quite work ok. Just callin= g plP_setphy with =0Asmall values (like 800x600) produced problems with som= e plots due to the =0Alimited resolution. I noticed this with the dotted co= ntour lines on =0Aexample 22. I've slightly tweaked your original patch to = scale these =0Avalues up as several of the other drivers do. This still see= ms to fix the =0Adistorted vector problem, but also fixes the contours agai= n. Perhaps you =0Acan test this (I've committed to svn)?=0A=0AAndrew=0A=0AO= n Wed, Nov 14, 2012 at 03:12:54AM -0800, phil rosenberg wrote:=0A> Hi Andre= w=0A> ?=0A> With the wxWidgets driver after applying the patch it uses the = values?provided by?plspage() - I think this should be the default behaviour= if plspage() has been called.=0A> ?=0A> If plspage() hasn't been called th= en common_init() calls plspage() with?default page size of 800 pixels wide = by 600 pixels high?and all other params of zero. In this case the page is p= lotted and only part of the plot is shown if the window is too small - no a= ttempt to resize the plot occurs. =0A> ?=0A> Perhaps a better option for wx= Widgets would be if the page size hasn't been set by the user with plspage = do not make any changes to it in?common_init() and instead move this code t= o the plD_esc_wxwidgets()? PLESC_DEVINIT case (or a virtual function called= from here for the different backends).??Until this point the driver doesn'= t have a canvas to draw on so page dimensions are useless anyway and from t= his point onwards the driver has access to the actual size of the canvas so= can?call plspage with sensible values.=0A> ?=0A> I'm not sure how the othe= r drivers you list get their canvas - but maybe expected behaviour could be= if plspage() is called before plinit() use the user's page size and plot p= art of the page if the window is too small or if plspage hasn't been called= then the driver should call plspage() itself at the earliest opportunity w= ith the actual window dimensions and should not use a "default size".=0A> ?= =0A> The only problem with this strategy is that calling plspage after sett= ing the device might give odd results? There is a warning however if plspag= e() is called after plinit() so maybe we could live with this.=0A> ?=0A> Ph= il=0A> ?=0A>=A0 =0A> =0A> ________________________________=0A>=A0 From: And= rew Ross =0A> To: phil rosenberg =0A> Cc: "plplot-devel@lists.sourceforge.net" =0A> Sent: Wednesday, 14 November 2012, 10:11= =0A> Subject: Re: [Plplot-devel] poor vectors when using wxwidgets=0A>=A0 = =0A> =0A> Phil,=0A> =0A> Thanks for the patch. Before applying I decided to= try the same thing=0A> on other drivers.=0A> =0A> xwin - behaves the same = as wxwidgets, i.e. it rescales the plot to fit=0A> the page and distorts ve= ctors (also text too so this is not a sensible=0A> thing to do with xwin)= =0A> =0A> qtwidget - maintains the aspect ratio of the plot and scales it t= o fit=0A> in the window=0A> =0A> xcairo - makes no attempt to rescale the p= lot, so it may or may not=0A> still fit in the window if the window size is= changed.=0A> =0A> All this behaviour is rather inconsistent. It would be n= ice if the=0A> main interactive drivers behaved in a similar way. What shou= ld that=0A> behaviour be?=0A> =0A> Andrew=0A> =0A> On Tue, Nov 13, 2012 at = 05:04:10PM -0800, phil rosenberg wrote:=0A> > It turns out I've managed to = solve my own problem. The wxWidgets driver was calling plP_setphy with cons= tant values irrespective of the actual width and height of the window. I've= replaced the constants with dev->width and dev->height which were assigned= from pls->xlength and pls->ylength (which are int turn set by either a use= r or default call to plspage). I could see an argument for using higher res= olution for AGG which has subpixel accuracy, but at least with this patch t= he distortions have been removed.=0A> > ?=0A> > This fixes the arrows and a= xes distances.=0A> > ?=0A> > Patch attached - tested on all three wxwidget = backends.=0A> > ?=0A> > Phil=0A> >? =0A> > =0A> > _________________________= _______=0A> >? From: phil rosenberg =0A> > To: = "plplot-devel@lists.sourceforge.net" = =0A> > Sent: Tuesday, 13 November 2012, 23:20=0A> > Subject: poor vectors w= hen using wxwidgets=0A> >? =0A> > =0A> > Hi=0A> > I've just been looking at= using the plvect function to add vectors to a plot. Unfortunately they are= not coming out well. Attached is a simple example with [1,1] vectors plott= ed at every integer from 0-9 in x and y. You can see that the arrow heads a= re distorted. I've traced this through the code and found that it's because= the? plot is scaled independantly in x and y in the wxWidgets driver (in t= his case in wxPLDevGC::DrawPolyline() ). This scaling AFTER the rotation of= the arrow causes distortion.=0A> > =0A> > I'm not fully familiar with the = plplot transformations from world to device coordinates, but I thought that= this should be performed by plP_wcpcx()? Does anyone have any idea what co= uld be going wrong here so I'm not debugging from scratch? Am I doing somet= hing wrong during initialisation?=0A> > =0A> > By the way, I thik this is r= elated to another problem that I've experienced (but hadn't gotten round to= reporting) where my y axis title moves further and further away from the y= axis as I make my plot window wider.=0A> > =0A> > Any help much appreciate= d.=0A> > =0A> > Phil=0A> =0A> =0A> > --------------------------------------= ----------------------------------------=0A> > Monitor your physical, virtu= al and cloud infrastructure from a single=0A> > web console. Get in-depth i= nsight into apps, servers, databases, vmware,=0A> > SAP, cloud infrastructu= re, etc. Download 30-day Free Trial.=0A> > Pricing starts from $795 for 25 = servers or applications!=0A> > http://p.sf.net/sfu/zoho_dev2dev_nov=0A> =0A= > > _______________________________________________=0A> > Plplot-devel mail= ing list=0A> > Plplot-devel@lists.sourceforge.net=0A> > https://lists.sourc= eforge.net/lists/listinfo/plplot-devel ---679638972-1971002086-1353108007=:19755 Content-Type: text/html; charset=iso-8859-1 Content-Transfer-Encoding: quoted-printable
Thanks (yet again) An= drew
That will presumably again let AGG use subpixel= accuracy (if it is supported in the rest of the code).
 
I've attached a suggestion for a change t= o the arrow scale algorithm. It is just a suggestion though - it's not exac= tly clever, but it worked for my situation. It's basically the same as your= s, but it only checks adjacent points and tries to distinguish between the = x and y direction.
 
Wha= t are your thoughts on the best output scheme for the interactive drivers? = If we come up with a standard I'll happily have a look at the wxwidgets dri= ver.
 
Thanks and have a= good weekend
 
Phil

From: Andrew Ross <andrewross@users.source= forge.net>
To: phil= rosenberg <philip_rosenberg@yahoo.com>
Cc: "plplot-devel@lists.sourceforge.net" <plplot= -devel@lists.sourceforge.net>
Sent: Friday, 16 November 2012, 21:07
Subject: Re: [Plplot-devel] poor vectors when using wxwi= dgets


Phil,

Your original patch didn't qu= ite work ok. Just calling plP_setphy with
small values (like 800x600) p= roduced problems with some plots due to the
limited resolution. I notic= ed this with the dotted contour lines on
example 22. I've slightly twea= ked your original patch to scale these
values up as several of the othe= r drivers do. This still seems to fix the
distorted vector problem, but= also fixes the contours again. Perhaps you
can test this (I've committ= ed to svn)?

Andrew

On Wed, Nov 14, 2012 at 03:12:54AM -0800, = phil rosenberg wrote:
> Hi Andrew
> ?
> With the wxWidget= s driver after applying the patch it uses the values?provided by?plspage() = - I think this should be the default behaviour if plspage() has been called= .
> ?
> If plspage() hasn't been called then common_init() calls plspage() with?default page size of 800 pixels wide by= 600 pixels high?and all other params of zero. In this case the page is plo= tted and only part of the plot is shown if the window is too small - no att= empt to resize the plot occurs.
> ?
> Perhaps a better option = for wxWidgets would be if the page size hasn't been set by the user with pl= spage do not make any changes to it in?common_init() and instead move this = code to the plD_esc_wxwidgets()? PLESC_DEVINIT case (or a virtual function = called from here for the different backends).??Until this point the driver = doesn't have a canvas to draw on so page dimensions are useless anyway and = from this point onwards the driver has access to the actual size of the can= vas so can?call plspage with sensible values.
> ?
> I'm not sur= e how the other drivers you list get their canvas - but maybe expected beha= viour could be if plspage() is called before plinit() use the user's page size and plot part of the page if the window is too small or if plspa= ge hasn't been called then the driver should call plspage() itself at the e= arliest opportunity with the actual window dimensions and should not use a = "default size".
> ?
> The only problem with this strategy is th= at calling plspage after setting the device might give odd results? There i= s a warning however if plspage() is called after plinit() so maybe we could= live with this.
> ?
> Phil
> ?

> > ________________________________
>  From: Andrew Ross <= ;andrewross@users.sourceforge.net>
&= gt; To: phil rosenberg <philip_rosenberg@yahoo.com&= gt;
> Cc: "plplot-devel@lists.s= ourceforge.net" <plplot-devel@lists= .sourceforge.net>
> Sent: Wednesday, 14 November 2012, 10:11<= br>> Subject: Re: [Plplot-devel] poor vectors when using wxwidgets
&g= t; 
>
> Phil,
>
> Thanks for the patch. Be= fore applying I decided to try the same thing
> on other drivers.
= >
> xwin - behaves the same as wxwidgets, i.e. it rescales the pl= ot to fit
> the page and distorts vectors (also text too so this is n= ot a sensible
> thing to do with xwin)
>
> qtwidget - ma= intains the aspect ratio of the plot and scales it to fit
> in the wi= ndow
>
> xcairo - makes no attempt to rescale the plot, so it = may or may not
> still fit in the window if the window size is changed.
>
> All this behaviour is rather inconsistent. It wo= uld be nice if the
> main interactive drivers behaved in a similar wa= y. What should that
> behaviour be?
>
> Andrew
> <= br>> On Tue, Nov 13, 2012 at 05:04:10PM -0800, phil rosenberg wrote:
= > > It turns out I've managed to solve my own problem. The wxWidgets = driver was calling plP_setphy with constant values irrespective of the actu= al width and height of the window. I've replaced the constants with dev->= ;width and dev->height which were assigned from pls->xlength and pls-= >ylength (which are int turn set by either a user or default call to pls= page). I could see an argument for using higher resolution for AGG which ha= s subpixel accuracy, but at least with this patch the distortions have been= removed.
> > ?
> > This fixes the arrows and axes distan= ces.
> > ?
> > Patch attached - tested on all three wxwidget backends.
> > ?
> > Phil
> >? > >
> > ________________________________
> >? Fr= om: phil rosenberg <philip_rosenberg@yahoo.com><= br>> > To: "plplot-devel@lists.sourc= eforge.net" <plplot-devel@lists.sou= rceforge.net>
> > Sent: Tuesday, 13 November 2012, 23:20> > Subject: poor vectors when using wxwidgets
> >?
&g= t; >
> > Hi
> > I've just been looking at using the p= lvect function to add vectors to a plot. Unfortunately they are not coming = out well. Attached is a simple example with [1,1] vectors plotted at every integer from 0-9 in x and y. You can see that the arrow heads are distorte= d. I've traced this through the code and found that it's because the? plot = is scaled independantly in x and y in the wxWidgets driver (in this case in= wxPLDevGC::DrawPolyline() ). This scaling AFTER the rotation of the arrow = causes distortion.
> >
> > I'm not fully familiar with t= he plplot transformations from world to device coordinates, but I thought t= hat this should be performed by plP_wcpcx()? Does anyone have any idea what= could be going wrong here so I'm not debugging from scratch? Am I doing so= mething wrong during initialisation?
> >
> > By the way,= I thik this is related to another problem that I've experienced (but hadn'= t gotten round to reporting) where my y axis title moves further and furthe= r away from the y axis as I make my plot window wider.
> >
>= ; > Any help much appreciated.
> >
> > Phil
>
>
> > --------------------------------------= ----------------------------------------
> > Monitor your physical= , virtual and cloud infrastructure from a single
> > web console. = Get in-depth insight into apps, servers, databases, vmware,
> > SA= P, cloud infrastructure, etc. Download 30-day Free Trial.
> > Pric= ing starts from $795 for 25 servers or applications!
> > http://p.sf.net= /sfu/zoho_dev2dev_nov
>
> > ___________________________= ____________________
> > Plplot-devel mailing list
> > Plplot-devel@lists.sourceforge.net
&g= t; > https://lists.sourceforge.net/lists/listinfo/plplot-deve= l


---679638972-1971002086-1353108007=:19755--