[Kstars-devel] UI For Memory Management

[James Bowlin]

I found your formula to linearize the star density control very 
interesting.

There are two independent issues here:

  1) min/max star density settings, and
  2) linearizing the star density control

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).

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.

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.

But even if we ignore the intuitiveness of letting users adjust a simple
star magnitude offset, I think it would be a mistake to make the star 
density control linear in stars/area.  Almost all scale setting 
controls such as this are exponential/logarithmic.  The quintessential
example is the controls on an oscilloscope that set the voltage range
and the time scale of the display.  This are almost always adjustable
via powers of ten with finer steps similar to the finer steps in 
fractional magnitude I chose above.  Likewise, our zoom control is 
exponential, allowing the user to change the FOV by many orders of 
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.    

 
-- 
Peace, James