OSX: CEF Offscreen Rendering extremely slow.

[mokaschitta]

Hi,

I am experiencing some weirdness when compile cefclient from a binary package on OS X. When compiled, and run in the default way, everything works as expected. When I pass in

Code: Select all

--off-screen-rendering-enabled

the performance is super bad though. Videos on YouTube only play with 10fps at max, all the interaction feels super laagy and sluggish. I am sure that I am using a release build, I tried both, Xcode and Ninja as the build systems, with the same results. The weird part is, if I download the TestApp of the same build from cefbuilds.com, the problem does not occur, and everything is still smooth, even when using

Code: Select all

--off-screen-rendering-enabled

. This is super weird, but appears to indicate, that this is a build issue.

I am on OS X Yosemite, with the newest Xcode and build tools. I tested the following builds with the same symptoms: Branch 2171 64-bit OSX, Dev channel (Trunk )64-bit OSX.
If I take a branch that does not use CMake, yet (i.e. Branch 1750, but that branch does not seem to properly support flash in offscreen mode), the problem does not occur. Does anybody have a recommendation, about how to fix this? If not, which is the recommended stable build to use right now? Preferably one, that works with offscreen rendering and flash.

Thanks,

Matthias

[magreenblatt]

The off-screen implementation changed significantly between 1916 and 2062 branches. What TestApp versions have you tried that do not show the slowness problem for you?

[mokaschitta]

That is the funny part, I tried the following combinations:

Branch 2171: When cefclient is built from source, the performance problems occur, no matter if release or debug build. When I download the TestApp of the same build from cefbuilds.com, the problem does not occur, which appears to be a strong indication to me that this is a build issue. How is the TestApp built? Does it use the exact same Chromium Embedded Framework.framework as the ones that come in the binary package of the same build?

The same is true for the Dev Channel branch.

Thanks!

[magreenblatt]

Does it use the exact same Chromium Embedded Framework.framework as the ones that come in the binary package of the same build?

Yes. My guess is that you're not actually creating a release build locally. How are you building locally (what command-line, etc?).

[mokaschitta]

I tried the following ways:

I download the binary package from cefbuilds.com.

1. cmake -G Xcode
2. Open cef.xcodeproj
3. change scheme to Release
4. build the ALL_BUILD target

I also tried ninja:

1. cmake -G "Ninja"
2. ninja all

Then I am using the resulting .app bundles inside cefclient/Release/cefclient.app (when using Xcode)
or just cefclient/cefclient.app (when using ninja)
Am I missing something obvious here?

Thanks!

PS: I also tried the same thing with the 32-bit packages now and they have the same problem.

[magreenblatt]

You need to specify -DCMAKE_BUILD_TYPE=Release on the cmake command-line.

[magreenblatt]

You need to specify -DCMAKE_BUILD_TYPE=Release on the cmake command-line.

Actually, Release should be the default value but try it anyways to see if it makes a difference.

[mokaschitta]

Unfortunately, that does not do the trick.
I even redownloaded everything, ran cmake the way you said and tried both, Xcode and ninja, still having the same issues. Any other ideas? Thanks for the quick replies!

[magreenblatt]

I'm seeing this same problem with cef_binary_3.2171.1932_macosx32 on OS X 10.9.5 with XCode 6.0.1. Contents of the "Chromium Embedded Framework.framework" directory look correct but the cefclient binaries created by the local build are much larger than the binaries in the TestApp. Stripping debug symbols from the executable reduces the size a bit, but not enough to match the TestApp executable. There's probably some optimization being applied to the TestApp that's missing from the CMake config for the local build. Please add an issue in the issue tracker.

[mokaschitta]

Will do, thank you.

Do you have any branch/build recommendation that won't have this issue?