Closed Bug 1272114 Opened 8 years ago Closed 8 years ago

CP+[GFX1-]: Invalid draw target type specified: 7

Categories

(Core :: Graphics, defect)

49 Branch
All
Windows
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla49
Tracking Status
firefox48 --- unaffected
firefox49 + fixed

People

(Reporter: streetwolf52, Assigned: sotaro)

References

Details

(Keywords: reproducible)

Attachments

(1 file, 2 obsolete files)

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:49.0) Gecko/20100101 Firefox/49.0
Build ID: 20160511073006

Steps to reproduce:

Installed latest inbound at http://archive.mozilla.org/pub/firefox/tinderbox-builds/mozilla-inbound-win64-pgo/

Go to http://www.weather.com/weather/today/l/07746:4:US


Actual results:

about:support shows this under Graphics section:

Failure Log
(#0) 	CP+[GFX1-]: Invalid draw target type specified: 7


Expected results:

Don't know what the message means.
Component: Untriaged → Graphics
OS: Unspecified → Windows 10
Product: Firefox → Core
Hardware: Unspecified → x86_64
Confirmed on Windows 7 (64bit) with Nightly (2016-05-11)

>Failure Log
>(#0) Error	Invalid draw target type specified: 7
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: reproducible
OS: Windows 10 → Windows
Same error on my machine as well. Windows 8.1 x64, Nightly 2016-05-11, Intel Graphics 2000 with latest drivers.
I can reproduce on win32 build as well as win64 build.

Regression window:
https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=d372ddfd228f0648d6925576a70a485cc50a3687&tochange=d6eac6cc4588db01c0654ea952d7a68027a4a77f

Regressed by: d6eac6cc4588	Sotaro Ikeda — Bug 1252405 - Reduce MaskLayer's memory usage r=mattwoodrow
Blocks: 1252405
Flags: needinfo?(sotaro.ikeda.g)
Another site with the same error message: http://www.cnn.com/2016/05/11/entertainment/azealia-banks-skai-jackson/index.html.  I also had a completely different error message but couldn't locate the site that caused it.
I can also reproduce with http://www.fishgl.com/ .
[Tracking Requested - why for this release]:
Assignee: nobody → sotaro.ikeda.g
(In reply to Gary [:streetwolf] from comment #0)
> 
> Failure Log
> (#0) 	CP+[GFX1-]: Invalid draw target type specified: 7
> 

This is a false alarm. The error needs to be suppressed.

When it happens, BackendType is DIRECT2D1_1. It does not support Factory::CreateDrawTargetForData(). Then the function failed and fallbacked to  BackendType::CAIRO. DXGITextureData does not support SurfaceFormat::A8 then BufferTextureData is created instead of DXGITextureData, then hit the error out put.
Flags: needinfo?(sotaro.ikeda.g)
The following rejects SurfaceFormat::A8 DXGITextureData.
 https://dxr.mozilla.org/mozilla-central/source/gfx/layers/d3d11/TextureD3D11.cpp#349
Attached patch patch - Suppress error log (obsolete) — Splinter Review
Attached patch patch - Suppress error log (obsolete) — Splinter Review
Attachment #8751556 - Attachment is obsolete: true
Attachment #8751560 - Flags: review?(nical.bugzilla)
Comment on attachment 8751560 [details] [diff] [review]
patch - Suppress error log

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

This patch is fine, but I am not found of the idea that we create a BuffeTextureData with a D2D backend in the first place. I would prefer that we make it so that TextureClient::CreateForRawBufferAccess picks a non-d2d fallback backend before creating the texture. This way we'd also avoid the log and we'd have a less surprising state. How does that sound to you?
Comment on attachment 8751560 [details] [diff] [review]
patch - Suppress error log

Thanks for the advice. I am going to try less hacky way.
Attachment #8751560 - Flags: review?(nical.bugzilla)
Attachment #8751560 - Attachment is obsolete: true
Attachment #8751642 - Flags: review?(nical.bugzilla)
Comment on attachment 8751642 [details] [diff] [review]
patch - Suppress error log

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

Cool! long term it'd be nice that gfxPlatofrm or something like that expose a fallback content backend so that we can use that instead (the fallback could be skia software for example), but that's beyond this bug.
Attachment #8751642 - Flags: review?(nical.bugzilla) → review+
Let's track this for 49.
https://hg.mozilla.org/mozilla-central/rev/8a9938ff5877
Status: ASSIGNED → RESOLVED
Closed: 8 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: