Closed
Bug 674731
Opened 13 years ago
Closed 13 years ago
WebGL/ANGLE interop with D3D layers requests incorrect extension
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
RESOLVED
FIXED
mozilla8
| Tracking | Status | |
|---|---|---|
| firefox5 | --- | unaffected |
| firefox6 | --- | fixed |
| firefox7 | --- | fixed |
People
(Reporter: jgilbert, Assigned: jgilbert)
References
Details
(Keywords: regression, Whiteboard: [qa-])
Attachments
(1 file)
|
4.85 KB,
patch
|
bjacob
:
review+
asa
:
approval-mozilla-aurora+
asa
:
approval-mozilla-beta+
|
Details | Diff | Splinter Review |
GLContextEGL requires extension "EGL_ANGLE_surface_d3d_share_handle", which no longer exists. According to the extension spec, the extension was renamed in version 2 to "EGL_ANGLE_surface_d3d_texture_2d_share_handle", but this change was evidently never factored back into GLContextEGL.
Refs:
http://www.khronos.org/registry/egl/extensions/ANGLE/EGL_ANGLE_surface_d3d_texture_2d_share_handle.txt
|
||
Comment 1•13 years ago
|
||
EGL_ANGLE_surface_d3d_share_handle only ever existed in a local patch that we used to have, not in upstream ANGLE.
When I upgraded ANGLE to r653 (bug 657748), I removed this patch as that functionality had been integrated upstream. I didn't notice that the extension name was different.
|
||
Updated•13 years ago
|
|
Assignee | |
Comment 2•13 years ago
|
||
Updates extension and relevant identifiers to match spec.
Fixed y-flip problem with shared textures.
Attachment #549201 -
Flags: review?(bjacob)
|
|
||
Updated•13 years ago
|
Attachment #549201 -
Flags: review?(bjacob) → review+
|
|
||
Updated•13 years ago
|
Summary: ANGLE layers acceleration requests incorrect extension → WebGL/ANGLE interop with D3D layers requests incorrect extension
|
|
||
Comment 3•13 years ago
|
||
Landed on central:
http://hg.mozilla.org/mozilla-central/rev/267ada59f86f
Please give us beta approval.
|
|
||
Updated•13 years ago
|
Attachment #549201 -
Flags: approval-mozilla-beta?
Attachment #549201 -
Flags: approval-mozilla-aurora?
|
|
||
Updated•13 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
|
||
Updated•13 years ago
|
Attachment #549201 -
Flags: approval-mozilla-beta?
Attachment #549201 -
Flags: approval-mozilla-beta+
Attachment #549201 -
Flags: approval-mozilla-aurora?
Attachment #549201 -
Flags: approval-mozilla-aurora+
|
||
Updated•13 years ago
|
Blocks: 657748
Keywords: regression
|
|
||
Comment 4•13 years ago
|
||
status-firefox8:
affected → ---
Target Milestone: --- → mozilla8
|
||
Comment 5•13 years ago
|
||
Mozilla/5.0 (Windows NT 6.1; rv:7.0) Gecko/20100101 Firefox/7.0
Can anyone please help me with a test case or with STR / guidelines that I can use to verify this fix?
Thank you
|
|
||
Comment 6•13 years ago
|
||
Actually, no, it's not very easy to verify this one. The only user-visible difference is speed: when we had this bug, running WebGL demos with a large window or full-screen was slower than normal.
In order to prevent this kind of regression in the future, we need WebGL performance tests: bug 676138.
Depends on: 676138
You need to log in
before you can comment on or make changes to this bug.
Description
•