Commit by jbowlin :: r823312 /branches/kstars/unfrozen/kstars/kstars/skycomponents/skylabeler.cpp:

Eliminated an unused parameter warning message.

Commit by jbowlin :: r823199 /branches/kstars/unfrozen/kstars/kstars/ (3 files in 2 dirs):

Can now adjust the magnitude limit using mouse wheel or "-" and "=" keys by
using the Alt key modifier. The Ctrl and Shift modifiers work in a similar
fashion to what they do with zooming.

The default mag step is 1.0.

The Shift modifier reduces the step to 0.5.

The Ctrl modifier reduces it to 0.2.

Combined, they reduce it to 0.1.

Also changed the factor in the maglim formula from 4.444 to 3.5 to match
the summer branch.


CCMAIL:kstars-devel at kde dot org

Commit by jbowlin :: r823176 /branches/kstars/unfrozen/kstars/kstars/ (5 files):

Added large zoom steps to unfrozen branch.

The change in zoom due to the mouse wheel or "-" and "=" keys is now 2.0
instead of the previous 1.1. This reduces the number of key presses or
wheel clicks to change to to a given zoom by roughly a factor of eight.

The Shift and Control keys reduce the zoom step by factors of 2 and 4
respectively. Combined, they reduce it by a factor of 8 which is close
to (but not equal to) the original factor of 1.1.

Also increased MINZOOM from 200 to 250, which I think roughly compensates
for the change caused when we converted SkyMap::fov() to reporting the
diagonal of the screen instead of the minimum of the height and width.
The change in fov() was made to provide a radius for the SkyMesh::aperture()
call.


CCMAIL: kstars-devel at kde dot org

Commit by jbowlin :: r752604 kstars/trunk/KDE/kdeedu/kstars/kstars/skycomponents/constellationboundarylines.cpp:

Fixed a bug that erroneously created two error messages of the form:

cbounds.dat: tossing dupe on line XXX

on startup. This fix also closed the gaps in the Aquarius and Cancer
constellation boundaries.

CCMAIL: kstars-devel at kde dot org

Commit by jbowlin :: r730109 kstars/trunk/KDE/kdeedu/kstars/kstars/skycomponents/skymapcomposite.cpp:

Fixed a memory leak by disabling the updates of satellites. Satellites
are not currently displayed so not updating them should be no great loss
but the actual bug will need to get fixed once satellites are re-enabled.

CCMAIL: kstars-devel at kde dot org

Commit by jbowlin :: r708436 kstars/trunk/KDE/kdeedu/kstars/kstars/ (4 files in 2 dirs):

Made a bool SkyMap:onscreenLine2() routine that uses the return value
to flag if a line is entirely offscreen instead of changing the values
of the points.

Fixed a minor bug in onscreenLine2() where a line would disappear if
one endpoint of the line was barely offscreen. This bug probably
still exists in onscreenLine().

Varied the point density of the coordinate grid lines of constant
declination so the lines near the poles have fewer points.

CCMAIL: kstars-devel at kde dot org

Commit by jbowlin :: r708168 kstars/trunk/KDE/kdeedu/kstars/kstars/skycomponents/linelistindex.cpp:

Fixed a potential bug in LineListIndex::drawLines() where the new
onscreenLine() routine could modify oThis before it is copied to oLast
for the drawing of the next segment. I'm not certain this would ever
cause a problem because onscreenLine() only modifies points that are
off-screen but neither am I certain that it will never occur, hence
the fix.

Also, my previous commit added the following line to the top of the
htmesh/CMakeLists.txt file:

KDE4_NO_ENABLE_FINAL(htmesh)

CCMAIL: kstars-devel at kde dot org

Commit by jbowlin :: r708070 kstars/trunk/KDE/kdeedu/kstars/kstars/ (16 files in 3 dirs):

Applied the simple fix Jason found for the coordinate grid lock. He
called existing clipping code in the LineListIndex draw loop which
keeps us from asking QT to draw the off-screen sections of lines.
This is only an issue when anti-aliasing is on but it is always used
(for line segments not already clipped by the celestial horizon). The
addition of the clipping code had no measurable impact on the speed.
With anti-aliasing turned off the coordinate grid never takes more
than a few milliseconds to draw but with anti-aliasing turned on it
can take hundreds of milliseconds.

Fixed a minor bug in onscreenLine() that caused lines near the bottom
edge to disappear.

Am now always using the index for components that don't precess.
Previously, I had disabled the no-precess index for very low zooms in
order to save the time of computing a 2nd aperture but the aperture
only takes a millisecond or two (with the level-3 mesh) so we always
use it now.

Removed most skycomponents code that was switching to integer drawing
when anti-aliasing was off. The anti-aliasing is totally controlled
by QPainter::setRenderHint() so that code added complication but didn't
save us any time. The number of draw routines in LineListIndex was
thus cut in half from six down to three. And since we are now always
using the no-precess index, the drawAllLines() is not being used.

CCMAIL: kstars-devel at kde dot org

Commit by jbowlin :: r707814 kstars/trunk/KDE/kdeedu/kstars/kstars/skycomponents/linelistindex.cpp:

Turned of anti-aliasing in LineListIndex for most zoom levels as a
temporary workaround for the coordinate grid lockup Jason reported
earlier today.

IMO the outrageously long draw time is a bug in the QT drawLine()
routine when the antialias RenderHint is enabled. It can take
over a thousand times longer compared to when antialiasing is
disabled.

CCMAIL: kstars-devel at kde dot org

Commit by jbowlin :: r707686 kstars/trunk/KDE/kdeedu/kstars/kstars/skycomponents/linelistindex.cpp:

I have tracked the high-zoom coordinate grid lockup to line 386 in
linelistindex.cpp inside of the drawLinesFloat routine:

    psky.drawLine( oLast, oThis );

This commit re-inserts the onScreen check which reduces the problem
(by reducing the number of times the above line executes) this does
not eliminate the problem.

CCMAIL: kstars-devel at kde dot org

Commit by jbowlin :: r706949 kstars/trunk/KDE/kdeedu/kstars/kstars/htmesh/ (14 files):

Removed unused files, some of which were being compiled even though
they were not actually used. All references to windows.h are now gone.

It is possible that this will fix the ENABLE_FINAL bug reported by
Nicolas L?\195?\131?\194?\169cureuil.

CCMAIL: kstars-devel at kde dot org
CCMAIL: neoclust dot kde at gmail dot com

Commit by jbowlin :: r704058 kstars/trunk/KDE/kdeedu/kstars/kstars/skycomponents/asteroidscomponent.cpp:

Improved the scale of the asteroid label density slider.

Commit by jbowlin :: r703551 kstars/trunk/KDE/kdeedu/kstars/kstars/skycomponents/ (8 files):

Reduced the maximum star label density. If you think it is too small,
hit the "b" key and see what the hit ratio is. If it is 50% or less
then the label density is not too small. If the hit ratio is
significantly less than 50% then the label density may even be too high
since most labels are not getting drawn because they would overlap.

Prioritized the star labels based on magnitude. This was not exact.
I bin the labels based on the first two significant digits of the
star magnitude to avoid the expense of a sort. I could not see any
speed difference using this scheme. The downside is that the labels
for stars that have magnitudes within 0.1 will be drawn with the same
priority.

This brought the drawing of star labels outside of SkyLabeler::draw()
which then enabled me to bring the drawing of the constellation names
out of that routine as well which cleaned things up a little. Label
priority is now set by the order things are drawn in
SkyMapComposite::draw() as well as in SkyLabler::draw().

Cleaned up the starcomponent.h and SkyMapComposite::draw() a little.

CCMAIL:kstars-devel at kde dot org

Commit by jbowlin :: r703172 kstars/trunk/KDE/kdeedu/kstars/kstars/skycomponents/ (skylabeler.cpp skylabeler.h):

Added non-aliased drawing of angled labels. Made labelName static.

Commit by jbowlin :: r703134 kstars/trunk/KDE/kdeedu/kstars/kstars/skycomponents/skymapcomposite.cpp:

Further reduced the HTM mesh level from 4 down to 3 which has further
improved the drawing speed when zoomed out. A level-3 mesh has 512
trixels total down from 2048 for level-4 and 8192 for level-5.

Fixed a bug in deciding when to calculate the no-precess aperture
which caused the equator to sometimes not get displayed.

Added timing code in SkyMapComposite::draw() to time the entire draw
cycle. Uncomment line 293 to get the times to print out:

//kDebug() << QString("draw took %1 ms").arg( t.elapsed() ) << endl;

I discovered that the anti-aliased drawing can take about ten times
longer than the integer drawing. It is important to turn the
anti-aliasing off in order to test the timing of the rest of the
system.

I can now draw a reasonable skymap, fully zoomed out, with star
labels in about 50 ms. This increases to about 100 ms when I
include the solar system and asteroid labels. This then jumps
to about 600 ms if I turn the anti-aliasing on.

CCMAIL:kstars-devel at kde dot org

Commit by jbowlin :: r702058 kstars/trunk/KDE/kdeedu/kstars/kstars/kstarsdata.cpp:

Added qApp->processEvents() which makes the progressText messages
visible.

Commit by jbowlin :: r702025 kstars/trunk/KDE/kdeedu/kstars/kstars/skycomponents/milkyway.cpp:

Added percentage progress messages as the Milky Way loads.

Commit by jbowlin :: r701764 kstars/trunk/KDE/kdeedu/kstars/kstars/ (9 files in 3 dirs):

Am now giving reasonable (but not always perfect) progress percentages
when reading and re-reading stars.dat.  The percentages should now end
near 100% even if we are not reading in the entire stars.dat file.

The new data file starlnum.idx has the line numbers of roughly 90
different star magnitudes which enables the more reasonable
percentages.  If the stars.dat file changes then starlnum.idx should
be regenerated via:

   $ ./mag-linenum.pl stars.dat > starlnum.idx

Have stopped the one draw cycle delay before re-reading star data
because the skymap is getting erased anyway.

Tracked down a several second delay after reading the star data to a
faulty implementation of QTextStream::pos().  This function can take
7 or 8 seconds to complete!  I have a feeling they go back and re-read
the entire file.  I implemented a trivial work-around by simply
keeping track of the file position myself inside our read loop:

    m_lastFilePos += line.length() + 1;

Also did some minor code clean up in StarComponent and KSFileReader.

CCMAIL:kstars-devel at kde dot org

Commit by jbowlin :: r701542 kstars/trunk/KDE/kdeedu/kstars/kstars/skycomponents/ (4 files):

Renamed StarComponent::setFaintMagnitude() to readData() based on the
principle of least surprise. Removed the associated SkyMapComposite
proxy function.

Cleaned up SkyMapComposite::draw() just a little.

Put the code that rereads star data and creates the splash screen into
its own independent rereadData() routine which will allow us to try
calling it from other places in an attempt to solve the bug where
qApp->processEvents() causes the skymap to go blank.

Put a similar splash screen into StarComponent::reindexAll() but then
disabled it because the full re-indexing is only taking one second now
probably because I changed the mesh level from 5 to 4. I had also
streamlined the re-indexing code just a little which may have helped
too.

CCMAIL:kstars-devel at kde dot org

Commit by jbowlin :: r701254 kstars/trunk/KDE/kdeedu/kstars/kstars/ (kstarsinit.cpp skymap.cpp):

Fixed four horizon related bugs where we checked for
Options::showGround() but not Options::showHorizon() which caused
us to assume the horizon was displayed and filled when it was
filled but not displayed:

  1) start up warning of focus below the horizon
  2) in checkVisibility() for displaying objects
  3) for drawing transient labels
  4) in slotCentered() warning of requested position below the horizon.

CCMAIL: kstars-devel at kde dot org