Hi, On Thu, Sep 2, 2010 at 2:55 AM, Thomas Friedrichsmeier <thomas.friedrichsme...@ruhr-uni-bochum.de> wrote: > Hi, > > 2) *Always* save to the history on plot.new, prev/next, etc. without the whole > newPlotExists mechanism. The advantage is again that it offers much less > potential for surprises. It does seem pretty wasteful, since most of the time, > the plots are not actually modified, but we still record them again and again > while browsing the history. On the other hand, recording plots appears to be > pretty damn fast for anything that I have tried so far, while replaying plots > is inherently slow. So any overhead that we add at this point will probably > not be noticeable. > Follow-up problem: Synchronization is probably needed in case of multiple > device windows showing the same history position (this time potentially > wasting a lot of CPU cycles, since it can mean a slow replay-operation; but > then this case should only be triggered every once in a while).
All right, the current implementation records and replays liberally. In some cases, you can "see the multiple replay processes." If it feels too sluggish, then we will have to drop the plot history feature for this release. > (BTW, these may have implications for the behavior of the "+"-button, too. For > solution 1, probably the current "replace plot" behavior makes most sense. For > solution 2, "replace plot" is rather useless, and so it should really be > "insert plot".) I have kept the "replace plot" feature because of trellis plots. Changing the titles for trellis plots amounts to re-plotting the whole thing which ends up appending to the history. Most of the times you don't want that. I've not looked carefully into the case when the history length is reached. It will need some extra testing. >> > Could you check the code for parts which are no longer needed and remove >> > those? Currently there are a lot of output messages. Lets keep it for the testing phase and I'll remove them before the release. Regards, -- Prasenjit ------------------------------------------------------------------------------ This SF.net Dev2Dev email is sponsored by: Show off your parallel programming skills. Enter the Intel(R) Threading Challenge 2010. http://p.sf.net/sfu/intel-thread-sfd _______________________________________________ RKWard-devel mailing list RKWard-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/rkward-devel
