[Kstars-devel] UI For Memory Management

[Akarsh Simha]

Hi James,

> I think it would be a mistake to unnecessarily impose arbitrary limits
> based on assumed use patterns because not everyone will be using KStars
> the same way we do.  I think 0.0 is a good lower limit on the zoomed out
> star density even though it doesn't correspond to what someone might see
> with the naked eye or a scope.  Choosing an upper limit involves a trade
> off between worst case memory usage versus incredible images that may
> take many seconds to display.  An easy compromise is one of the 
> suggestions I made previously to rely on the mouse-wheel to set the 
> density and use a control in the config window to set the "maximum star
> density" that is allowed via the mouse-wheel.  This will keep things 
> safe for most users but it will allow power users to achieve very high
> star densities (at the expense of higher memory usage and much longer
> draw times).  I think this is the best solution.   The upper limit
> in the config menu could range between 5.0 and 10.0 (or possibly 
> higher).

ISTM that a magnitude limit of zero is useless, because I could just
see one star in my FOV when fully zoomed out (with Gnomonic
projection). Maybe a lower magnitude limit of 2.0 will add flexibility
when compared to 3.5, but I really don't know why a user of KStars
would like to see so few stars (as with maglim_zoom_out = 0.0), other
than a case where he is interested in filtering by magnitude.

If the user wishes to filter by magnitude, the star density slider
wouldn't be a good candidate, IMO. At some point in time, we should
have a "filter by magnitude" option in KStars, that sets the universal
limiting magnitude for all objects to a given limit. We could
implement this then, by adding something like:

if ( maglim > universal_maglim ) maglim = universal_maglim;

> The simpler solution is to just impose a single fixed upper limit.
> I agree that we run into performance issues at 7.5 and beyond.  Although 
> it breaks my heart a little that we would make it impossible for people 
> to get really high star densities.  I don't think it should be 
> impossible, it should just be hard so you can't do it accidentally.
> But maybe for now, a single fixed limit will suffice.

I don't know why anybody would want a star density beyond 8.0. I took
a look by changing the way the Star Density slider works (patch
attached). Anything beyond maglim_zoom_out ~ 8.0 to 8.2 is both
cluttering up the field of view with too many stars, and is reducing
the discernability between stars, making it difficult to identify
constellations. I can't think of a practical use for a magnitude limit
beyond 8.0 to 8.2, other than to prove that KStars really shows a LOT
of stars! (Or when an astronomer is interested in seeing two 12th mag
stars that are pretty far apart, and I can't think of a reason for
this situation)

I find extending the magnitude limit to beyond 8.0 or below 3.5 a
disadvantage, and I will discuss that below.

> As far as linearizing the star density control, my gut feeling is that
> this would be a mistake.  The only way to know for sure is to try it
> both ways and see which way feels better.  One benefit of the current
> arrangement is that the steps are in star magnitude regardless of zoom
> level.  The mouse wheel provides steps of: 1.0, 0.5, 0.2, and 0.1 mag.
> This means that we can display the setting (when it is changed) in the
> status bar and it will be almost always be 2 digits and changes will 
> relate directly to changes in the maglim.  If you want to increase or
> decrease the maglim at the current zoom, by 1.0, one click of the mouse
> wheel is all you need.

The mouse wheel, as you suggest, (and as it is in the current trunk),
could be left as it is. This way, the mouse wheel could be left
labelled as 'Increase magnitude limit' and 'Decrease magnitude limit'
and that would probably be just what the user would want to adjust
when using KStars. For example, I want to see two fairly far apart
12.0 mag stars simultaneously, so I zoom out sufficiently and raise
the faint limit.

But IMO, a logarithmic version of the 'Star Density' slider seems
rather counter-intuitive for someone who doesn't know that it is
logarithmic. Also, I think that 'Faint Magnitude for Stars when Zoomed
Out' (approximately) would be a more appropriate label for a
logarithmic Star Density slider, in which case I think the old spin
box would make more sense. I made a few screenshots in this context:

http://members.bas.org.in/kstar/kstars-star-density-slider-logarithmic.tar.bz2

The number at the end of the filename is a guesstimate of the value on
the slider (which is 10 * maglim_zoom_out). You can see the slider in
the configuration window on the left side, although its label is out
of the screen.

Now, if I wish to maintain a linear slider, I must restrict the range
of possible magnitudes to about 5 (i.e. from 2.0 to 7.0 or 3.5 to 8.5
for instance), for otherwise the slider will get too conjusted.

If we really want to provide the flexibility of going to really low
(0.0) and really high (10.0) magnitudes, we could switch to
logarithmic mode beyond a certain point, just like car speedometers
change their scale at low speeds. Beyond 8.0, we could switch to
interpreting the slider logarithmically, change its colour to red or
something and possibly display a warning, telling the user that KStars
will become slow and use up a lot of memory. (Interestingly, I saw a
memory usage of about 230 MB at maglim_zoom_out = 10, which, I think
is not all that significant for a modern day computer.)

<snip>
> magnitude.  The current magnitude based control should provide users
> with fixed changes in the _percentage_ of stars displayed for a fixed
> number of steps/clicks which is what I think people naturally expect.    
</snip>

Isn't increasing in percentages the same as a logarithmic scale?

I've attached a patch that modifies the formula so that the same
slider behaves in the following manner:

1. Set the lower limit of the slider to maglim_zoom_out = 0.0

2. Set the upper limit of the slider to maglim_zoom_out = 10.0

3. Make the slider linear.

This patch also breaks the function of Alt + Mouse Wheel.

I apologize if this mail sounds like a rant or something, but I'm just
expressing my point of view. I'm open to suggestions and comments.

BTW, I also took some screenshots at various magnitude limits, and I
can link them if required.

Regards
Akarsh
-------------- next part --------------
A non-text attachment was scrubbed...
Name: linear-slider-mag-0-to-10.patch
Type: text/x-diff
Size: 497 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kstars-devel/attachments/20080720/55973186/attachment.bin 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : http://mail.kde.org/pipermail/kstars-devel/attachments/20080720/55973186/attachment.pgp