[rkward-devel] limiting onscreen graphics history

[Prasenjit Kapat]

Hi,

On Wed, Jun 30, 2010 at 12:25 PM, Prasenjit Kapat <kapatp at gmail.com> wrote:
> Hi,
>
> On Wed, Jun 30, 2010 at 6:20 AM, Thomas Friedrichsmeier
> <thomas.friedrichsmeier at ruhr-uni-bochum.de> wrote:
>> Hi,
>>
>> On Wednesday 30 June 2010, Prasenjit Kapat wrote:
>>> 1. Limit on L, no limit on either S or s -- naive
>>> 2. Limit on L and s which in turn limits S as well -- better than 1
>>> but the user may not have a clear idea of how large s can be? 1 KB? 5
>>> KB? 30 KB?
>>> 3. Limit on L and S -- can be easily superseded by just limiting on S.
>>> 4. Limit on S -- seems reasonable
>>> 5. Limit on S and s = p * S where p = (say) 0.6 -- more reasonable.
>>
>> I'm somewhat undecided between 2 and 5. 5 is most elegant, technically, but 2
>> may be slightly easier usability-wise. I think it depends on what we believe
>> how what would be sensible values for L, s and S. For L, I believe the ~5-10
>> most recent plots are the most interesting by far, but we could assume 20 to
>> be on the safe side.
>> Regarding s, the object.size() of plot(rnorm(100000)) is around 1.6MB, here.
>> So, if we set s to 2MB, that should support pretty much any plot in practice.
>> Multiplying that in solution 2 would yield 40MB. That *is* pretty large. On
>> the other hand, S would _typcially_ be much smaller in solution 2, and on
>> systems where 40MB are a serious issue, RKWard may not be a good choice in the
>> first place.
>> In solution 5, memory-usage would always approach S after extended usage, so
>> it may be reasonable to set S somewhat lower, perhaps at 10MB.
>>
>> How large is a "typical" plot? My guess is 50KB. That would mean 200 plots can
>> be stored in 10MB for solution 5. For solution 2 that means the typical memory
>> use for the plot history is 1MB.
>>
>> Hm, ok, after writing this down, I think I'm inclined towards solution 2.
>
> Thanks for the numbers! If no one has any objection, then I shall
> implement 2 shortly.

I've implemented the limits as discussed above. Two things came up:

1. s = 50 KB seems small even for a pie (...) plot! Which was a
surprise, but it validated the code implementation. Let's stick with
50 KB as the default for now. Once this feature is field-tested by
others, if needed, we can change it easily.

2. What to do when the max history length (or size) is reduced from
the settings, while there is an existing history? What I mean to say
is this: suppose L = 10 is set in the settings. Let H = length of the
current recorded history. Suppose H = 8. Now suppose the user decides
to reduce L to 5 in the settings. So, there are 3 extra plots in the
history. Two ways out:

2a. Do nothing (which is the status quo). In this case, there is a
warning displayed in R (not in KDE) and no new plot is added the
history.

2b. Pop out the first 3 plots, so that H = 5 and then any new plot can
be added the usual way (pop the first and push the last)

Do you think 2b is a better solution than 2a? Opinions? I (think, I)
have all the necessary code in place to implement 2b, so it should be
relatively easy.

There is a similar situation if 's' is reduced below max (all
individual recorded plot sizes). So, popping plots out of history in
this case would almost reduce to the case 5 above; which I'm not too
comfortable with it.

In any case, it would be nice to show a KMessageBox warning (instead
of / along with, the warning in R) from KDE in both these situations.
This would require R to send the value to H back to C++ whenever the
length of history changes - which is already being by
updateDeviceHistory. Can it be accessed from the
rksettingsmoduleouput?

Since updateDeviceHistory has no information on the 'size,' it may be
better to create a separate rk.do.call () with history_length and
max_existing_size as the two arguments and connect it to
rksettingsmoduleoutput. Or may be there is a simpler/better way...

Regards,
-- 
Prasenjit

PS: @Stefan, I haven gotten around to your JSS email yet. Will do so soon.