Julian Adams Reporter
	Description • 12 years ago

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!

	Julian Adams Reporter
	Comment 1 • 12 years ago

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

	Virgil Dicu [:virgil] [QA]
	Comment 2 • 12 years ago

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.

	Julian Adams Reporter
	Comment 3 • 12 years ago

(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

	Julian Adams Reporter
	Comment 4 • 12 years ago

(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?

	Virgil Dicu [:virgil] [QA]
	Comment 5 • 12 years ago

(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?

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

(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.

	Julian Adams Reporter
	Comment 7 • 12 years ago

(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.

	Julian Adams Reporter
	Comment 8 • 12 years ago

(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.

	Julian Adams Reporter
	Comment 9 • 12 years ago

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.

	Virgil Dicu [:virgil] [QA]
	Comment 10 • 12 years ago

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

	Julian Adams Reporter
	Comment 11 • 12 years ago

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

	Julian Adams Reporter
	Comment 12 • 12 years ago

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

	Julian Adams Reporter
	Comment 13 • 12 years ago

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

	Virgil Dicu [:virgil] [QA]
	Comment 14 • 12 years ago

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?

	Julian Adams Reporter
	Comment 15 • 12 years ago

btw at what point does the status become confirmed?

	Virgil Dicu [:virgil] [QA]
	Comment 16 • 12 years ago

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

	Matt Woodrow (:mattwoodrow)
	Comment 17 • 12 years ago

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

	Benoit Jacob [:bjacob] (mostly away)
	Comment 18 • 12 years ago

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.

	Kelsey Gilbert [:jgilbert]
	Comment 19 • 12 years ago

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.

	Kelsey Gilbert [:jgilbert]
	Comment 20 • 12 years ago

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

	u279076
	Comment 21 • 8 years ago

Is this bug still reproducible in the current Firefox Nightly?