[rkward-devel] Request for feedback on plot history

[Thomas Friedrichsmeier]

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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/rkward-devel/attachments/20100904/8eeac472/attachment.sig>