[3029] Migration from 2743 - OnPaint in OSR not being called

Having problems with building or using CEF's C/C++ APIs? This forum is here to help. Please do not post bug reports or feature requests here.

[3029] Migration from 2743 - OnPaint in OSR not being called

Postby fokz » Sat Mar 25, 2017 10:14 am

Hello,

I have strange problem. I was trying to migrate from build 2743 (binary distrib) to 3029. I am not sure if it makes any difference but 3029 was the first time I was building locally using automate-git.py

The issue is that now on 3029 build the OnPaint method of my CefRenderHandler implementation is never called in Debug builds, despite the fact that I see logs that the page is successfully loaded.

I have two instances of CefBrowser in my app. One for splash loaded immediately and one for the actuall app loaded async. when the splash is already loaded and displayed.

Obviously I pass the pointer to my CefClient implementation while calling CefBrowserHost::CreateBrowser that returns proper CefRenderHandler. It gets called for the viewport and client rect size which are correct yet OnPaint does not happen.

What is even more strange is that in Release build the first page that is loaded synchronusly has its OnPaint called but the latter page that is eventually loaded does not.

I am using external message pump method taken from cefclient example app and it worked in 2743.

What might be the cause for such a change in behaviour between 2743 and 3029? Any help would really be welcome because at this point I am stuck.
fokz
Techie
 
Posts: 22
Joined: Sat Jun 18, 2016 10:53 am

Re: [3029] Migration from 2743 - OnPaint in OSR not being ca

Postby Czarek » Sat Mar 25, 2017 11:25 am

External message pump is buggy on Linux: https://bitbucket.org/chromiumembedded/ ... s-slow-and

I recall the guy who worked on external message pump PR tested it mainly on Mac.

On Windows it's best to use multithreaded message loop.
Maintainer of the CEF Python, PHP Desktop and CEF C API projects. My LinkedIn.
User avatar
Czarek
Virtuoso
 
Posts: 1927
Joined: Sun Nov 06, 2011 2:12 am

Re: [3029] Migration from 2743 - OnPaint in OSR not being ca

Postby fokz » Tue Mar 28, 2017 6:49 am

I mentioned that I use external message pump but I doubt this is the cause. This was the best choice for the type of app I am developing. I need to the UI thread of CEF to be my main thread to simplify life so multithreaded message loop would complicate stuff for me. But if this will actually turn out to be buggy and unreliable I will consider switching away from external message pump.

I will try to test a bit more what actually is hapenning but to do so I need to do it on my regular machine and I have another really strange issue.

Last time I build cef 3029 was on my laptop but it took ages so I decided to set it up on my PC now that I have access to it again. I did it the same as on my laptop and according to instructions on CEF Wiki but I failed to compile CEF. I did checkout twice with same result. Now I see where is the problem but have no idea how could it happen.

The problem is with chromium failing to compile dependency - ANGLE. It depends on VulkanValidationLayers and in case of branch 3029.6 it should check out Revision: d9da90d92748c37962766868f8b0354637672c2a of the git repo. I checked all the DEPS files etc. and chromium revision is fine, CEF is fine everything looks good. On my laptop machine that was the revision of VulkanValidaitonLayers, yet on my PC it checks out rev. f47c534fee2f26f6b783209d56e0ade48e30eb8d which doesnt make any sense since its from march 23.

Anyone have a clue why this might happen? The only difference in running python automate_git I did this time was --no-build in addition to --branch=3029. I wanted to build manually later on according to info on: https://bitbucket.org/chromiumembedded/ ... ckStart.md (I did use --branch=3029 obviously)
fokz
Techie
 
Posts: 22
Joined: Sat Jun 18, 2016 10:53 am

Re: [3029] Migration from 2743 - OnPaint in OSR not being ca

Postby magreenblatt » Tue Mar 28, 2017 11:38 am

Try with 2987 which is the current supported stable branch. You can download binaries from http://opensource.spotify.com/cefbuilds/index.html.
magreenblatt
Site Admin
 
Posts: 12382
Joined: Fri May 29, 2009 6:57 pm

Re: [3029] Migration from 2743 - OnPaint in OSR not being ca

Postby fokz » Tue Mar 28, 2017 1:11 pm

Thanks for the tip. I will try to build 2987 then. I need to built it myself because I want to apply and test the OSR GPU pull request (I know its against master, but the patch is straightforward to apply so the branch doesnt really matter). I thought I will just check with the latest branch.

Still I dont get why it checks out wrong revision of the VulkanValidationLayers git repo. I did a last try, changing something in the process, but still the HEAD in the git repo points to the different rev. than declared in DEPS. after the script finishes running. I assumed depot_tools should takes care of keeping the dependencies in correct state? Maybe my idea on how it works is just wrong, I am still fresh to chromium/CEF

I will try to checkout 2987 and report back.
fokz
Techie
 
Posts: 22
Joined: Sat Jun 18, 2016 10:53 am

Re: [3029] Migration from 2743 - OnPaint in OSR not being ca

Postby magreenblatt » Tue Mar 28, 2017 1:18 pm

