Quote:
Originally Posted by CoolDragon
I have tested your binary on my dr800sg. Here is the story:
Rebooting the device, the clock is up-to-date. Do nothing, the clock automatically updated about 30 seconds later (same as what you see). Using flipbar to go to my directory, in between, the clock updates again.
Opened a PDF file, doing nothing for more than 1 min. Clock is not updated. Using flipbar to go to next page, after about 30 seconds, it updates. Doing nothing on the current page for more than 1 min, clock is not updated. Using flipbar to next page, clock updated after some seconds. Repeating this, sometimes, clock is updated in several seconds after page turning.
In the folder view, clock does not update when staying in the same directory, changing directory of course updates.
Tried checking battery status several times, no hanging. Maybe just lucky. :-)
|
Your experiences are similar than mine, I get some refresh on folders view though.
And the behaviour I see is not so random (only refreshes with page changing, not after some seconds).
The hangs were produced clicking on battery every 30-60 secs during 5-10 minutes. Maybe it's the effect of not having a 'g' in my device
Quote:
Originally Posted by CoolDragon
So, this behavior sort of justifies my assumption(based on Mackx's hypothesis): in-activity for longer than 5 seconds will stop a user timer, and some external events (such as page turning using flipbar, or flipbar press to other directory etc) will restore the user timer. The thing that doesn't justify my assumption is that with your binary, in PDF view, clock updates after about 30 seconds. It appears that the clock timer is restarted by the flipbar turning, and not paused/stopped after 5 seconds of in-activity. There might be another timer in the display hardware?
Anyway, I have tested a clock timer of 6 seconds (less than 5 may prevent CPU from suspending, not sure), and not calling eripc in the clock update function. Without activity, clock won't update by itself. But after every page turning, it will do a nice local update after about 5-6 seconds. This is quite acceptable, although I have to test the battery consumption rate.
By the way, it's best to have fixed font for the clock, otherwise, a local refresh of the toolbar becomes a little bit messy due to the changed width of clock string.
|
I don't like the idea of having a timer every 4-6 secs.
Current implementation is not perfect, but it somehow works... I prefer to have something working that waiting until we discover the solution.
So what do you think if I do a public release of current code (i.e. with eripc) but 1 min. timer and tt font? Is robust enough?