788026 - Flickering in Ro.me demo rendering - black frames rendered / presented?

Status: RESOLVED INCOMPLETE

(Core :: Graphics, defect, P3)

Description

[Julian Adams]

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:17.0) Gecko/17.0 Firefox/17.0
Build ID: 20120903042010

Steps to reproduce:

Run the interactive video at Ro.me. Watch!


Actual results:

It runs, but there's flickering. It increases with time. There's some in the city 3D area, then lots in the 2D video and especially it's transition to the 3D landscape. 


Expected results:

No flickering!

Comment 1

[Julian Adams]

This is on a 2011 Mac Book Pro 13". 4GB RAM. Graphics:

Intel Inc. -- Intel HD Graphics 3000 OpenGL Engine -- 2.1 APPLE-7.18.18

Comment 2

[Virgil Dicu [:virgil] [QA]]

Could you paste your about:support Graphics information? 
Could you also post a small screencast of the issue?

Fort the record, this works fine for me on 10.7 with the Latest Aurora 17.

Comment 3

[Julian Adams]

(In reply to Virgil Dicu [:virgil] [QA] from comment #2)
> Could you paste your about:support Graphics information? 
> Could you also post a small screencast of the issue?
> 
> Fort the record, this works fine for me on 10.7 with the Latest Aurora 17.

info from about:support:

Graphics
            
Vendor ID 0x8086
Device ID 0x 126
WebGL Renderer: Intel Inc. -- Intel HD Graphics 3000 OpenGL Engine -- 2.1 APPLE-7.18.18
GPU Accelerated Windows: 3/3 OpenGL
AzureCanvasBackend: quartz
AzureFallbackCanvasBackend: none
AzureContentBackend: none

Comment 4

[Julian Adams]

(In reply to Virgil Dicu [:virgil] [QA] from comment #2)
> Could you paste your about:support Graphics information? 
> Could you also post a small screencast of the issue?
> 
> Fort the record, this works fine for me on 10.7 with the Latest Aurora 17.

Do you have any suggestions for the screen recording software?

Comment 5

[Virgil Dicu [:virgil] [QA]]

(In reply to Julian Adams from comment #4)
> Do you have any suggestions for the screen recording software?

You can use the Quick Time screen recording software (QuickTime-File-Scree Recording). There's also vid.ly available out there if there's any need in converting the video to html5 (usually useful for linux people)

Is this a regression, did the video previously work fine in other Firefox versions on your side?

Comment 6

[Virtual_ManPL [:Virtual] 🇵🇱 - (please needinfo? me - so I will see your comment/reply/question/etc.)]

(In reply to Julian Adams from comment #4)
> Do you have any suggestions for the screen recording software?

You can also try http://www.screenr.com/ (Java needed). It's 10fps only, so I don't know if this bug will be visible on this set.

Comment 7

[Julian Adams]

(In reply to Virgil Dicu [:virgil] [QA] from comment #5)
> (In reply to Julian Adams from comment #4)
> > Do you have any suggestions for the screen recording software?
> 
> You can use the Quick Time screen recording software (QuickTime-File-Scree
> Recording). There's also vid.ly available out there if there's any need in
> converting the video to html5 (usually useful for linux people)
> 
> Is this a regression, did the video previously work fine in other Firefox
> versions on your side?

It's a regresion. The video / webgl works (with more GC pauses) without flickering on Firefox 16.0b1 for me.

Comment 8

[Julian Adams]

(In reply to Julian Adams from comment #3)
> (In reply to Virgil Dicu [:virgil] [QA] from comment #2)
> > Could you paste your about:support Graphics information? 
> > Could you also post a small screencast of the issue?
> > 
> > Fort the record, this works fine for me on 10.7 with the Latest Aurora 17.
> 
<snip>

Attaching screencast now. The framerate is a bit low, but the black frames are clearly visible.

Comment 9

[Julian Adams]

Attachment: A screencast of a segment of ro.me showing the flickering / black frames

As requested a screencast of the bug. I've held on to the original video. If you need a different format just ask :) I've edited this down to the bare minimum to fit the upload limit. There's a big black screen just at the end too, I've left only a couple of correct frames in after it.

Comment 10

[Virgil Dicu [:virgil] [QA]]

Thanks, Julian.

Yeah, this doesn't look very nice. As you're the only one who can reproduce, do you think you might find a regression window for this one? http://harthur.github.com/mozregression/

17 was in Nightly from 2012-07-16 to 2012-08-27
https://wiki.mozilla.org/RapidRelease/Calendar

Comment 11

[Julian Adams]

I do this as soon as I can find a bit of time.

Comment 12

[Julian Adams]

I followed the instructions here: http://harthur.github.com/mozregression/, but moznightly fails, even with sudo:

sudo moznightly --date=2012-07-16

Downloading nightly from 2012-07-16

Starting nightly

XPCOMGlueLoad error 4:0 for file /Users/jools/moznightlyapp/Mozilla.app/Contents/MacOS/libxpcom.dylib:
image not found
Couldn't load XPCOM.
Could not kill process, could not find pid: 18187, assuming it's already dead

Comment 13

[Julian Adams]

Happily mozregression works!

mozregression --good=2012-07-16 --bad=2012-08-27
<snip>
Last good nightly: 2012-08-13
First bad nightly: 2012-08-14

Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=f89feda9d997&tochange=22288130fea2

Comment 14

[Virgil Dicu [:virgil] [QA]]

Thanks a lot, Julian!

Matt, there's a bunch of graphics related bugs you landed in the pushlog Julian posted in comment 13. Do you think the regression reported here might have something to do with any of them? 

If not, could you provide any leads as to where/whom to go next?

Comment 15

[Julian Adams]

btw at what point does the status become confirmed?

Comment 16

[Virgil Dicu [:virgil] [QA]]

When someone can confirm it's indeed an issue within Firefox. This one has enough information on its own to be escalated.

Comment 17

[Matt Woodrow (:mattwoodrow)]

I can reproduce this.

Since we now draw thebes layers, and composite them to the screen in separate steps, it's possible for us to composite twice without drawing in between.

This causes issues with WebGL, since we clear the texture when we composite.

I think we'll need to do the same at OMTC and double buffer here so that we can redraw the existing content if necessary.

It would be nice if we could reuse the OMTC double buffering code, not sure if that's practical.

CC'ing bjacob since he knows this code better

Comment 18

[Benoit Jacob [:bjacob] (mostly away)]

This could be related to bug 785838, which refactors the code handling the clearing of the WebGL drawing buffer, has a patch by jgilbert that is pending landing. It fixes bugs very similar to what you talk about in comment 17.

Comment 19

[Kelsey Gilbert [:jgilbert]]

OMTC double-buffering is very different, and is in various ways more and less complex than we need.

This is *very* likely to be bug 785838, for the reasons mattwoodrow and bjacob suggest.

Comment 20

[Kelsey Gilbert [:jgilbert]]

FWIW, this can easily be worked around by using preserveDrawingBuffer:true in rome.

Comment 21

[u279076]

Is this bug still reproducible in the current Firefox Nightly?