[Kstars-devel] Good job Akarsh! Therefore: more, better TODO

[Akarsh Simha]

Hi James,

[Ccing the mailing list as well]

> In current example, I think updateCache is a good name but I don't
> like updateDrawID because we really are updating the cache and even
> though we are also updating the drawID's as part of that process, 
> it is too implementation specific.

Agreed. Fixed in my local copy. Will commit the changes soon.


> I agree that downloading and processing the data will probably take
> days.  It is likely that some steps may have to be repeated.  This
> is why I wanted to get started on this process soon.  

After the RAM upgrade, I'm able to fetch 1e6 SQL results in a single
query. That reduces processing time for 1e6 stars to half an
hour. That means, downloading will be the only bottleneck, but that's
okay.

> You might also considering downloading and/or processing the 100E6
> stars in chunks of 10E6 or 20E6 so there will be less to re-do if
> the process is interupted.   Perhaps it is best to not even worry
> about this until you are actually interupted and it actually causes
> a problem.

I don't think that will be easy, because the data, as of now, is
sorted by trixel (and then by magnitude) by the MySQL server. I will
have to restructure the process in order to enable me to do it. My
programs should be able to add stars to trixels.

If we require this, I'm willing to change the procedure, however.

> > I don't understand this.
> 
> You already did half of this with your fake-frugal modes to free blocks.
> The nCache idea is almost the opposite of fake-frugal.  It is the number
> of new StarBlocks the SBF will make before it even tries to start 
> recycling.  This would increase caching and thus reduce how much we 
> need to read in new stars from disk.  It is not clear to me that this 
> will be useful since you are able to read in stars from disk so 
> quickly.

I agree. The disk reads seem to be very fast, esp. in comparison to
the drawing. I think we must optimize the whole drawing process - not
only of stars, but of the whole skymapcomposite - the scrolling is not
smooth enough at low zoom levels.

> IMO, the memory UI should be sliders with either loose words 
> like "frugal" or with scales calibrated in megabytes (or whatever).
> But the key thing is that we want to make the translation so the
> user is dealing with units (or concepts) of memory usage and not
> something like "mag limit" for controlling memory usage.  This can
> become tricky when we want the same UI to handle different catalogs.

I agree. I'd prefer to go with loose words, because they are easier to
code and make sense to a typical user.

> IMO, there are two slightly different memory things the user could have 
> control over.  The first is the maximum memory needed to display stars.
> This is affected by some things we have no real-time control over such 
> as the mesh size and the catalog depth.  The one thing we can use to
> control the memory usage is limiting the mag limit.  But instead of
> requiring each user to experiment with the effects on memory of the
> various mag limit setttings and zooms, I think we should provide them
> with either some preset limits, or with a slider that deals in memory
> and not mag limit.

I like the idea of having some presets, or a master slider - something
like the KDE First Time Wizard used to have for effects, with the two
ends marked 'Faster Processor' and 'Slower Processor' - that would
control the rest of the parameters. Maybe we could have items like
"Binocular observing from city outskirts, Fair amount of RAM" or "The
ultimate observatory telescope, Lots of RAM".

> we need/want it.   It might become useful when you start expiring 
> StarBlocks, in which cause you would stop expiring blocks when the
> number of blocks gets reduced to nCache.  

I think I should implement this kind of a memory release as well. It
reminds me of the concept of an impulsive force in Physics. If you use
up a lot of memory, do so for a short time, and you will create less
"damage" to the user. But I don't know, maybe it is not worth it.
-------------- 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/20080630/942440f2/attachment-0001.pgp