Ultra slow javascript animation

[GoogleCodeExporter]

See the slider at http://gamecenter.pl/ (below the logo, a big image and 4 
thumbnails on the right - you click on the thumbnails to animate it)

The animation is very slow (2-3 frames per second compared to Google Chrome 30 
FPS) and what's more strange when I look in task manager > processes, the 
cefclient.exe process uses only 1-5% of CPU (95% of cpu is IDLE).

Tested on 2 machines, both XP SP3, one running Ahtlon XP 1800+ (1,53Ghz) + 1 GB 
ram, the other Athlon II X2 245 2x2.9 Ghz + 3 GB ram. The second machine is at 
least 3x times faster but the slowness of the animation is the same as on the 
first computer.

!! And here is the most strange thing about this bug: when the animation 
running (slowly) and I start to move my mouse very fast, the animation speeds 
up instantly, when moving the mouse while animating the CPU jumps to 50-60% and 
the speed/smoothnes is almost the same as in Google Chrome.

Tested on r181 binaries, also r126 and r27 - the effect is the same.

I also notice slow scrolling on pages.

I've been browsing through past issues here and I've found this: 
http://code.google.com/p/chromiumembedded/issues/detail?id=79
I'm suspecting that this might be some GUI thread issue related to multi 
threaded message loop option. Once I finish installing VS2005 along with all 
the patches I will try to compile cefclient and set 
TEST_SINGLE_THREADED_MESSAGE_LOOP to true. I will post here the results whether 
it helped.

Original issue reported on code.google.com by cagret@gmail.com on 17 Feb 2011 at 1:15

[GoogleCodeExporter]

Setting TEST_SINGLE_THREADED_MESSAGE_LOOP to TRUE didn't fix the issue, sliding 
behaves exactly the same.

Original comment by cagret@gmail.com on 17 Feb 2011 at 5:51

[GoogleCodeExporter]

Ahh I misread the comment regarding multi threading, it is disabled by default 
by that TEST_SINGLE_THREADED_MESSAGE_LOOP, to enable multi threading I must 
comment out that definition.

I've found that there are 2 solutions to that slow animation.

1. Single thread: by changing SetTimer to run every 10 milliseconds.
In cefclient_win.cpp replace that line:
>> SetTimer(hWnd, 1, 250, NULL);
with:
>> SetTimer(hWnd, 1, USER_TIMER_MINIMUM, NULL);

2. Multi thread: comment out TEST_SINGLE_THREADED_MESSAGE_LOOP in 
cefclient_win.cpp

The second solution is better - seems x2 faster, exactly as fast as in Google 
Chrome, the same CPU usage, the same speed, just fantastic.

In single thread the SetTimer() fix helps a lot, but compared to multi-threaded 
you can still feel the lag, it uses only 15-30% of CPU, compared to 
multi-thread 30-50% which makes that no frames are lost during animation.

I've tested other releases and there is one very fast in Single Thread mode, in 
revision 41 with changes to the SetTimer the animation is as smooth as in 
revision181 with multi-threading. But the CPU usage in r41 is quite unstable, 
during the animation going up to 100% and sometimes staying that high even when 
nothing is going on the page.

I've made some more tests and it feels faster (but maybe that's just feeling) 
when in multi-threading using also USER_TIMER_MINIMUM.

Original comment by cagret@gmail.com on 22 Feb 2011 at 3:20

[GoogleCodeExporter]

Your analysis in comment #2 makes sense. When running in single-threaded 
message loop mode Chromium only processes events when CefDoMessageLoopWork() is 
called from inside the message processing loop. By moving the mouse or using a 
faster timer you are causing Windows events to be generated more frequently 
which causes CefDoMessageLoopWork() to be called more frequently are results in 
smoother animation.

Other than using USER_TIMER_MINIMUM I'm not sure what more can be done to speed 
up single-threaded mode. I've committed the USER_TIMER_MINIMUM change as 
revision 193.

Original comment by magreenb...@gmail.com on 23 Feb 2011 at 3:34

• Changed state: Fixed

[GoogleCodeExporter]

Marshall,

I've been doing more testing and benchmarking on an old machine, there are 
cases when CEF is faster than Google Chrome - I especially liked one case when 
loading a 1.5 MB html page with 500 images, CEF displays it instantly in 0.5sec 
while loading the rest, Google Chrome tries to load everything before 
displaying it and it takes 4 sec before the white screen disappears, it makes 
CEF feel x8 faster in that case :)

