[PATCH] Caret blinking and CPU wakeups
Enrico Tröger
currently Scintilla (GTK version) adds a timeout function to the GLib
main loop which gets active every 100 ms. This timeout function handles
the caret blinking, horizontal scrollbar stuff and the dwell display.
This means every 100 ms Scintilla wakes up the CPU to do minor things.
And this happens for each instance of Scintilla, i.e. for each open
file in an editor like SciTE.
This is an issue on notebooks on battery power and causes unnecessary
power loss.
IMO it's sufficient to set the timeout interval to the value of the
caret blinking time to reduce CPU wakeups.
Furthermore, there is no need for this timeout at all if the Scintilla
instance doesn't have the input focus, i.e. if it isn't active.
Find the attached patch to change this behaviour. It only changes the
GTK part as I have no idea how the caret blinking time is handled on
Windows and I can't test it.
Before:
Scintilla wakeups the CPU 10 times a second for every file, even if the
container app is minimized in the background.
After:
Scintilla wakeups the CPU only when the caret actually needs to be
shown/hidden and only for the current active Scintilla instance. If the
container app doesn't have the input focus, no wakeups at all are
triggered.
I think this would be a significant improvement especially for notebook
users.
The only disadvantage could be that the dwell visibility needs a little
longer to show up, assuming the caret blinking times are generally
about between 0.7 and 1.0 seconds. But for me this would ok.
What do you think?
Regards,
Enrico
--
Get my GPG key from http://www.uvena.de/pub.asc
Neil Hodgson
> currently Scintilla (GTK version) adds a timeout function to the GLib
> main loop which gets active every 100 ms.
> ...
> IMO it's sufficient to set the timeout interval to the value of the
> caret blinking time to reduce CPU wakeups.
This affects all uses of the timer so deciding upon a different
caret period will change the speed of automatic scrolling as well as
dwell time. Caret blinking may also be turned off with a period of 0.
Changing the timer period will impair performance for users on mains
power for an unmeasured potential benefit for users on battery power.
To implement this well is more work: allowing each consumer of
timer ticks to specify whether or not they should currently be active
and the rate at which they should be generated. Then you could have
the dwell turned off when the window is invisible or turn it on when
the mouse moves into the window.
Neil
Enrico Tröger
<nyama...@gmail.com> wrote:
> Enrico Tröger:
>
> > currently Scintilla (GTK version) adds a timeout function to the
> > GLib main loop which gets active every 100 ms.
> > ...
> > IMO it's sufficient to set the timeout interval to the value of the
> > caret blinking time to reduce CPU wakeups.
>
> This affects all uses of the timer so deciding upon a different
> caret period will change the speed of automatic scrolling as well as
> dwell time. Caret blinking may also be turned off with a period of 0.
What exactly is the automatic scrolling? How important is its speed?
Turning off caret blinking at all is not necessary to reduce CPU
wakeups, IMO.
> Changing the timer period will impair performance for users on mains
> power for an unmeasured potential benefit for users on battery power.
So we need to find a tradeoff to make both happy :D.
> To implement this well is more work: allowing each consumer of
> timer ticks to specify whether or not they should currently be active
> and the rate at which they should be generated. Then you could have
> the dwell turned off when the window is invisible or turn it on when
> the mouse moves into the window.
Maybe it's worth to use a separate timer for the dwell code which is
only set if any dwell features are actually used (when activated by
setting SCI_SETMOUSEDWELLTIME to something else than SC_TIME_FOREVER)?
Then it's up to the container app whether to use dwell code or not.
In any case, I really suggest to consider at least the part of
deactivating the timers if the Scintilla instance has no input focus.
Neil Hodgson
> What exactly is the automatic scrolling? How important is its speed?
Automatic scrolling is scrolling when you drag the mouse through
the text and past the border of the window.
> Turning off caret blinking at all is not necessary to reduce CPU
> wakeups, IMO.
Turning off caret blinking is a user preference - some people don't
like the blinking. Since your patch uses the blink rate to determine
other timers it will not work when the user sets caret.period=0.
> So we need to find a tradeoff to make both happy :D.
No need for any tradeoff if the feature is implemented well.
> Maybe it's worth to use a separate timer for the dwell code which is
> only set if any dwell features are actually used (when activated by
> setting SCI_SETMOUSEDWELLTIME to something else than SC_TIME_FOREVER)?
> Then it's up to the container app whether to use dwell code or not.
Having multiple timers may cause more wake ups than using one. This
would all be much more interesting if the effect on battery life from
turning off the timer was measured.
> In any case, I really suggest to consider at least the part of
> deactivating the timers if the Scintilla instance has no input focus.
Dwell events are commonly used for value tips when Scintilla does
not have focus.
Neil
Enrico Tröger
<nyama...@gmail.com> wrote:
> Enrico Tröger:
>
> > What exactly is the automatic scrolling? How important is its speed?
>
> Automatic scrolling is scrolling when you drag the mouse through
> the text and past the border of the window.
I see.
> > Turning off caret blinking at all is not necessary to reduce CPU
> > wakeups, IMO.
>
> Turning off caret blinking is a user preference - some people don't
> like the blinking. Since your patch uses the blink rate to determine
> other timers it will not work when the user sets caret.period=0.
Ok but this is not a problem. If caret blinking is disabled, simply use
a default value for the timer, maybe 100ms or ideally something bigger.
> > Maybe it's worth to use a separate timer for the dwell code which is
> > only set if any dwell features are actually used (when activated by
> > setting SCI_SETMOUSEDWELLTIME to something else than
> > SC_TIME_FOREVER)? Then it's up to the container app whether to use
> > dwell code or not.
>
> Having multiple timers may cause more wake ups than using one. This
> would all be much more interesting if the effect on battery life from
> turning off the timer was measured.
You can use powertop (http://www.lesswatts.org/projects/powertop/).
> > In any case, I really suggest to consider at least the part of
> > deactivating the timers if the Scintilla instance has no input
> > focus.
>
> Dwell events are commonly used for value tips when Scintilla does
> not have focus.
What do they do if Scintilla does not have focus? I really don't want
to accept each Scintilla instance wakes up every 100ms even if the
whole application is e.g. minimized.
Neil Hodgson
> Ok but this is not a problem. If caret blinking is disabled, simply use
> a default value for the timer, maybe 100ms or ideally something bigger.
It is something that an implementation has to take into account.
> You can use powertop (http://www.lesswatts.org/projects/powertop/).
If there is a real measured decrease in time running on batteries
of 10%, a "Scintilla is not optimized for use on battery powered
systems" warning can go into the documentation.
> What do they do if Scintilla does not have focus?
Dwell events still fire when Scintilla does not have the focus. Its
quite common in an IDE to have the focus on a memory view or
breakpoint list while still being able to examine variables in the
unfocussed editor.
Neil
Enrico Tröger
<nyama...@gmail.com> wrote:
> > You can use powertop (http://www.lesswatts.org/projects/powertop/).
>
> If there is a real measured decrease in time running on batteries
> of 10%, a "Scintilla is not optimized for use on battery powered
> systems" warning can go into the documentation.
IMO that doesn't help much as it doesn't solve the problem, just
document it.
> > What do they do if Scintilla does not have focus?
>
> Dwell events still fire when Scintilla does not have the focus. Its
> quite common in an IDE to have the focus on a memory view or
> breakpoint list while still being able to examine variables in the
> unfocussed editor.
I see.
It's indeed much more complicated than I guessed initially. If I've
some time, I'll work on this again, maybe I'll come up with a better
solution.
Neil Hodgson
> IMO that doesn't help much as it doesn't solve the problem, just
> document it.
It solves 'the problem' completely since it first requires that
'the problem' be demonstrated. I am not interested in changing the
code for a non-problem.
> I see.
> It's indeed much more complicated than I guessed initially. If I've
> some time, I'll work on this again, maybe I'll come up with a better
> solution.
Measure first. No optimization should ever be performed without measurement.
Neil