On Mar 5, 2015, at 5:45 AM, Phil Rosenberg <p.d.rosenb...@gmail.com> wrote:
> I sort of agree. Sounds like a maintenance nightmare, plus, again, I thought
> that was the buffer's role - sit after major processing (e.g. After contour
> generation) but before device dependence, collecting commands which can be
> transferred to any device for repotting?
The buffer essentially sits right before the call to the driver. The
information stored in the buffer are in the device specific coordinate system.
The original purpose of the buffer was to redraw the window on a resize event.
The plot buffer can be brought up the hierarchy, but the tradeoff is reduced
performance on window redraws. Plus, as Maurice points out, the current code
architecture is not designed for a mid-level interface.
Consider the case of a dashed grid. The dash is specified as lengths in mm,
thus there will be a different of number of dashes for different physical
sizes. For example, in x01c I count ~2 horizontal dashes between vertical
ticks on the psc device, ~3 on the xwin device, ~2 on qtwidget, and ~2 on
cairo. When resizing the GUI windows, the number of dashes remains unchanged,
which violates the specified dash lengths.
While working on the code, my thinking has iterated over different solutions as
gained a better understanding of what is happening in the guts. There are two
basic directions that we can go with plbuf/plmeta.
1) Keep the current structure and live with the differences in rendering
Pro: Less change to the code, better performance on redraws
Con: Resized windows or rerendered plots might not be correct in appearance.
2) Move plbuf up in the architecture and make plmeta a very smart driver.
Pro: Plots would be rendered correctly (e.g. dash length) on redraws or when
output on different devices from a metafile.
Con: Redraw performance will be a bit less (probably not noticeable on most
machines), more change to the code
What I mean by a "very smart" driver is that it would be able to do all graphic
operations natively (e.g. dashed lines, pattern fills).
I think the second option is the right way to go and it is closest to what was
originally discussed when this effort started.
@Alan: I will update the documentation as requested.
>
> Phil
> From: Maurice LeBrun
> Sent: 05/03/2015 09:42
> To: Jim Dishaw
> Cc: PLplot development list
> Subject: Re: [Plplot-devel] plot metafile questions
>
> On Wednesday, March 4, 2015 at 12:56:22 (-0500) Jim Dishaw writes:
> >
> > On Mar 4, 2015, at 6:04 AM, "Alan W. Irwin" <ir...@beluga.phys.uvic.ca>
> > wrote:
> > > If you think that escape code trick should work as a way to transport
> > > raw user input directly to plmeta to be stored in the plmeta file, can
> > > you also use a similar trick to transport and store the relevant raw
> > > user input data for the non-solid line case?
> > >
> >
> > That is much trickier with the current architecture. The plmeta driver is
> > at the same level as all the other drivers, which is after all the
> > coordinate transformations. To do what you describe will take more work
> > (more than I am comfortable doing this close to release). There are
> > different approaches to implementing what you describe. One thought that I
> > had was to restructure the interface to the drivers by expanding and
> > unifying a "driver capabilities" structure. We sort have that now with a
> > dev_unicode, dev_text, dev_hrshsym, hardware fills, etc. Basically, my
> > thought is that a driver would be able to declare that it has a native
> > capability to all the primitives (pattern fills, dashed lines, etc) and
> > coordinate transformations. Then all PLplot would do for that driver is
> > layout the plot. For less capable drivers, PLplot with render the missing
> > features. I have not figured out how to handle clipping and difilt in this
> > architecture.
>
> Jim is right, the idea of implementing a mid-level interface that would be at
> just the right place of device-independence always horrified me sufficiently
> to stay well away from it. But it sounds like a agreat idea. :)
>
> --
> Maurice LeBrun
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website, sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for all
> things parallel software development, from weekly thought leadership blogs to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> Plplot-devel mailing list
> Plplot-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/plplot-devel
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
Plplot-devel mailing list
Plplot-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/plplot-devel
