[Kstars-devel] UI For Memory Management

Jason Harris kstars at 30doradus.org
Sat Jul 19 18:22:30 CEST 2008


Hi Akarsh,

I wouldn't worry too much about making the memory estimate very
accurate.  Since memory usage will vary anyway for a given setting,
all we want to do is provide a rough estimate.

I would just add a debug statement that shows the number of stars
loaded into memory, and then do an "eyeball average" of that number as
you use the program with different slider settings.  Then just
multiply the average number of stars by the memory footprint of a
single star.  Actually, when you do the "eyeball average", you may
want to err on the high side of memory usage, so the displayed number
is a conservative estimate.

regards,
Jason


On 7/19/08, Akarsh Simha <akarshsimha at gmail.com> wrote:
> Hi
>
> Please find yet another opscatalog.ui candidate attached.
>
> I think this is good enough, as James pointed out, because we have the
> Alt + Mouse Wheel feature anyway if we wish to increase star density.
>
> In the meanwhile, I'll work out the math required to estimate the
> memory usage given the value on the 'Star Density' slider.
>
> Should the slider be replaced by the Spin Box for the faint mag when
> zoomed out that we had earlier? I don't like the Spin Box because the
> numbers wouldn't make sense if we were labelling the field as 'Star
> Density'.
>
> Sliders, AFAIK, can handle only integers and integer steps. This means
> that I will need to map the numbers 1 to 10 (or whatever) from the
> slider to a magnitude range, by playing around with James map from
> star density to magnitude limit, so that they actually correspond to
> linear changes in star density. I hope this will be acceptable to
> everyone.
>
> Any suggestions on the math behind the memory usage estimates? If it
> is going to be 10 values from a slider, it might be possible to
> hardcode values, and these hardcoded values will be extremely
> accurate. I think I should avoid hardcoded values (other than the
> "basic" memory usage), lest we change things later. So I plan to work
> out the memory usage by finding the average number of stars in the FOV
> for the given magnitude limit, and then multiplying this by the ratio
> of maximum stars per trixel to the average stars per trixel, so we
> make an approximate guess of the maximum memory usage (so that the
> user is safe). Of course, this assumes that he has the Tycho-2 deep
> star catalog. Maybe I should implement a way of checking this.
>
> I wish that everyone could send in their suggestions / opinions fast,
> because I would like to close my GSoC project as soon as possible and
> start working on other things.
>
> Regards
> Akarsh
>


More information about the Kstars-devel mailing list