It would really nice to have b2g oop again. It seems to work but we don't render content from child processes. For the homescreen we only get the background image. I can still click on the homescreen and open apps. The browser for example renders the UI but any content is only white. The clock app for example just shows a white screen. If I go to the window manager I see the correct screenshot of the app.
Blake, you looked at this a little bit. Can you add any findings here?
I didn't really look into the painting stuff very much.
Milan, can we get an estimation here when someone can take a look? oop b2g-desktop has been broken for months. Debugging our koi+ bugs takes much longer because of this.
I appreciate the difficulty without the desktop tools, but people have been trigger happy on making graphics bugs koi+, so this is going to wait until those are cleared. I'd say December at the earliest.
Based on comment 4 moving to 1.3
(In reply to Milan Sreckovic [:milan] from comment #4) > I appreciate the difficulty without the desktop tools, but people have been > trigger happy on making graphics bugs koi+, so this is going to wait until > those are cleared. I'd say December at the earliest. Thanks for the reply. So this means we are not gonna have it for any 1.3 features. It's important to know for our planning.
Is this a regression?
(In reply to Andreas Gal :gal from comment #7) > Is this a regression? Yes, but unclear when it regressed. B2g-desktop OOP was completely broken for months now. We had to fix many bugs to get it working again and this seems the last piece to make it work on mac again. jgriffin is also ready to turn on tests for it so we don't end up regressing it again.
Lets identify the bug. This can't be that hard. Can you describe the simplest possible test case to me?
mhenretty and I will look at this tomorrow.
(In reply to Andreas Gal :gal from comment #9) > Lets identify the bug. This can't be that hard. Can you describe the > simplest possible test case to me? 1) Enable oop by switching http://hg.mozilla.org/mozilla-central/file/19fd3388c372/b2g/app/b2g.js#l254 2) make a b2g-desktop build and start with a fresh profile. 3a) and we have a new regression: bug 930836 3b) otherwise you would just see a white screen whenever a content process is visible (like homescreen). The homescreen still works because random clicking opens applications and if I hit the browser, I see the browser UI. Trying to find the regression for bug 930836 now.
This regression is exactly why we need the gfx code fixed. It's blocking turning on a whole lot of other tests, and until we have those tests running other things are going to keep regressing. This is actively preventing people from doing B2G development. It should definitely be a higher priority than any 1.3 work.
Created attachment 823733 [details] [diff] [review] Force b2g-desktop to composite on OSX. bent, mhenretty and I debugged this over the past couple of days. With this patch as well as: diff --git a/b2g/app/b2g.js b/b2g/app/b2g.js index bc73180..11b4466 100644 --- a/b2g/app/b2g.js +++ b/b2g/app/b2g.js @@ -251,8 +251,8 @@ pref("ui.dragThresholdY", 25); // Layers Acceleration. We can only have nice things on gonk, because // they're not maintained anywhere else. #ifndef MOZ_WIDGET_GONK -pref("dom.ipc.tabs.disabled", true); -pref("layers.offmainthreadcomposition.enabled", false); +pref("dom.ipc.tabs.disabled", false); +pref("layers.offmainthreadcomposition.enabled", true); pref("layers.offmainthreadcomposition.async-animations", false); pref("layers.async-video.enabled", false); #else we paint child processes and things seem to work. Looking at the bug that added this call, it seems like it should be safe to disable it. The basic problem is that we refuse to do OMTC on transparent windows on Mac.
But the window should not be transparent, should it? nsContainerFrame::SyncWindowProperties should call nsChildView::SetTransparencyMode(eTransparencyOpaque), which should forward it to nsCocoaWindow::SetTransparencyMode(eTransparencyOpaque), which should call [mWindow setOpaque:NO]. Is that call not happening? Or does it happen after we've already made the decision not to do OMTC?
Comment on attachment 823733 [details] [diff] [review] Force b2g-desktop to composite on OSX. I guess for a quick fix to unblock things this is ok, but in that case please file a bug for finding the answer to comment 14 and reference the bug number in the code.
In related news, why does it bother the OMTC code that the window is transparent?
It bothers it if the window has a shadow (or at least it only has a reason to be bothered in the shadow case, not sure if the code reflects that) because OS X only draws a correct shadow for transparent windows when we're drawing without HWA into the normal window pixel buffer and not into an OpenGL context, and we only support OMTC with GL.
\o/ Thanks everyone! https://hg.mozilla.org/integration/b2g-inbound/rev/cf582248b52e
I have the followup bug asked for in comment 15 sitting in a tab at home just waiting for me to click on "submit." I'll do that tonight.
https://hg.mozilla.org/mozilla-central/rev/cf582248b52e
(In reply to Blake Kaplan (:mrbkap) from comment #19) > I have the followup bug asked for in comment 15 sitting in a tab at home > just waiting for me to click on "submit." I'll do that tonight. This is now bug 933106.
Already in 1.3, clearing nom.
or