Closed
Bug 667885
Opened 13 years ago
Closed 13 years ago
about:support causes screen freeze
Categories
(Core :: Graphics: CanvasWebGL, defect)
Tracking
()
RESOLVED
FIXED
mozilla9
People
(Reporter: heeen, Assigned: heeen)
Details
Attachments
(4 files)
46.02 KB,
text/x-log
|
Details | |
2.47 KB,
patch
|
romaxa
:
review-
|
Details | Diff | Splinter Review |
4.38 KB,
text/plain
|
Details | |
6.62 KB,
patch
|
cwiiis
:
review+
|
Details | Diff | Splinter Review |
Opening about:support with ogl layers enabled causes the screen to freeze for some reason. I tried to force a MakeCurrent in LayerManagerOGL::Render but that didn't help. Also regular webGL stuff in content works as expected. I suppose this problem is caused by the webGL context being created in a chrome context?
Assignee | ||
Comment 1•13 years ago
|
||
Initializing context 0x443fb340 surface 0x443d8800 on display 0x2 0x443db000 MakeCurrent force=0 0x443db000 MakeCurrent force=0 Initializing context 0x443fb460 surface 0x435d3c00 on display 0x2 0x443dc000 MakeCurrent force=0 0x443dc000 MakeCurrent force=0 0x443dc000 MakeCurrent force=0 WEBGL MakeCurrent [gl:0x443dc000] > void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [gl:0x443dc000] < void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [gl:0x443dc000] < void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [gl:0x443dc000] < void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [gl:0x443dc000] < void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [gl:0x443dc000] < void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [gl:0x443dc000] < void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [gl:0x443dc000] < void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [gl:0x443dc000] < void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [gl:0x443dc000] < void mozilla::gl::GLContext::fGetIntegerv(GLenum, GLint*) [0x0000] --- WebGL context created: 0x443dc000 0x443dc000 MakeCurrent force=0 WEBGL MakeCurrent [gl:0x443dc000] > void mozilla::gl::GLContext::fBindFramebuffer(GLenum, GLuint) [gl:0x443dc000] < void mozilla::gl::GLContext::fBindFramebuffer(GLenum, GLuint) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::raw_fViewport(GLint, GLint, GLsizei, GLsizei) [gl:0x443dc000] < void mozilla::gl::GLContext::raw_fViewport(GLint, GLint, GLsizei, GLsizei) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fClearColor(GLclampf, GLclampf, GLclampf, GLclampf) [gl:0x443dc000] < void mozilla::gl::GLContext::fClearColor(GLclampf, GLclampf, GLclampf, GLclampf) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fClearDepth(GLclampf) [gl:0x443dc000] < void mozilla::gl::GLContext::fClearDepth(GLclampf) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fClearStencil(GLint) [gl:0x443dc000] < void mozilla::gl::GLContext::fClearStencil(GLint) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fClear(GLbitfield) [gl:0x443dc000] < void mozilla::gl::GLContext::fClear(GLbitfield) [0x0000] 0x443dc000 MakeCurrent force=0 WEBGL MakeCurrent [gl:0x443dc000] > const GLubyte* mozilla::gl::GLContext::fGetString(GLenum) [gl:0x443dc000] < const GLubyte* mozilla::gl::GLContext::fGetString(GLenum) [0x0000] 0x443dc000 MakeCurrent force=0 WEBGL MakeCurrent [gl:0x443dc000] > const GLubyte* mozilla::gl::GLContext::fGetString(GLenum) [gl:0x443dc000] < const GLubyte* mozilla::gl::GLContext::fGetString(GLenum) [0x0000] 0x443dc000 MakeCurrent force=0 WEBGL MakeCurrent [gl:0x443dc000] > const GLubyte* mozilla::gl::GLContext::fGetString(GLenum) [gl:0x443dc000] < const GLubyte* mozilla::gl::GLContext::fGetString(GLenum) [0x0000] 0x443dc000 MakeCurrent force=0 --- WebGL context destroyed: 0x443dc000 0x443dc000 MakeCurrent force=0 [gl:0x443dc000] > void mozilla::gl::GLContext::fDeleteFramebuffers(GLsizei, GLuint*) [gl:0x443dc000] < void mozilla::gl::GLContext::fDeleteFramebuffers(GLsizei, GLuint*) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fDeleteTextures(GLsizei, GLuint*) [gl:0x443dc000] < void mozilla::gl::GLContext::fDeleteTextures(GLsizei, GLuint*) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fDeleteRenderbuffers(GLsizei, GLuint*) [gl:0x443dc000] < void mozilla::gl::GLContext::fDeleteRenderbuffers(GLsizei, GLuint*) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fDeleteRenderbuffers(GLsizei, GLuint*) [gl:0x443dc000] < void mozilla::gl::GLContext::fDeleteRenderbuffers(GLsizei, GLuint*) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fDeleteProgram(GLuint) [gl:0x443dc000] < void mozilla::gl::GLContext::fDeleteProgram(GLuint) [0x0000] [gl:0x443dc000] > void mozilla::gl::GLContext::fDeleteFramebuffers(GLsizei, GLuint*) [gl:0x443dc000] < void mozilla::gl::GLContext::fDeleteFramebuffers(GLsizei, GLuint*) [0x0000] Destroying context 0x443fb460 surface 0x435d3c00 on display 0x2 == GLContext 0x443db000 == Outstanding Textures: Outstanding Buffers: Outstanding Programs: Outstanding Shaders: Outstanding Framebuffers: Outstanding Renderbuffers: 0x43928400 MakeCurrent force=1 [gl:0x43928400] > void mozilla::gl::GLContext::fBindFramebuffer(GLenum, GLuint) [gl:0x43928400] < void mozilla::gl::GLContext::fBindFramebuffer(GLenum, GLuint) [0x0000] [gl:0x43928400] > void mozilla::gl::GLContext::raw_fViewport(GLint, GLint, GLsizei, GLsizei) [gl:0x43928400] < void mozilla::gl::GLContext::raw_fViewport(GLint, GLint, GLsizei, GLsizei) [0x0000] [gl:0x43928400] > void mozilla::gl::GLContext::fUseProgram(GLuint) [gl:0x43928400] < void mozilla::gl::GLContext::fUseProgram(GLuint) [0x0501] GL ERROR: void mozilla::gl::GLContext::fUseProgram(GLuint) generated GL error GL_INVALID_VALUE(0x0501) [gl:0x43928400] > void mozilla::gl::GLContext::fUseProgram(GLuint) [gl:0x43928400] < void mozilla::gl::GLContext::fUseProgram(GLuint) [0x0501] GL ERROR: void mozilla::gl::GLContext::fUseProgram(GLuint) generated GL error GL_INVALID_VALUE(0x0501) [gl:0x43928400] > void mozilla::gl::GLContext::fUseProgram(GLuint) [gl:0x43928400] < void mozilla::gl::GLContext::fUseProgram(GLuint) [0x0501] GL ERROR: void mozilla::gl::GLContext::fUseProgram(GLuint) generated GL error GL_INVALID_VALUE(0x0501) [gl:0x43928400] > void mozilla::gl::GLContext::fUseProgram(GLuint) [gl:0x43928400] < void mozilla::gl::GLContext::fUseProgram(GLuint) [0x0501] GL ERROR: void mozilla::gl::GLContext::fUseProgram(GLuint) generated GL error GL_INVALID_VALUE(0x0501) [gl:0x43928400] > void mozilla::gl::GLContext::fUseProgram(GLuint) [gl:0x43928400] < void mozilla::gl::GLContext::fUseProgram(GLuint) [0x0501] GL ERROR: void mozilla::gl::GLContext::fUseProgram(GLuint) generated GL error GL_INVALID_VALUE(0x0501) [gl:0x43928400] > void mozilla::gl::GLContext::fUseProgram(GLuint) [gl:0x43928400] < void mozilla::gl::GLContext::fUseProgram(GLuint) [0x0501] GL ERROR: void mozilla::gl::GLContext::fUseProgram(GLuint) generated GL error GL_INVALID_VALUE(0x0501) [gl:0x43928400] > void mozilla::gl::GLContext::fUseProgram(GLuint) [gl:0x43928400] < void mozilla::gl::GLContext::fUseProgram(GLuint) [0x0501] GL ERROR: void mozilla::gl::GLContext::fUseProgram(GLuint) generated GL error GL_INVALID_VALUE(0x0501) so the context appears to still be current, yet we get lots of errors
Assignee | ||
Comment 2•13 years ago
|
||
The problem also occurs if the webgl context is never made current explicitly
Comment 3•13 years ago
|
||
First of all, is this with mozilla-central from after June 17? You really want the fix from bug 659842 here. Since you get GL errors, the next step is to run with MOZ_GL_DEBUG_ABORT_ON_ERROR=1 in a debugger to get a stack for the first error.
Assignee | ||
Comment 4•13 years ago
|
||
I disabled makecurrent for the webgl context in this test, but I assume a newly created context is current automatically, hence the same outcome
Comment 5•13 years ago
|
||
(In reply to comment #4) > I disabled makecurrent for the webgl context in this test, but I assume a > newly created context is current automatically, hence the same outcome Newly created contexts aren't automatically current. The first MakeCurrent call after creating a new context is actually very long, it's where all the initialization happens. However, WebGL code is full of MakeCurrent calls, so you could still have one there even if you removed one elsewhere.
Comment 6•13 years ago
|
||
(In reply to comment #4) > Created attachment 542484 [details] > log and backtrace to first gl error LayerManagerOGL::SetLayerProgramProjectionMatrix is calling Activate which is calling glUseProgram which fails. Stuff to investigate: Did some shader here fail to compiler? Did glLinkProgram fail? What does glGetShaderInfoLog say?
Assignee | ||
Comment 7•13 years ago
|
||
(In reply to comment #5) > (In reply to comment #4) > > I disabled makecurrent for the webgl context in this test, but I assume a > > newly created context is current automatically, hence the same outcome > > Newly created contexts aren't automatically current. The first MakeCurrent > call after creating a new context is actually very long, it's where all the > initialization happens. However, WebGL code is full of MakeCurrent calls, so > you could still have one there even if you removed one elsewhere. I disabled the WebGL MakeCurrent call itself (In reply to comment #6) > (In reply to comment #4) > > Created attachment 542484 [details] > > log and backtrace to first gl error > > LayerManagerOGL::SetLayerProgramProjectionMatrix is calling Activate which > is calling glUseProgram which fails. Stuff to investigate: Did some shader > here fail to compiler? Did glLinkProgram fail? What does glGetShaderInfoLog > say? if the shader failed, GL would have aborted at that point, not when using the shader, anyways I double-checked and all shaders compile OK.
Assignee | ||
Comment 8•13 years ago
|
||
I also checked, and the program it tries to use is indeed Generated and Linked in the same context. maybe the GL context persists after its deletion for some reason?
Comment 9•13 years ago
|
||
Please have a close look at https://bugzilla.mozilla.org/show_bug.cgi?id=659842#c79 glXDestroyContext does not take effect as long as the context is current. So in that bug we discovered that we had to release the context with a glXMakeCurrent(display, None, NULL) before calling glXDestroyContext, or else the context destruction would happen at an arbitrary later time. Check if you're having the same problem here, and check that the mozilla-central you're using is more recent than June 17 as said in comment 3.
Assignee | ||
Comment 10•13 years ago
|
||
No luck so far. I can't get any egl tracing from either ltrace or pvrtrace - what exactly are we doing that obfuscates library calls this good? I tried various configurations of makecurrent and xsync before or after destroying and a sample egl program can actually create and destroy contexts. Not sure how to proceed here.
Assignee | ||
Comment 11•13 years ago
|
||
one more thing - if I push fennec into the background and fetch it back the context starts working again.
Assignee | ||
Comment 12•13 years ago
|
||
I found the following: if we don't try to use the platform provided context, everything works as expected. ( http://mxr.mozilla.org/mozilla-central/source/gfx/thebes/GLContextProviderEGL.cpp#1731 ), but if we use the context we assume is provided by Qt, we get BAD_CONTEXT every time we try to actually make it current or query it.
Assignee | ||
Comment 13•13 years ago
|
||
In this patch I remove the Qt special case for creating egl contexts since it appears we can't use the context provided by Qt. We can't query it or makecurrent it, we can only use it (accidentally?) when it is made current by a third party (compositor? framework?) I also tried QGLContext::MakeCurrent, this also didn't work.
Attachment #559952 -
Flags: review?(romaxa)
Comment 14•13 years ago
|
||
Comment on attachment 559952 [details] [diff] [review] remove special Qt EGL context code with this patch we are going to have doubling of eglSwapBuffers calls. one is coming from QGLWidget, another is from moz eglContext... that is bad and cause flickering.. If we create our own widget context, then we should drop existing one by setting qgraphicsview->setViewport(new QWidget()); in all cases. otherwise we need to create some trick in order to sync swapBuffer calls Also it make sense to remove other platformContext related code from egl provider...
Attachment #559952 -
Flags: review?(romaxa) → review-
Comment 15•13 years ago
|
||
Also if we do that, then we will not be able to integrate filepicker dialog as it is.... rendering is broken in that case
Assignee | ||
Comment 16•13 years ago
|
||
I found a way to fix this problem that does not require removing QGLContext. When we start with the QGLWidget, the context is created on display 0x1. We, however, query for the default display and get 0x2 and use this for all contexts. Also, the QGLWidget context has a surface attached, and we try to makecurrent it without any surface. If we query the current display, instead of the default display, and if we remember the surface the qglcontext has and use it later to make it current again, all works as expected.
Assignee | ||
Comment 17•13 years ago
|
||
here's a quick hack how I made it work.
Comment 18•13 years ago
|
||
> here's a quick hack how I made it work.
yep, it works, could you make display creating part Qt only, and add comment that for Qt we use current display and current surface
Comment 19•13 years ago
|
||
also instead of mEGLDisplay = fGetCurrentDisplay();, you can define EG_DEFAULT_DISPLAY as QX11Info::display
Comment 20•13 years ago
|
||
also you need to fix swapBuffers, in order to not call it for Qt (otherwise double swapBuffers call)
Comment 21•13 years ago
|
||
Comment 22•13 years ago
|
||
Comment on attachment 560171 [details] [diff] [review] Fixed default display and surface for Qt GL context This all looks good to me. Note, I can't test Maemo/Qt, but the changes look sound and they won't affect other platforms.
Attachment #560171 -
Flags: review+
Updated•13 years ago
|
Keywords: checkin-needed
Updated•13 years ago
|
Comment 23•13 years ago
|
||
https://hg.mozilla.org/mozilla-central/rev/44977dedb485
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → FIXED
Whiteboard: [inbound]
Target Milestone: --- → mozilla9
You need to log in
before you can comment on or make changes to this bug.
Description
•