I've found only one issue - slow scrolling in CEF. I know that in general 
Chrome compared to other browsers has slow scrolling, but in CEF it is even 
slower. It's only an issue on old machine, but if you know of any solution it 
would be great to hear it.

Original comment by cagret@gmail.com on 23 Feb 2011 at 5:10

[GoogleCodeExporter]

Revision 208 introduces a new CefRunMessageLoop() function. Using this function 
cefclient should the same performance in single-threaded and multi-threaded 
message loop modes.

Original comment by magreenb...@gmail.com on 24 Mar 2011 at 8:45

[GoogleCodeExporter]

That would be great. Will test it as soon as there is a binary release.

Original comment by cagret@gmail.com on 24 Mar 2011 at 9:04

[GoogleCodeExporter]

I've tested the r211. Works like a charm, the javascript animation in single 
threaded is even faster than in Chrome :)

There is some bug with resolution detection in this newest version, 
"screen.width" contains invalid value "0", put "javascript:alert(screen.width)" 
in url and you have it. At http://gamecenter.pl/ there is a javascript code 
that detects resolution and choses an appropriate wallpaper, it always selects 
the smallest 1024px wallpaper even on high resolutions.

Original comment by cagret@gmail.com on 25 Mar 2011 at 7:45

[GoogleCodeExporter]

Screen size problem fixed in revision 212. I'll build a new binary release.

Original comment by magreenb...@gmail.com on 25 Mar 2011 at 7:53

[GoogleCodeExporter]

Binary release now available at revision 212.

Original comment by magreenb...@gmail.com on 25 Mar 2011 at 7:59

[GoogleCodeExporter]

Works fine now.

Regarding the javascript animation speed. Now, not only it is faster than in 
Google Chrome but it even eats less CPU, the same test: Chrome uses up to 50% 
cpu on average, Cef uses up to 35% cpu on average. Awesome!

Original comment by cagret@gmail.com on 25 Mar 2011 at 8:28

[GoogleCodeExporter]

Marshall, is there a way to speed up the scrolling of pages also? It's a lot 
slower than in Chrome.

Original comment by cagret@gmail.com on 25 Mar 2011 at 9:01

[GoogleCodeExporter]

Scrolling speed is affected primarily by the balance between the handling of 
user input events (like scroll cursor movement) and the generation of screen 
repaints. Chromium has had quite a lot of optimization in this regard. You can 
find more information about it here: http://codereview.chromium.org/6730028/

Original comment by magreenb...@gmail.com on 26 Mar 2011 at 7:05

[GoogleCodeExporter]

Sorry... So this is there exist way to speed-up scrolling with CEF?
I see on about-complex visible markup, that scrolling have lags in CEF and CPU 
usage little more than in Chrome.

Original comment by fdd...@gmail.com on 22 Apr 2011 at 8:14

[GoogleCodeExporter]

Is it possible to know that the next call to the CefDoMessageLoopWork() should 
be done in as short time as possible?
For example CefDoMessageLoopWork() could return a boolean flag. The false value 
could mean that the next call is at the discretion of the user - on the new 
window message or on the lo-freq timer event. The true value could mean that 
the next call should be done as soon as possible.

Original comment by igor.ara...@gmail.com on 22 Apr 2011 at 9:06

[GoogleCodeExporter]

I was testing r231 and the bug appeared again (in multi threaded mode), but in 
another way, instead of animation, a start of next page loading was slowed down 
(to a crawl), but I can't reproduce it again. It worked like this:
1. I click in menu a link to another page 
2. After click nothing happens, I wait 2-3 secs and still nothing, I start 
moving the cursor and only then it starts loading immadietely.
(I'm really confusued cause I can't reproduce it, but I'm 90% sure that it 
wasn't lag, I repeated the test a few times, and when loading of next page hung 
up, only by moving cursor I could push it forward).

Original comment by cagret@gmail.com on 6 Jun 2011 at 12:06

[GoogleCodeExporter]

The javascript animation seems to be 50% slower (or more) in latest r306 
(windows binaries).

Original comment by czarek.t...@gmail.com on 6 Nov 2011 at 7:08

[GoogleCodeExporter]

The scrolling is much faster in r306, compared to r231. That is great news.

Original comment by czarek.t...@gmail.com on 7 Nov 2011 at 5:33

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

