Closed
Bug 1272114
Opened 9 years ago
Closed 9 years ago
CP+[GFX1-]: Invalid draw target type specified: 7
Categories
(Core :: Graphics, defect)
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)
996 bytes,
patch
|
nical
:
review+
|
Details | Diff | Splinter Review |
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.
Reporter | ||
Updated•9 years ago
|
Component: Untriaged → Graphics
OS: Unspecified → Windows 10
Product: Firefox → Core
Hardware: Unspecified → x86_64
Comment 1•9 years ago
|
||
Confirmed on Windows 7 (64bit) with Nightly (2016-05-11)
>Failure Log
>(#0) Error Invalid draw target type specified: 7
Status: UNCONFIRMED → NEW
status-firefox49:
--- → affected
Ever confirmed: true
Keywords: reproducible
OS: Windows 10 → Windows
Comment 2•9 years ago
|
||
Same error on my machine as well. Windows 8.1 x64, Nightly 2016-05-11, Intel Graphics 2000 with latest drivers.
![]() |
||
Comment 3•9 years ago
|
||
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
![]() |
||
Updated•9 years ago
|
Flags: needinfo?(sotaro.ikeda.g)
Reporter | ||
Comment 4•9 years ago
|
||
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.
![]() |
||
Comment 5•9 years ago
|
||
I can also reproduce with http://www.fishgl.com/ .
![]() |
||
Comment 6•9 years ago
|
||
[Tracking Requested - why for this release]:
status-firefox48:
--- → unaffected
tracking-firefox49:
--- → ?
Assignee | ||
Updated•9 years ago
|
Assignee: nobody → sotaro.ikeda.g
Assignee | ||
Comment 7•9 years ago
|
||
(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)
Assignee | ||
Comment 8•9 years ago
|
||
The following rejects SurfaceFormat::A8 DXGITextureData.
https://dxr.mozilla.org/mozilla-central/source/gfx/layers/d3d11/TextureD3D11.cpp#349
Assignee | ||
Comment 9•9 years ago
|
||
Assignee | ||
Comment 10•9 years ago
|
||
Attachment #8751556 -
Attachment is obsolete: true
Assignee | ||
Updated•9 years ago
|
Attachment #8751560 -
Flags: review?(nical.bugzilla)
Updated•9 years ago
|
Status: NEW → ASSIGNED
Hardware: x86_64 → All
Comment 11•9 years ago
|
||
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?
Assignee | ||
Comment 12•9 years ago
|
||
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)
Assignee | ||
Comment 13•9 years ago
|
||
Attachment #8751560 -
Attachment is obsolete: true
Assignee | ||
Updated•9 years ago
|
Attachment #8751642 -
Flags: review?(nical.bugzilla)
Comment 14•9 years ago
|
||
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+
Comment 15•9 years ago
|
||
Comment 17•9 years ago
|
||
bugherder |
Status: ASSIGNED → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla49
You need to log in
before you can comment on or make changes to this bug.
Description
•