Closed Bug 943204 Opened 8 years ago Closed 8 years ago
OMTC rendering to popup windows (e
.g ., Australis menu)
Using OMTC to render to popup windows on Windows is broken. Nothing renders at all. There are absolutely no error messages, even from d3d in debug mode. This only happens on Windows (Linux is fine) and is independent of backend (basic, d3d9, and d3d11 are all broken in the same way). Rendering the main window OMTC and the popup MT is OK (note that the Australis menu is a panel, so IsSmallPopup is false, so OMTC is the default way to render it). Works fine for MT rendering with any backend. With d3d9 I have verified that everything is happening OK (data is drawn correctly on the main thread, uploading to d3d texture is OK (and I dumped just before upload, so communication to the compositor is OK), all the correct setup is happening and in the right order (i.e., we are not initialising one compositor then drawing with another), nothing is returning failure values). Compositing is happening and we get the expected number of DrawQuad calls, again no early return, no errors. Just nothing appearing on screen. As expected, we have a single d3d9 device and two d3d9 swap chains. With basic, we do not initialise properly - we fail here (http://dxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp#3553) because the gfxWindowsSurface has 0 size. I could not work out why. There is nothing else wrong with it. I replaced this code with code using the size from GetClientBounds, but still nothing. I experimented with using various different HDCs but that didn't seem to help. The widget looks fine, afaict - correct size, no worrying field values. mTransparencyMode == eTransparencyOpaque, which triggers some special cases, but we seem to do the same thing for MT and OMTC rendering. Anyone got any ideas?
I have a similar bug on mac. There ContentClientIncremental is broken I believe (verifying as we speak).
In case anyone wants to try this out, just run a nightly recent enough to have Australis, flick the OMTC pref, restart, click the hamburger menu icon. Expected: you see the menu; found: you don't.
(In reply to Matt Woodrow (:mattwoodrow) from comment #3) > http://mxr.mozilla.org/mozilla-central/source/gfx/layers/d3d9/ > DeviceManagerD3D9.cpp#58 > > Is that rect normal? Yes, it is fine.
I got a lead! As I mentioned above, mTransparencyMode == eTransparencyTransparent for the popup (also for the main window, I think). There are a few cases where that forces a separate path. I tried undoing a few of them before, but to no avail. However, if I always force mTransparencyMode to be eTransparencyOpaque, then I see the menu (rendered poorly for obvious reasons, but it is there). Tomorrow I will figure this out properly.
Reversing the check added in bug 802316 so that we get a LAYERED window, but not a COMPOSITED one makes the menu visible, but not transparent. I don't know why this would only affect OMTC rendering yet, but we do some funky stuff for rendering to transparent windows that we might not be doing correctly with OMTC. James: do you have any insight as to what might be happening here?
Just removing the check from bug 802316 entirely has the same effect - the menu renders but what should be transparent is rendered as black.
You might try removing the WS_EX_COMPOSITED flag on popup creation to see if you get the same effect as reversing bug 802316. http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp#485 I remember running into similar effects (black popups) when trying to change flags later
(In reply to James from comment #8) > You might try removing the WS_EX_COMPOSITED flag on popup creation to see if > you get the same effect as reversing bug 802316. > http://mxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp#485 > > I remember running into similar effects (black popups) when trying to change > flags later The menu/window is still invisible. So, this looks like I need WS_EX_COMPOSITED to see the window. I am not sure why that is. Perhaps the behaviour around WM_PAINT messages is changed. Also, I don't understand why I am not getting transparency. I suspect that solving things this way is not correct, and somehow our handling of the memory DC for translucent images is not playing well with OMTC.
Attachment #8339666 - Flags: review?(dvander)
So, turns out the Window style flags had nothing to do with this. For transparent windows we do a whole bunch of fun stuff using an in-memory bitmap. That requires using the correct DC for drawing and calling UpdateTranslucentWindow() after drawing (frustratingly, I tried both of these things earlier, but didn't realise they were closely related, so I didn't try doing both). For the HWA compositors, we just need to not use them for transparent windows, just like we don't for main thread rendering (http://dxr.mozilla.org/mozilla-central/source/widget/windows/nsWindow.cpp#3282).
Comment on attachment 8339666 [details] [diff] [review] Fix basic compositor Review of attachment 8339666 [details] [diff] [review]: ----------------------------------------------------------------- ::: widget/windows/nsWindow.cpp @@ +3557,1 @@ > ReleaseDC(mWnd, mCompositeDC); Change this to FreeNativeData()
Attachment #8339667 - Flags: review?(matt.woodrow) → review+
(In reply to Matt Woodrow (:mattwoodrow) from comment #13) > Comment on attachment 8339666 [details] [diff] [review] > Fix basic compositor > > Review of attachment 8339666 [details] [diff] [review]: > ----------------------------------------------------------------- > > ::: widget/windows/nsWindow.cpp > @@ +3557,1 @@ > > ReleaseDC(mWnd, mCompositeDC); > > Change this to FreeNativeData() Good catch, thanks
With Matt's change
Attachment #8339723 - Flags: review?(dvander) → review+
Status: NEW → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla28
I managed to reproduce the issue using Nightly 28.0a1 (2013-11-30)  and Fx 27.0.1 (Build ID: 20140212131424)  with the layers.offmainthreadcomposition.enabled pref set to true. I was able to confirm the fix for this issue on Windows 7 64-bit, using: - the latest Beta (Build ID: 20140213172947)  - the latest Aurora (Build ID: 20140217004001)  - the latest Nightly (Build ID: 20140217030202)   Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0  Mozilla/5.0 (Windows NT 6.1; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0  Mozilla/5.0 (Windows NT 6.1; WOW64; rv:29.0) Gecko/20100101 Firefox/29.0  Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:30.0) Gecko/20100101 Firefox/30.0
Status: RESOLVED → VERIFIED
Hardware: x86 → All
You need to log in before you can comment on or make changes to this bug.