It looks like you're running into https://bugs.chromium.org/p/chromium/is ... 433&desc=2. In the CEF build this is fixed by automate-git.py applying cef/patch/patches/DEPS.patch after checking out the chromium branch and before running gclient sync. Is that not being applied for you?
magreenblatt
Site Admin
 
Posts: 12382
Joined: Fri May 29, 2009 6:57 pm

Re: [3029] Migration from 2743 - OnPaint in OSR not being ca

Postby fokz » Tue Mar 28, 2017 2:04 pm

I am using automate-git.py and looking at the output I see some information about pathing DEPS before gclient sync so I think the patch was applied. I will check the 2987 anyway since its already checking out
fokz
Techie
 
Posts: 22
Joined: Sat Jun 18, 2016 10:53 am

Re: [3029] Migration from 2743 - OnPaint in OSR not being ca

Postby fokz » Wed Mar 29, 2017 8:36 am

Same method - branch 2987 checks out and builds just fine. Dependencies have revision as declared in DEPS files.
fokz
Techie
 
Posts: 22
Joined: Sat Jun 18, 2016 10:53 am

Re: [3029] Migration from 2743 - OnPaint in OSR not being ca

Postby fokz » Tue Apr 04, 2017 12:49 pm

Regarding the original issue, as I expected this was not due to external messasge loop. After some tinkering I see why my OnPaint stopped being triggered. I failed to notice the obvious - renderer process simply crashes when I try to load anything. Either something changed since 2743 or I build something in wrong way (which is actually possible).

When I attach to the renderer process the following callstack is generated at the moment of the crash:

Code: Select all
    libcef.dll!base::debug::BreakDebugger() Line 21   C++
    libcef.dll!logging::LogMessage::~LogMessage() Line 762   C++
>   libcef.dll!content::InitializeDWriteFontProxy() Line 89   C++
    libcef.dll!content::RendererMainPlatformDelegate::PlatformInitialize() Line 60   C++
    libcef.dll!content::RendererMain(const content::MainFunctionParams & parameters) Line 165   C++
    libcef.dll!content::RunNamedProcessTypeMain(const std::basic_string<char,std::char_traits<char>,std::allocator<char> > & process_type, const content::MainFunctionParams & main_function_params, content::ContentMainDelegate * delegate) Line 491   C++
    libcef.dll!content::ContentMainRunnerImpl::Run() Line 836   C++
    libcef.dll!content::ContentMain(const content::ContentMainParams & params) Line 20   C++
    libcef.dll!CefExecuteProcess(const CefMainArgs & args, scoped_refptr<CefApp> application, void * windows_sandbox_info) Line 171   C++
    libcef.dll!cef_execute_process(const _cef_main_args_t * args, _cef_app_t * application, void * windows_sandbox_info) Line 188   C++
    editor.exe!CefExecuteProcess(const CefMainArgs & args, scoped_refptr<CefApp> application, void * windows_sandbox_info) Line 190   C++


The actual line that is problematic is this DCHECK_EQ:

Code: Select all
  // When IDWriteFontFallback is not available (prior to Win8.1) Skia will
  // still attempt to use DirectWrite to determine fallback fonts (in
  // SkFontMgr_DirectWrite::onMatchFamilyStyleCharacter), which will likely
  // result in trying to load the system font collection. To avoid that and
  // instead fall back on WebKit's fallback logic, we don't use Skia's font
  // fallback if IDWriteFontFallback is not available.
  // This flag can be removed when Win8.0 and earlier are no longer supported.
  bool fallback_available = font_fallback.Get() != nullptr;
  DCHECK_EQ(fallback_available,
    base::win::GetVersion() > base::win::VERSION_WIN8);
  blink::WebFontRendering::setUseSkiaFontFallback(fallback_available);


Now I am confused and have two problems with it. For once, this probably happens because I build without official_build switch so all those DCHECK's are fatal in builds instead of just log the error (am I right here?). On the other hand I am not sure if it crashed in cefclient (maybe I wasn't checking debug, still need to investigate a bit).

The second thing that confuses me is why this DCHECK fails on my machine since I am running on Windows 10. The base::win::GetVersion() returns VERSION_WIN8 (?).

Anyway, is there an easy way to supress crash from such a dcheck in debug?

I see something promising in ~LogMessage() destructor:
Code: Select all
 // Give any log message handler first dibs on the message.
  if (log_message_handler &&
      log_message_handler(severity_, file_, line_,
                          message_start_, str_newline)) {
    // The handler took care of it, no further processing.
    return;
  }


Can this be somehow exploited? Should I care that this dcheck fails? Maybe I have did something terribly wrong while building and this shouldn't happen at all? Any help would be appreciated.
fokz
Techie
 
Posts: 22
Joined: Sat Jun 18, 2016 10:53 am

Re: [3029] Migration from 2743 - OnPaint in OSR not being ca

Postby magreenblatt » Tue Apr 04, 2017 12:57 pm

The fallback_available DCHECK is due to incorrect manifest settings in your application. See viewtopic.php?f=6&t=14721
magreenblatt
Site Admin
 
Posts: 12382
Joined: Fri May 29, 2009 6:57 pm

Next

Return to Support Forum

Who is online

Users browsing this forum: Google [Bot] and 31 guests