[Kstars-devel] branches/kstars/summer/kdeedu/kstars/kstars

[Akarsh Simha]

> We might also want the mesh level and the maximum (dynamic) stars per 
> trixel in the header.  Putting the mesh level in the header will allow
> us to have different mesh levels for different star catalogs.  including 
> the MSpT will allow us to limit the total number of dynamic StarBlocks 
> to:
> 
>     6 * ceiling( MSpT / stars_per_block) 

Mesh level is fine. Do we still need MSpT, considering that we are not
doing double buffering? I can't see how the total number of SBs will
ever exceed 6 * ceil( MSpT / stars_per_block ).

> From this we can figure out the proper star density setting.  For 
> example, if the brightest dynamic star is mag m_0, and we have agreed 
> to not make more than N_blocks StarBlocks then we know that the maglim
> can't be greater than m_0 when there are more than N_blocks trixel
> visible.

Ok. You're planning to change the memory usage slider that currently
uses arbitrary units to use StarBlocks.

> But maybe this is getting too complicated and we should instead just
> put a simple limit on the star density.  Still, the reasoning above
> could help us come up with a formula relating the star density setting
> to the maximum number of StarBlocks needed.

Would it be worth the while to derive this relationship numerically?
I'm satisfied with the arbitrary memory units that we use now, but I
wouldn't mind adding more sense to that.

Regards
Akarsh
-------------- 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/20080628/af5abc06/attachment.pgp