Faster scrolling comes at the cost, presenting initial screen is slower, but 
it's fine. I have a big document and I've tested speeds for r231, r306 and 
Chrome. The test below is about progressive rendering and time in which we are 
able to scroll the page, and then the speed of scrolling.

It seems that faster scrolling comes at the cost of slower initial screen and 
being able to use the page. The longer we see white screen loading > the faster 
the scrolling is.

r231:
initial screen: 0.5 sec
able to scroll: 1 sec
scrolling: slow, lagging
total document loading: 8-9 sec

r306:
initial screen: 1.5 - 2 sec
able to scroll: 3-4 sec
scrolling: quite ok, no big lag
total document loading: 5 sec

Chrome:
initial screen: 4 sec
able to scroll: 6 sec
scrolling: fast
total document loading: 6 sec

Original comment by czarek.t...@gmail.com on 7 Nov 2011 at 5:51

[GoogleCodeExporter]

[deleted comment]

[GoogleCodeExporter]

I personally like the CEF for it's speed of progressive rendering. The speed 
seen in Google Chrome (4 secs of white screen!) is not acceptable imo. I hope 
that it will stay that way in CEF in the future.

In my app I need to display an initial screen very fast, so user doesn't feel 
that the app is "slow".

For some other cases, that might not be the best option.

Masshall, I wonder, whether there could be an option in CEF, whether we need 
fast initial screen (and we don't care about slower scrolling and longer total 
document loading) or fast scrolling (we can wait more time and in return we 
have fast scrolling on the page).

Maybe something like:

PrioritizeInitialScreen(10); // 10 = max
PrioritizeUsingThePage(7);
PrioritizeFastScrolling(5);
PrioritizeTotalLoading(3);

Would that be possible?

Original comment by czarek.t...@gmail.com on 7 Nov 2011 at 6:06

[GoogleCodeExporter]

@comment#19: Can you provide an attachment or link to a document that you feel 
is a good test of initial rendering performance and scrolling performance?

I'm not personally convinced that there needs to be a tradeoff between initial 
rendering performance and scrolling performance. Initial rendering performance 
is limited by how quickly WebKit can parse the DOM and generate the initial 
layout/rendering. Scrolling performance is more about optimizing invalidation 
regions and intelligently repainting the screen. I think that we can do a lot 
to improve scrolling performance irrespective of initial rendering performance 
(and we've already done a lot of work in this regard for Mac OS-X -- see issue 
#360).

Original comment by magreenb...@gmail.com on 8 Nov 2011 at 4:37

[GoogleCodeExporter]

Here are the test files:
http://www.speedyshare.com/file/Uv33E/stress.zip

torrents-510.htm - 510 movie records
torrents-1020.htm
torrents-2040.htm
torrents-4080.htm

In my tests in comment #19 I've used torrents-510.htm on Ahtlon XP 1800+ 1.5 
Ghz machine. I've repeated them a few times, always the same results. On faster 
machine you should use the bigger files.

Original comment by czarek.t...@gmail.com on 8 Nov 2011 at 8:07

[GoogleCodeExporter]

>> that there needs to be a tradeoff between initial rendering performance and 
>> scrolling performance

Firefox has a very fast scrolling, but it needs to spend more time on preparing 
the document, and that is what I read on the net. 

But let's make a test for firefox too, using the same machine (1.5Ghz) and the 
same file (torrents-510.html):

Firefox:
initial screen: 7 sec
able to scroll: 7 sec
scrolling: ultra fast
total document loading: 7 sec

Seems to make sense imo.

I did the same test for Opera, wow, it is really FAST:

Opera:
initial screen: 3 sec
able to scroll: 3 sec
scrolling: also ultra fast
total document loading: 3 sec

Original comment by czarek.t...@gmail.com on 8 Nov 2011 at 8:20

[GoogleCodeExporter]

The scrolling differences can be seen easily by dragging the scrollbar.

Original comment by czarek.t...@gmail.com on 8 Nov 2011 at 8:26

[GoogleCodeExporter]

 czarek, your zip file of stress sample is broken. cannot unzip it.

Original comment by boogun...@gmail.com on 9 Nov 2011 at 5:09

[GoogleCodeExporter]

I've downloaded the zip file and extracted using WinRar and 7-Zip, both 
successfully. Your download must had been corrupted probably.

Here is a different download and used a different archiver:
http://www.gosu.pl/var/stress.zip

Original comment by czarek.t...@gmail.com on 9 Nov 2011 at 7:27