Closed Bug 575855 Opened 12 years ago Closed 12 years ago

Transitions from fullscreen briefly show an aero basic window frame

Categories

(Core :: Widget: Win32, defect)

x86
Windows 7
defect
Not set
normal

Tracking

()

RESOLVED FIXED
Tracking Status
blocking2.0 --- final+

People

(Reporter: robarnold, Assigned: jimm)

References

Details

Attachments

(1 file, 1 obsolete file)

it quickly redraws a glass frame. Not sure what's going on.
This bug report is fairly vague, but on my system at work the graphics card is slow enough that I can tell the window is being opened on one screen in some weird UI, then resized on my second monitor's desktop, then removed from my first display. This is a change from the last Mozilla Developer Preview -> 4.0b1
Anybody want to set this to blocking final?
(In reply to comment #1)
> This bug report is fairly vague, but on my system at work the graphics card is
> slow enough that I can tell the window is being opened on one screen in some
> weird UI, then resized on my second monitor's desktop, then removed from my
> first display. This is a change from the last Mozilla Developer Preview ->
> 4.0b1

This should be fixed.(In reply to comment #2)

> Anybody want to set this to blocking final?

I don't think the original bug blocks, it's pretty minor IMHO.
(In reply to comment #3)
> This should be fixed.(In reply to comment #2)

Excellent. Is this for 4.0 release?

> > Anybody want to set this to blocking final?
> 
> I don't think the original bug blocks, it's pretty minor IMHO.

I'm not sure what 'blocks' means in this context, but I will assume it means the blocking of 4.0 until the bug is fixed? Personally I find it a major bug on low-end systems since graphics cards with low performance or memory cause the system to take half a second to draw/resize the window. At work adding this up over the entire day means a lot of time wasted and a lot of irritation.

We all have our pet peeves though so I can understand prioritizing more important bugs.
(In reply to comment #4)
> (In reply to comment #3)
> > This should be fixed.(In reply to comment #2)
> 
> Excellent. Is this for 4.0 release?
> 
> > > Anybody want to set this to blocking final?
> > 
> > I don't think the original bug blocks, it's pretty minor IMHO.
> 
> I'm not sure what 'blocks' means in this context, but I will assume it means
> the blocking of 4.0 until the bug is fixed? Personally I find it a major bug on
> low-end systems since graphics cards with low performance or memory cause the
> system to take half a second to draw/resize the window. At work adding this up
> over the entire day means a lot of time wasted and a lot of irritation.

If you could snap a screen shot of what you're seeing that would be helpful.

Even if the aero basic frame didn't show, how would this effect time wasted in redrawing the window? If resizing & drawing performance is an issue on slower systems, that's a different bug.
Attached patch patch v.1 (obsolete) — Splinter Review
Initial shot at fixing this. Parts of the frame gets painted during the change to styles in HideWindowChrome via MakeFullscreen.

    style = tempStyle & ~(WS_CAPTION | WS_THICKFRAME);
    exStyle = tempExStyle & ~(WS_EX_DLGMODALFRAME | WS_EX_WINDOWEDGE |
                              WS_EX_CLIENTEDGE | WS_EX_STATICEDGE);

I'm still curious though why windows does this. This path suppresses the update.

Also, there's a secondary bug in this. We update the glass margins during the initial stage of reflow for the resize, before content gets painted. Windows however updates the glass on the original normalized window immediately. So what we see is a normalized window where the glass briefly turns to black, then we repaint as a full screen window. It would be nice if we could find a way to prevent this, it's pretty ugly. I'll probably file off another bug on that though since it's not related to the issue described in this bug.
Comment on attachment 472187 [details] [diff] [review]
patch v.1

This looks great in release builds. The transition is much smoother.
Attachment #472187 - Flags: review?(vladimir)
blocking2.0: --- → ?
Assignee: nobody → jmathies
http://hg.mozilla.org/mozilla-central/rev/3db393b691be
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Depends on: 594773
backed out due to regression on themed desktops. (bug 594773)

http://hg.mozilla.org/mozilla-central/rev/ce4dbcbc75a2
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch patch v.2Splinter Review
Just a slight variation - restricting these change to glass desktops.

A few side notes - this is present in 3.6, and also ie. We probably dont' need to block on this if we find other issues. 

I did a little additional experimenting around with handling the wm_nccalcsize event to try and prevent windows from preserving the main window on the resize, but ran into a bunch of problems. I think I'll spin that out into another bug.
Attachment #472187 - Attachment is obsolete: true
Attachment #475558 - Flags: review?(vladimir)
http://hg.mozilla.org/mozilla-central/rev/8b4dc40a4138
Status: REOPENED → RESOLVED
Closed: 12 years ago12 years ago
Resolution: --- → FIXED
Blocks: 597066
Note this code was removed in bug 634586.
You need to log in before you can comment on or make changes to this bug.