[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kstars-devel
Subject:    Re: [Kstars-devel] branches/kstars/summer/kdeedu/kstars/kstars
From:       Akarsh Simha <akarshsimha () gmail ! com>
Date:       2008-06-28 0:50:04
Message-ID: 20080628003804.GW6846 () PENGUIN
[Download RAW message or body]

[Attachment #2 (multipart/signed)]


> 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

["signature.asc" (application/pgp-signature)]

_______________________________________________
Kstars-devel mailing list
Kstars-devel@kde.org
https://mail.kde.org/mailman/listinfo/kstars-devel


[prev in list] [next in list] [prev in thread] [next in thread]