User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20051111 Firefox/1.5 When a XUL window has a transparent background with some element in it and is minimized and reopened, the window is black for a while before after all the elements appear. Reproducible: Always Steps to Reproduce:

Press minimize and then open the window up again.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051211 Firefox/1.6a1 ID:2005121105 WFM Maybe it's your graphics drivers or something else?

This problem has been seen in various computers, the testcase I have provided isnt a very good one. Let me see if I can make a testcase that really shows this problem.

The problem is when there is an a very complex XUL with transparencies, and it is opened from a minimized state. If there is movement or animation on the XUL, it flashes with a black outline of the window and then renders the window. If there isnt, the window is black until some kind of action if performed on it. I am trying to find out if my employer will let me publish the XUL that is giving the problem.

The previous testcase was a half baked one, this one is a much better.

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a1) Gecko/20051211 Firefox/1.6a1 ID:2005121105 I'm not seeing a black window when restoring from minimized, but I am seeing a hitch. Same with resizing - it's pretty slow.

That little hitch is a black screen, not very clear in the testcase though, the XUL is not complex enough.

Maybe Dainis can help us here.

my bad, the previous fix doesnt fix it, sorry!

now this fixes it.

Comment on attachment 205829 [details] [diff] [review] with comments Looks good to me, but I want Dainis to sign off on it.

Comment on attachment 205829 [details] [diff] [review] with comments We do not need confusing comments that it is some kind of HACK. There is no black magic and it is not related to complexity of XUL. Simply in ResizeTranslucentWindow () we discard the original memory Bitmap and create new one that is initialized to 0. Thus the black rectangle. Your approach with forcing repaint might look like this: #ifdef MOZ_XUL if (mIsTranslucent) { ResizeTranslucentWindow(newWidth, newHeight); if (newWidth > mLastSize.width || newHeight > mLastSize.height) Invalidate(PR_TRUE); } #endif Please note that your version did not checked for !mPainting. But I much better prefer the solution that ResizeTranslucentWindow () actually preserves that is already drawn in current memory bitmap and after creating new memory bitmap copies these old bits back. Then if moved before ::RedrawWindow it should be sufficient with drawing only in those parts that got revealed by window size increase and no full invalidation should be required. I will modify ResizeTranslucentWindow to see if it really helps .

The actual problem was that ::RedrawWindow actually do affect layered translucent windows and send them WM_PAINT messages which they usually do not receive. As result OnPaint (0) was called for translucent windows which usually received the mMemoryDC as parameter. Because of wrong DC the black rectangle (all zeros) appeared. I made a change in nsWindow::ProcessMessage to not send invalidates for layered translucent windows. As a safeguard in nsWindow::OnPaint I've added check to ignore paint requests for layered translucent windows that are targeted to window DC instead of mMemoryDC.

Dainis, I checked this in for you. Thanks!!!

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20051218 SeaMonkey/1.5a Build ID: 2005121823 I don't see a difference on the testcases, the browser maximizes instantly, on the 2nd testcase then there are some seconds delay showing the windows desktop in the content area, then the xul content is rendered. There is no color 'transparent' in the testcases, a typo has caused the writing 'transaprent' in all cases. To minimize I had to use the Windows button in the title bar. JS console is showing errors: Error: Expected color but found 'transaprent'. Error in parsing value for property 'background-color'. Declaration dropped. Source File: data:text/css,window {background-color: transaprent;} ... Error: Expected color but found 'transaprent'. Error in parsing value for property 'background-color'. Declaration dropped. Source File: https://bugzilla.mozilla.org/attachment.cgi?id=205634 Line: 0 Error: window.minimize is not a function Source File: https://bugzilla.mozilla.org/attachment.cgi?id=205634 Line: 1

256 level alpha translucency is not supported on Win95, Win98 or WinME. Every pixal that is not fully trasparent (alpha=0) will be fully opaque (alpha=255). You need Win2k or newer to see desired effect! However that is unrelated to the typo in testcase. I've seen these warnings in debug build, too.

According to the blog of GDI guru Lou Amadio: "Be careful of WM_PAINT with a layered window. Specifically, I'm referring to a WM_PAINT that shouldn't happen when you call UpdateLayeredWindow. In the window proc for a layered window, you should always handle WM_PAINT, call BeginPaint and EndPaint. You don't have to do anything in the middle. If you don't do this, windows will assume that the window is still invalid and pump another WM_PAINT. It does this over and over causing 100% CPU utilization..." My previous patch was not affected by this, because I avoided the generation of WM_PAINT. But if some other code path or some other application will generate unexpected WM_PAINT then that leads to 100% CPU consumption. I verified that that is the case by forcing needInvalidate = PR_TRUE in WM_WINDOWPOSCHANGED handler. After the window minimize and then maximize the CPU usage was 100%.

Robert, You will check in the last patch and close the defect, right?

sure. Checked in.