1098008 - OMTC: Black flashes when maximizing/resizing windows

Status: RESOLVED INCOMPLETE

(Core :: Graphics: Layers, defect)

Description

[dagger.bugzilla]

Attachment: firefox-omtc-maximize.png

I get a brief flash of black when maximizing windows, as seen in the attached screenshot. Making a window larger by dragging the corner also leads to similar blackness in the new area, before it's redrawn with the window contents. That's not supposed to happen, and it doesn't look too great.

Bug 912352 comment 1 suggests that the color used to fill the region can be changed to white. That would definitely be an improvement with pages that have a white background, but it'd be worse with dark pages, and it wouldn't eliminate the actual problem of having an extra render of wrong content flashing briefly. The normal behavior here seems to be to leave the new area transparent until it can be painted with proper content.

(XP, and same results with or without hardware acceleration enabled.)

Comment 1

[Milan Sreckovic [:milan] (needinfo for best results)]

Does this depend on OMTC basic?

Comment 3

[Milan Sreckovic [:milan] (needinfo for best results)]

Do you still see this problem?

Comment 4

[dagger.bugzilla]

I can't check Nightly right now because of bug 1099339, but I don't think it's bug 1086985 because a) this occurs on all pages, and b) it occurs on 33.1.1 and today's Aurora too.

It doesn't depend on OMTC basic; here's the Graphics section from about:support with hardware accel on:

Graphics
Adapter Description	AMD Radeon HD 6800 Series
Adapter Drivers		ati2dvag
Adapter RAM		Unknown
Device ID		0x6739
DirectWrite Enabled	false (0.0.0.0)
Driver Date		4-11-2013
Driver Version		9.0.100.1000
GPU #2 Active		false
GPU Accelerated Windows	1/1 Direct3D 9 (OMTC)
Subsys ID		03b41043
Vendor ID		0x1002
WebGL Renderer		Google Inc. -- ANGLE (AMD Radeon HD 6800 Series Direct3D9 vs_3_0 ps_3_0)
windowLayerManagerRemote	true
AzureCanvasBackend	skia
AzureContentBackend	cairo
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0

(although, as I said, I see the same thing with hardware accel off too.)

Comment 5

[dagger.bugzilla]

Attachment: capture.webm

I managed to catch it on video.

Comment 6

[dagger.bugzilla]

I still see it in the latest Nightly, so it's definitely not bug 1086985.

Comment 7

[dagger.bugzilla]

Okay, I know it's taken me a shockingly long time to find my Win7 VM, get it working again and test this, but: I see it on Win7 too, with or without Aero. "0/1 Basic (OMTC)" in both cases, since hardware acceleration doesn't seem to want to turn on in VMware even with gfx.direct2d.force-enabled/layers.acceleration.force-enabled.

Aero has slightly different behavior to non-Aero, in that Aero fills the area with white pixels first. OMTC rendering then fills the area with black pixels, before finally drawing the actual content. Switching to a hard-coded white fill (instead of a black one) would effectively fix this on Aero. Unfortunately, it wouldn't fix the non-Aero/XP case, where the default fill is transparent (or the window isn't painted or something -- I'm not really familiar with Windows GUI). So I'd really like to see either a) filling it with transparent pixels (if that's a thing), b) limiting painting to the non-black areas until they're filled in with real content, or c) just not rendering anything until new content is actually ready to be rendered. I guess at least c) ought to be possible, because maximize already works like that some of the time.

Comment 8

[Milan Sreckovic [:milan] (needinfo for best results)]

:nical, let's understand what's going on here.

Comment 9

[Gregory Pappas [:gregp]]

Reporter, are you still experiencing this issue?

Comment 10

[BugBot [:suhaib / :marco]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:bhood, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.