On Thursday, March 5, 2015 at 14:44:20 (-0500) Jim Dishaw writes: > > 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.
[snip] I really wish I had time to be more involved, since these are issues I've dealt / struggled with myself back in ancient history. No time to follow code changes or even to build/test. :( That said, about 10yrs ago I had the following on my wish-list: 1. Enhancements to driver intelligence & plot-buffer a) Expanding device space to 32b assuming brain-dead dashed line algo was fixed b) Embellishing driver smarts to such things as strings, maybe other object types. Ended up getting stuck on both accounts, sadly. 2. Design & implement a mid-level device-independent interface which would be the basis for the new metafile driver & renderer. The problems with the current metafile architecture (aside from bit-rot) have been known for a very long time. It was made "good enough" for our needs given the time constraints. I settled for a common default resolution & size for the devices I could, such as plm, xwin, etc, which mitigated the problem. The comments (this is from an old checkout) in plplotP.h about the latter are actually kind of funny to read today. Starting with: /* These define the virtual coordinate system used by the metafile driver. * Others are free to use it, or some variation, or define their own. */ ... Never even came close to starting this one. But conceivable, given the fairly small number of plplot core operations e.g. draw a line. :) 3. There was no #3 but it occurs to me a mid-level interface might be fast enough to handle redraws and have significant advantages in flexibility and whatnot. No way to find out except a real world test. At a previous employer we ended up driving everything from the client side which meant redraws used the public API all the way down to device level (xwin/plframe). Basically we had no plot buffer. We let expose events do their thing but everything else we handled ourselves. Being in the client we could throw away a lot of data to begin with instead of pumping it all through poor little plframe. :) So that included anything offscreen (when zoomed) and anything too small in resolution to see (with some caveats). I think my last project involved implementing overlaid rulers. They weren't saved as part of the plot buffer but done as the last stage so that moving them around on the screen was fast (refresh == expose + line draws over top). Of course, all proprietary. :( -- 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
