I was wondering if we could include support, as a compile-time option, for
Lightspeed overclocking, once the feature freeze is over.  I include a
patch--it's really a very simple patch.  I've been using a version of
Plucker patched with this patch for several months now with a private beta
of Lightspeed 2.0, and it has worked like a charm.  It is perfectly stable.
It switches into fast mode for autoscrolling, which makes autoscrolling
anti-aliased text usable on my NX70, for searching, and for reformatting.
The latter is an issue now that so many units have built-in rotation (which
will be supported by Plucker as soon as the new DIA support is in--Mike is
looking at a rough version of a patch for that) since a rotation forces a
reformat.  On my NX70 search benchmark, it cuts search time from 48 seconds
to 30 seconds.

Not only does this speed things up, it allows one to save battery life.  For
one can set Lightspeed to underclock Plucker--and then the few things that
require a fast CPU are still going to be blazing fast, done at high speed.

Lightspeed as of 2.0 beta currently supports a lot of OS5 devices: PalmOne
Tungsten C, PalmOne Tungsten T, PalmOne Tungsten T2, PalmOne Tungsten T3,
PalmOne Tungsten E, PalmOne Zire 21, PalmOne Zire 71, Sony CLIE TJ25, Sony
CLIE TJ35, Sony CLIE TJ27, Sony CLIE TJ37, Garmin iQue 3600, Tapwave Zodiac
1, Tapwave Zodiac 2, Sony CLIE NX60, Sony CLIE NX70, Sony CLIE TG50, Sony
CLIE NX73, Sony CLIE NX80, Sony CLIE NZ90.  See www.clievideo.com

My patch does not include any UI.  Since it should be a default-off
compile-time option, it doesn't really need any UI.  It checks if Lightspeed
is available, and if so it increases the speed (unless it is already running
at fast speed) whenever SpeedFaster() is called, and restores the old speed
whenever SpeedRestore() is called.  The two must be called in matched pairs.
If another overclocking program includes API it will be trivial to add a
call to it.

This patch has made for a MUCH better Plucker user experience for me.  The a
mount of changes to code are minimal--a couple of Lightspeed support
routines and then SpeedFaster() and SpeedRestore() calls.  I very strongly
recommend we include it.

Possible objections:
 1. This belongs in PPI.   Response: Sublaunches are slow, and we don't want
to slow down the
     calls to the Lightspeed API by having an extra sublaunch.  This is
important for the speedup
     when starting autoscroll--we want autoscroll to start and stop nicely
and snappily.
 2. Overclocking is a kludge that we shouldn't support.  Response: The
xscale processor is
     designed for variable clock rate, and so at least on the xscale
processors this is not really
     a kludge from the point of view of the hardware.  Moreover, I know that
the Lightspeed
     developer does a lot of testing (switching speed repeatedly every
second and all that).
 3. Bloat.  Response: This would be a compile-time option.  Moreover, it's
only 468 bytes
     compiled.

Variable speed PDA processors seem to be the way things are going.

I should note that if you want to try this patch, you should make one change
after applying it--sorry, I don't have time to do this.  After applying,
util.c will come to have an #include "lightspeed_public.h" line.  Just
delete that line--it's no longer needed.

Alex

--
Dr. Alexander R. Pruss
Department of Philosophy
Georgetown University
Washington, DC 20057-1133  U.S.A.
e-mail: [EMAIL PROTECTED]
online papers and home page: www.georgetown.edu/faculty/ap85
--------------------------------------------------------------------------
   "Philosophiam discimus non ut tantum sciamus, sed ut boni efficiamur."
       - Paul of Worczyn (1424)

Attachment: ls-diff-latest
Description: Binary data

Reply via email to