Hi, gee, this whole affair sure is more complex than I would have imagined!
I did not have a look at everything, so far, but here are a few issues and comments: On Saturday 04 September 2010, Prasenjit Kapat wrote: > 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. One performance problem that I have hit occurs once the history limit is reached. Then, if you create a new plot (all on a single device!), what appears to happen is that the current plot is replayed. As far as I understand, this comes from remove(), and there pop.and.update(). This will always redraw plots in all current device windows, while actually the only windows that would really need an update are those whose plots have actually been popped. For the others it would be enough to just update the internal list of history positions. Not sure, how to do this, best, but I think this is the most severe performance problem ATM. Again, when looking into this, it might be worth considering whether a plot that has been popped out of the history should really be cleared from any other devices that show it. Perhaps it should rather gain the status of a new plot, instead, which has not yet been placed in the history. The use case I'm thinking of is this: 1) User creates a fancy plot in one device, wanting to keep it. 2) User opens a second device (so as not to overwrite the other plot), and starts creating a different plot in it. Since it's not that easy, it takes the user a good number of attempts to arrive at the desired result for this plot. Naturally, each attempt will take up a slot in the history... 3) As the history limit is reached, the plot created in 1 is popped out of the history, and is gone for good! While talking about all this, it would probably be a good idea to offer some configuration option for turning off the whole history mechanism in case of unforseen problems. Again, I'm not sure, how to implement this, best. > I have kept the "replace plot" feature because of trellis plots. All right. I suggest an additional "insert plot" for the wishlist, then. Use case: User wants to modify a plot, but wants to be able to revert to a previous state in case of mess up. So he "inserts" the previous state into the history, then proceeds with modifications. But of course this can wait until everything else works as expected. On duplicated devices: I think we touched the subject before, but I don't remember the conclusion, and I can't find the mail right now: Is it really a good idea to treat the duplicate as the same history position? Isn't the point precisely to have a logically separate copy (i.e. like a regular new plot)? Somewhat similar to the issue of how to treat plots which have been removed in a different device. > Currently there are a lot of output messages. Lets keep it for the > testing phase and I'll remove them before the release. Yes. Assorted other things: - Occasional "Error in gType[[n]] : subscript out of bounds" subscript out of bounds in gType[[...]]" while printing the plot properties. I'll try to find a way to reproduce this, when I have more time. - I once got errors during replay() after playing around a lot. Will give you more information if/when I find a way to reproduce this. - I don't quite understand the meaning of "replacePositions" / "previous positions". Is this really needed? When exactly does this differ from the current history positions? Regards Thomas
signature.asc
Description: This is a digitally signed message part.
------------------------------------------------------------------------------ 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
