Closed GoogleCodeExporter closed 9 years ago
With CEF r195, this issue now appears to happen as much in single-threaded mode
as in multi-threaded mode.
This could be due to the change to USER_TIMER_MINIMUM (see issue 189) making
the thread busier doing the animations.
Original comment by powerbf...@gmail.com
on 3 Mar 2011 at 5:33
I've found a workaround, but it means bypassing CEF's built-in context menu and
rolling my own.
I have HandleBeforeMenu send a message to my main window and then return
RV_HANDLED.
When the main window receieves the message, it creates and displays a
custom-built context menu (using the Win API functions CreatePopupMenu,
AppendMenu and TrackPopupMenu).
Original comment by powerbf...@gmail.com
on 9 Mar 2011 at 6:50
Tested using latest r212 and the context menu is showing 100% time, albeit
there is a problem when you want to hide that context menu, I need to click 3-5
times before it gets it. Seems like the problem is that these CSS animations
(in general) are not optimized, in my case on Athlon XP 1800+ it uses 99% of
CPU, so it's not a big surprise that context menu or other stuff won't work on
that page.
Original comment by cagret@gmail.com
on 28 Mar 2011 at 1:12
I've never seen it fail to display the context menu, only fail to respond when
an item in the menu is clicked. I had also guessed that it's because the thread
is busy doing the animations, but I never thought to check the CPU usage.
Also, I should clarify that the workaround I mentioned above will only work in
multi-threaded mode (because it shifts the context menu handling into a
different thread from the animations).
Original comment by powerbf...@gmail.com
on 28 Mar 2011 at 3:11
cagret: How much CPU does Chromium use when running the same animation on your
Athlon XP 1800+ system?
Original comment by magreenb...@gmail.com
on 28 Mar 2011 at 4:51
-------- Chrome --------
On Chrome the hiding of context menu fails only 10-20% of the time for the
first click, the second click almost always works and the menu is hidden.
Cpu usage below:
1st chrome process + 2nd chrome process, total
78 + 22, 100
80 + 16, 96
78 + 17, 95
77 + 18, 95
82 + 14, 96
15 + 79, 94
80 + 16, 96
76 + 20, 96
81 + 15, 96
78 + 18, 96
78 + 18, 96
79 + 16, 95
81 + 15, 96
81 + 14, 95
80 + 14, 94
76 + 19, 95
80 + 15, 95
84 + 12, 96
82 + 13, 95
80 + 14, 94
80 + 14, 94
AVERAGE=95.48
The total system CPU usage in Chrome is always 100%.
The missing 4.5% of cpu is used by "System" process.
-------- CEF --------
On CEF the hiding of context menu fails 99% of the time, it needs in most cases
5-10 clicks to hide the menu.
Cpu usage below:
cefclient.exe process
78
81
79
87
82
82
86
82
84
79
83
81
83
84
85
82
82
83
84
82
AVERAGE=82.45
The total system CPU usage is also always 100%.
The missing 17.65% of cpu is used by "System" process.
Original comment by cagret@gmail.com
on 28 Mar 2011 at 5:42
Your results are what I expected, which is good :-). You list 2 Chromium
processes; the 1st is probably the renderer (WebKit) process and the 2nd is
probably the browser process. Comparing Chromium's WebKit process to CEF's
single process you're seeing similar CPU usage while running the CSS animation.
Chromium creates the popup menu in the browser process instead of the renderer
process, which is why Chromium's popup menu shows better responsiveness. This
is similar to the situation described in comment #4.
So to improve CEF's popup menu responsiveness we have two options.
1. Always create the popup menu on a separate thread. This isn't really an
option when CEF is running in single-threaded message loop mode because we have
only the single WebKit/application thread for handling UI-related events.
2. Throttle WebKit CPU usage while showing the popup menu. This would result in
slower (or paused?) animation while the popup menu is displayed and would also
apply for WebGL and other renderer tasks that can take significant CPU.
Is everyone OK with #2 from a user experience standpoint?
Original comment by magreenb...@gmail.com
on 28 Mar 2011 at 6:10
You mean to "pause" the animation for the whole time the menu is being shown?
That would mean pausing it for at least 2-3 seconds on average until user
clicks an item in the menu. If it's about just slowing then that would be fine
I guess.
What about the 3rd option? In multi-threaded create popup in a seperate thread,
in single-threaded throttle the webkit cpu.
Original comment by cagret@gmail.com
on 28 Mar 2011 at 6:56
The 3rd option you propose isn't possible internally because CEF has no way of
posting tasks to the application thread when different from the WebKit thread
(which is the case with multi-threaded message loop mode). The user can of
course implement this 3rd option in their application if they don't want the
WebKit thread throttled.
Original comment by magreenb...@gmail.com
on 28 Mar 2011 at 7:02
I think it's interesting that the context menu never fails to display.
If it was purely a CPU usage issue, I'd expect that to fail as much as the menu
item selection does. In both cases, the app is responding to a mouse click
(right-click to display the menu, left-click to select a menu item). Why would
this fail in one case and not the other?
I think there's more to this than meets the eye.
I've attached a log of window messages seen while doing context menu stuff.
In this log, "browser" refers to the CEF browser window and "main" refers to
the main application window (the parent of the browser window).
(I hijacked the browser window's WndProc so that the messages went through my
main window's WndProc first so I could log them).
The log shows that when the context menu responds to a mouse click, the browser
window does not see the mouse clicks, but when the context menu is
unresponsive, the browser window receives the mouse clicks. So, it looks like
the context menu is sometimes "missing" the mouse clicks and they are falling
through to its parent (the browser window).
Original comment by powerbf...@gmail.com
on 29 Mar 2011 at 6:30
oops, forgot the attachment....
Original comment by powerbf...@gmail.com
on 29 Mar 2011 at 6:31
Attachments:
is anybody actively working on this issue now ? i think this issue is also
responsible for interaction delays with the window frame itself (and its menu)
it often is sluggish or unresponsive when showing any animation (like webgl
grass demo).
Original comment by mgt...@gmail.com
on 26 May 2011 at 12:08
Use CEF3 for GPU accelerated content.
Original comment by magreenb...@gmail.com
on 2 Oct 2012 at 10:21
May be related to http://code.google.com/p/chromium/issues/detail?id=59864.
Original comment by magreenb...@gmail.com
on 19 Dec 2012 at 1:43
Menu responsiveness fixed with a new CefBrowser::SetOSModalLoop method in trunk
revision 950, 1271 branch revision 951 and 1180 branch revision 952.
Original comment by magreenb...@gmail.com
on 19 Dec 2012 at 4:29
Change CefBrowser::SetOSModalLoop to CefSetOSModalLoop because the
functionality is not connected with any particular browser. Done in trunk
revision 1062, 1364 branch revision 1063, 1271 branch revision 1064 and 1180
branch revision 1065.
Original comment by magreenb...@gmail.com
on 4 Mar 2013 at 11:36
CefSetOSModalLoop function added in CEF3 trunk revision 1384, 1547 branch
revision 1385 and 1453 branch revision 1386.
Original comment by magreenb...@gmail.com
on 22 Aug 2013 at 5:12
Original issue reported on code.google.com by
powerbf...@gmail.com
on 25 Feb 2011 at 4:30Attachments: