Benoit Jacob [:bjacob] (mostly away) Assignee
	Description • 12 years ago

STR: load testcase

Expected: blank page

Actual: hit reload a few times, see some random junk.

Tested on a HTC One S with a Adreno 225 GPU.

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

Oh, actually the issue is not with resizing the canvas, it's with scaling it by setting a style size different from the drawing buffer size.

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

...which makes it more likely to be a gfx/layers bug than a WebGL bug.

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

New findings:
 - the drawing buffer itself is corrupted: these random pixels can be read by readPixels, as this testcase shows
 - this has nothing to do with scaled or resized canvases after all
 - this reproduces on a fresh new WebGL context, never resized or scaled
 - this only seems to affect canvases of width <= 16.

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

And so, back to the WebGL component. Sorry for the noise.

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

This is confirmed to be a Adreno driver bug: glClear is called by GLContext::ClearSafely during WebGL initialization, checked with GDB. It just doesn't do its job.

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

Michael, this is a bug in the Adreno driver: with a framebuffer object backed by a texture of width <= 16, glClear seems to not take effect. Any info on possible work-arounds / scope of bug / hope of fixes would be greatly appreciated!

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

FWIW I stumbled upon this while writing the ATC conformance test (which uses a 16x8 canvas) and this soft-blocks it -- I can still write a conformance test with that bug, but not the one I'd like to.

	Michael Vines [:m1] [:evilmachines]
	Comment 8 • 12 years ago

Can you please let me know the "Version:" of the driver in use here.  I need that to map back into the source internally.

e.g:
E/GeckoConsole(  904): OpenGL LayerManager Initialized Succesfully.
E/GeckoConsole(  904): Version: OpenGL ES 2.0 V@6.0 AU@04.00.04.19.229 (CL@)
E/GeckoConsole(  904): Vendor: Qualcomm
E/GeckoConsole(  904): Renderer: Adreno (TM) 200
E/GeckoConsole(  904): FBO Texture Target: TEXTURE_2D

Also does the issue still manifest with the latest driver from  
https://developer.qualcomm.com/download?  (Search for "Adreno 2xx User-mode Android ICS Graphics Driver (ARMv7)" link in the bottom half of the page).

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

Traveling (to Khronos F2F), will be back on Thursday. Jeff, if you want to check this for me, this is the HTC/Adreno phone you had lent me, it's sitting on my desk.

	Al Billings [:abillings - ex-MoCo]
	Comment 10 • 12 years ago

Can we get an update here? It has been over three months.

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

Oops, looks like I dropped this ball. Will look into it on Monday.

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

fixed the testcase in success case

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

So I tried on a bunch of Adreno phones to see how widespread the problem is:

Does not reproduce:

Otoro
Unagi

Reproduces:

HTC One S
 (Hardware: ville, GPU: Adreno 225)

WebGL blocked on:

HTC "passion"
 (Hardware: mahimahi, GPU: Adreno 200)
HTC "supersonic"
 (Hardware: supersonic, GPU: Adreno 200)
HTC Desire HD
 (Hardware: spade, GPU: Adreno 205)

So, possibly thanks to WebGL being blacklisted on old Adreno drivers, the HTC One S was the only phone on which I could reproduce.

Most importantly, the B2G prototype phones (Otoro and Unagi) are unaffected!

At this point I'm not concerned anymore by this bug; if you want, we can blacklist WebGL on the HTC One S, but that's about it.

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

Comment on attachment 702978 [details] [diff] [review]
blacklist WebGL on HTC One S ("ville")

Review of attachment 702978 [details] [diff] [review]:
-----------------------------------------------------------------

::: widget/android/GfxInfo.cpp
@@ +345,5 @@
>          *aStatus = nsIGfxInfo::FEATURE_BLOCKED_DEVICE;
>          return NS_OK;
>        }
> +
> +      if (mHardware.Equals(NS_LITERAL_STRING("ville"), nsCaseInsensitiveCStringComparator())) {

Equals not StartsWith or Contains, or similar?

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

I think we really want Equals there. Suppose that Zynga gets in the business of making phones next year and names their hardware "farmville" .

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

http://hg.mozilla.org/integration/mozilla-inbound/rev/31399fd0cb5b

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

Build bustage; hotfix consists in dropping the attempt at case-insensitiveness. -1 for our string classes (case-insensitive compares should be easy, they're not).

https://hg.mozilla.org/integration/mozilla-inbound/rev/8f213db8fe7f

	David Baron :dbaron:
	Comment 19 • 12 years ago

Backed out speculatively as the possible cause of android reftest-4 failures (for lack of any better guesses that I could find):
https://hg.mozilla.org/integration/mozilla-inbound/rev/d9d98ffe9ecc

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

Still failing:
https://tbpl.mozilla.org/?tree=Mozilla-Inbound
also, the reftest failure was a SVG reftest, according to the logs.

	Ryan VanderMeulen [:RyanVM]
	Comment 21 • 12 years ago

https://hg.mozilla.org/mozilla-central/rev/b52b445017c9
https://hg.mozilla.org/mozilla-central/rev/cf4db0037c7e

	bhavana bajaj [:bajaj]
	Comment 22 • 12 years ago

[Security Triage] Marking esr17/b2g unaffected as this affected driver may not be used there.Please help with comment's if this was misunderstood for b2g.Thanks