[Kstars-devel] Clipped Mikly Way polygons ported to 4.0

[James Bowlin]

On Saturday 17 June 2006 18:54, James Bowlin wrote:
> 1) I am going to go ahead and implement the "ignore points" feature using
>    a QHash.  This will fix a lot of problems and make the code simpler and
>    more robust.  

I added this feature.  The Milky Way seems to work with all projections
now except Equirectangular and Gnomonic.  I've attached the complete patch
and I will email the new data files to Jason.  I used the character 'S'
to indicates points that should be skipped when drawing the outline.
There is no conflict with the 'D' used to indicate the beginning of
a polygon because the 'S' is only checked for (in the QHash) starting
with the 2nd point onward.

I did not apply the simplification that this change would allow because
the simplification would still require that toScreen() be evaluated
twice for each point (except the first) when drawing the outlines.

I think we could save some time in the ConsellationLinesComponent
by switching to the drawing routine used for the Milky Way outline.
Also, I don't think the modeList is needed anymore in drawing the
constellation lines since the first point in every constellation
line component is an 'M' point and all the following points are
all 'D' points.  Maybe I'll work on these two things next.

Finally, I had a few thoughts on some of the peculiar timing results
I've been seeing.  As I reported before, I sometimes see drawing
routines that normally take about 8 ms jump up to taking 40 or 50 ms.
I recently saw this same phenomenon with the Milky Way in the 3.5 code
and I spent about a day chasing it around.  I found that whenever I
put in a loop in the code to run the same drawing routine repeatedly
(to better the timing accuracy) the jumps up to 40 or 50 ms per iteration
disappeared.

I think these erratic timing results are due to the CPU cache.  I have
a laptop which has a reasonably fast (1.6 GHz) processor but only
512 KB cache.  I think that when the code (and or data?) are already
in the cache then that is when I get the fast times around 8 or 12 ms.
But when something changes and there is a cache miss, this causes the
time to bump up by 40 ms or so.  This might also explain why I sometimes
get really horrible times with the anti-aliasing enabled:  enough extra
code is added to the inner loops by the anti-aliasing so that I am almost
always getting cache misses.  OTOH, 50 ms seems to be too long a time
scale for RAM access and seems to be more on the time scale of a disk
access, but I am certainly not swapping.  This would also explain why
Jason is getting more consistent results, the amd-64 has a very smart
cache.  Also cache misses on a fast desktop system will probably be
much less expensive than on my laptop.


-- 
Peace, James
-------------- next part --------------
A non-text attachment was scrubbed...
Name: kstar-4-mw.patch
Type: text/x-diff
Size: 16237 bytes
Desc: not available
Url : http://mail.kde.org/pipermail/kstars-devel/attachments/20060618/3f171328/attachment-0001.bin