Chromium 11 / system clock changes

[cgp1024]

I'm currently using berkelium / chromium 11.0.696.77, and I've backported fixes from chromium 24 to resolve issues around the system clock being changed, and timers not firing, or the firing being delayed.
This only includes fixes for windows and linux platforms.

more details about this issue:
http://ludios.net/browser_bugs/chromium_time_jump_bug.html

See patches attached.

[Ewen Cheslack-Postava]

Thanks for the patches. I've cleaned up and combined them and it's
been committed in f87a9397a05b1240d5ba31c355dd6c5aea5ebe5c.

-Ewen

[Ewen Cheslack-Postava]

I actually had to revert this. It compiles and things seemed to be
working fine in the demo, but I found it started causing problems with
the glut_input demo. Trying to type into an input half works,
sometimes entering the character and leaving the cursor in the wrong
place.

Omitting this from Berkelium isn't a problem since this seems like a
pretty unusual problem to encounter anyway, but if you're using this
patch yourself, I'd be careful with it.

-Ewen

[george pee]

Thanks for the heads up!  I've been using it for a couple of weeks and haven't noticed unusual (yet), but I'll keep an eye out.

Yeah, it is a rare situation in most cases (like a setTimeout call right before a backwards daylight savings event), but for kiosks made for an embedded environment that require periodic time sync, I was encountering a problem a couple of times a week.

It's really just the javascript timers that should be affected-- does the glut_input demo use any of these?

[Ewen Cheslack-Postava]

On Mon, Jan 7, 2013 at 3:21 PM, george pee <crazy...@gmail.com> wrote:
> Thanks for the heads up! I've been using it for a couple of weeks and
> haven't noticed unusual (yet), but I'll keep an eye out.
>
> Yeah, it is a rare situation in most cases (like a setTimeout call right
> before a backwards daylight savings event), but for kiosks made for an
> embedded environment that require periodic time sync, I was encountering a
> problem a couple of times a week.
>
> It's really just the javascript timers that should be affected-- does the
> glut_input demo use any of these?

No, the input system doesn't use any javascript, it's just injecting
the appropriate events into Chromium. But the patch modifies core
timing functionality which is almost certainly used for input handling
in webkit/chromium. It doesn't actually surprise me too much that a
problem like this popped up when backporting a patch from chromium 24.
Lots of things have changed since then and there are probably a ton of
unstated assumptions that have changed over time. Modifying such core
functionality is bound to have unexpected consequences.

As for why you didn't see this -- we may simply be testing different
platforms. I'm on x86_64 Linux. If there's a smaller patch covering
only the platforms you need that doesn't have any issues, I'd be happy
to apply that.

-Ewen

[george pee]

That makes sense.  I'm running primarily on win32, with little testing on linux.

I don't know that a smaller patch would work.  Yes, there are a few things in the patch that may be unnecessary, but it's mostly all needed.

I think it's more likely that I missed something like a file that didn't exist in chromium 11.

Let me try out the demo and see if I can make a it work properly.

[george pee]

I found issue with the backport with WebKitClientImpl::setSharedTimerFiredFunction.  It was causing very very high cpu utilization.



It should be changed to this:
-void WebKitClientImpl::setSharedTimerFireTime(double fire_time) {
-  shared_timer_fire_time_ = fire_time;
+void WebKitClientImpl::setSharedTimerFireInterval(double fire_interval) {
+  shared_timer_fire_time_ = fire_interval + monotonicallyIncreasingTime();
   if (shared_timer_suspended_)
     return;
 
@@ -477,7 +482,7 @@
   // This results in measurable performance degradation unless we use ceil() to
   // always round up the sleep times.
   int64 interval = static_cast<int64>(
-      ceil((fire_time - currentTime()) * base::Time::kMicrosecondsPerSecond));
+      ceil((fire_interval * base::Time::kMillisecondsPerSecond) * base::Time::kMicrosecondsPerMillisecond));
   if (interval < 0)
     interval = 0;
 
@@ -596,7 +601,7 @@
 void WebKitClientImpl::ResumeSharedTimer() {
   // The shared timer may have fired or been adjusted while we were suspended.
   if (--shared_timer_suspended_ == 0 && !shared_timer_.IsRunning())
-    setSharedTimerFireTime(shared_timer_fire_time_);
+    setSharedTimerFireInterval(monotonicallyIncreasingTime() - shared_timer_fire_time_);
 }


Do you think that high cpu utilization may have caused the issues that you were seeing ?

[george pee]

Updated patches, with the high cpu utilization resolved.

[Ewen Cheslack-Postava]

Great, these ones worked out just fine with slight modification to fit
with one of the other existing patches. They're now in the repo on the
chromium11 branch. Thanks for the patches!

-Ewen

On Thu, Feb 7, 2013 at 7:13 PM, george pee <crazy...@gmail.com> wrote:
> Updated patches, with the high cpu utilization resolved.
>

> --
> You received this message because you are subscribed to the Google Groups
> "Berkelium" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to berkelium+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>