CefRenderHandler::OnPaint called with stale pixels

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.

Re: CefRenderHandler::OnPaint called with stale pixels

Postby callum » Sat Jan 27, 2018 10:51 am

Understood and I may have missed something in my implementation but that wouldn't explain the repro in cefclient would it ?
callum
Expert
 
Posts: 323
Joined: Mon Feb 23, 2015 6:19 pm

Re: CefRenderHandler::OnPaint called with stale pixels

Postby amaitland » Sun Jan 28, 2018 6:36 pm

salvadordf wrote:If you are using an external message pump you may need to create a message loop that handles all cases.


The problem reproduces using Multi threaded message loop on Windows.
Maintainer of the CefSharp project.
amaitland
Virtuoso
 
Posts: 1290
Joined: Wed Jan 14, 2015 2:35 am

Re: CefRenderHandler::OnPaint called with stale pixels

Postby callum » Tue Mar 20, 2018 5:55 pm

https://bitbucket.org/chromiumembedded/ ... -receiving

Is there a way to find out if this is in progress or not?
callum
Expert
 
Posts: 323
Joined: Mon Feb 23, 2015 6:19 pm

Re: CefRenderHandler::OnPaint called with stale pixels

Postby magreenblatt » Tue Mar 20, 2018 5:57 pm

It is not in progress.
magreenblatt
Site Admin
 
Posts: 12382
Joined: Fri May 29, 2009 6:57 pm

Re: CefRenderHandler::OnPaint called with stale pixels

Postby rdl » Wed Jun 20, 2018 10:34 am

I've spent the last few days investigating this.

I can very easily get into the broken state using downloaded cefclients from http://opensource.spotify.com/cefbuilds/index.html. I found that all 3.3071 versions got stuck, but no 3.3029 versions did. I was running with the --off-screen-rendering-enabled flag only, on Windows 10.

I downloaded and built from source. Building as at 3.3071.1634 again produced a stuck cefclient, building as at 3.3029.1619 again produced a cefclient that I could not get into the stuck state. A quick[0] bisection of the CEF commits between these two revisions gave me that 2f6475c0 did not get stuck, and that 3f711386 did get stuck. Predictably, 3f711386 updates the Chromium version that CEF builds against.

Code: Select all
λ git log branch-heads/3029..branch-heads/3071 | grep "^commit " | wc -l
11016

Only 11K commits that could break it :( (This is a slight over-count, since there are commits after the known-broken one.)

Searching for "resize" in these commits produces some scary-looking changes, including:


At this point I am in quite a bit over my head. Bisecting the Chromium changes is difficult because the CEF changes needed to match them are combined into a single commit that would need to be partially applied to match how the Chromium code would look at various stages between the endpoints of the bisection. There are a lot of changes there! I'm sure this is possible but it is not currently looking an attractive prospect.

My hope is that this bug has been caused by a simple oversight and a lack of a test case. I believe that someone familiar with the code could jump in here, take a close look at some of the Chromium changes knowing that this case fails, and quickly deduce what is wrong.

I am keen to get this bug fixed, and happy to offer assistance in whatever way I can! Just hesitant to jump in to further bisection...

[0] I'm not sure "quick" is the correct word given the amount of time this actually took.
rdl
Newbie
 
Posts: 1
Joined: Wed Jun 20, 2018 9:56 am

Previous

Return to Support Forum

Who is online

Users browsing this forum: TakashiHSD and 30 guests