flypig.co.uk

Today I've spent a fair bit of time exploring a new part of the rendering process. Having spent a lot of time on the nuts and bolts of textures, images and surfaces over the last few days, it's made a nice change to be looking at fresh parts of the code.

My plan has been to try to check that the texture that's used as a canvas is being rendered on to the screen properly. Historically the way I've done this when it comes to the browser (as opposed to the WebView) has been to clear the texture to a particular colour. The buffer-clearing calls sit in the sailfish-browser code and specifically the declarativewebcontainer.cpp source file where there's a method specifically for the purpose:

void DeclarativeWebContainer::clearWindowSurface()
{
    Q_ASSERT(m_context);
    // The GL context should always be used from the same thread in which it 
    was created.
    Q_ASSERT(m_context->thread() == QThread::currentThread());
    m_context->makeCurrent(this);
    QOpenGLFunctions_ES2* funcs = 
    m_context->versionFunctions<QOpenGLFunctions_ES2>();
    Q_ASSERT(funcs);

    funcs->glClearColor(1.0, 1.0, 1.0, 0.0);
    funcs->glClear(GL_COLOR_BUFFER_BIT);
    m_context->swapBuffers(this);
}

This method clears the texture to a white colour before performing rendering of the web page on top of it. By changing the value passed to glClearColor() it's possible to get immediate feedback about the fact that the texture is being rendered. For example, suppose the code is changed to the following:

    funcs->glClearColor(0.0, ).0, 1.0, 0.0);
    funcs->glClear(GL_COLOR_BUFFER_BIT);

In this case the screen will change to a dark blue on initial render, only later being painted over by the web page itself.

But this isn't part of the WebView code. In the case of the WebView the location of the code that performs this task is less clear to me. In fact it may be there is no direct equivalent, but it still feels like I should be able to place this glClear() code somewhere in order to get a similar result, even if there isn't anything yet in the codebase that's doing this.

The challenge therefore is to find the right place for this. Checking through the code I eventually come upon the CompositorOGL::BeginFrame() method. This includes code like this:

  mGLContext->fClearColor(mClearColor.r, mClearColor.g, mClearColor.b,
                          mClearColor.a);
  mGLContext->fClear(clearBits);

This looks pretty similar to the sailfish-browser code, apart from the fact that the colour looks configurable. Moreover, checking with the debugger shows that this method, and the fClear() call within it, are definitely being called.

I've added some changes to the ESR 91 codebase to set the colour to dark blue again, in the hope this will have an impact on the output. When I step through the code, I can see that the colour value is getting set to blue. But I can't see this having any consequence on what's rendered to the screen.

(gdb) b CompositorOGL::BeginFrame
Breakpoint 1 at 0x7ff11a6970: file ${PROJECT}/gecko-dev/gfx/layers/opengl/
    CompositorOGL.cpp, line 9
83.
(gdb) c
Continuing.
[...]
Thread 37 "Compositor" hit Breakpoint 1, mozilla::layers::
    CompositorOGL::BeginFrame (this=0x7ed8002f10, aInvalidRegion=..., 
    aClipRect=..., 
    aRenderBounds=..., aOpaqueRegion=...)
    at ${PROJECT}/gecko-dev/gfx/layers/opengl/CompositorOGL.cpp:983
983     in ${PROJECT}/gecko-dev/gfx/layers/opengl/CompositorOGL.cpp
(gdb) c
Continuing.
[...]
1050    in ${PROJECT}/gecko-dev/gfx/layers/opengl/CompositorOGL.cpp
(gdb) p mClearColor
(gdb) p mClearColor
$1 = {r = 0, g = 0, b = 0, a = 0}
(gdb) n
2436    ${PROJECT}/obj-build-mer-qt-xr/dist/include/nsRegion.h: No such file or 
    directory.
(gdb) n
[...]
1086    in ${PROJECT}/gecko-dev/gfx/layers/opengl/CompositorOGL.cpp
(gdb) n
1087    in ${PROJECT}/gecko-dev/gfx/layers/opengl/CompositorOGL.cpp
(gdb) p mClearColor
$2 = {r = 0, g = 0, b = 1, a = 0}
(gdb) p /x clearBits
$5 = 0x4100
(gdb) n

There could be one of two reasons for this: the first it could be that this code simply has no effect no rendering anyway. The second is that this is having no effect in ESR 91 specifically because the rendering pipeline is broken in some other way.

To try to distinguish between the two I've attempted to run the WebView on ESR 78 and, although I don't want to have to go to the trouble of recompiling, I can poke in values for the colour to see whether they have any effect.

Here's the debug output from me changing the colour value on ESR 78 mid-execution using the debugger.

[Switching to Thread 0x7fa516f9a0 (LWP 32148)]

Thread 36 "Compositor" hit Breakpoint 1, mozilla::layers::
    CompositorOGL::BeginFrame (this=0x7eac003420, aInvalidRegion=..., 
    aClipRect=..., 
    aRenderBounds=..., aOpaqueRegion=...) at gfx/layers/opengl/
    CompositorOGL.cpp:967
967                                              const nsIntRegion& 
    aOpaqueRegion) {
(gdb) p mClearColor
$1 = {r = 0, g = 0, b = 0, a = 0}
(gdb) n
(gdb) n
968       AUTO_PROFILER_LABEL("CompositorOGL::BeginFrame", GRAPHICS);
[...]
313     obj-build-mer-qt-xr/dist/include/mozilla/RefPtr.h: No such file or 
    directory.
(gdb) n
1045      mGLContext->fClearColor(mClearColor.r, mClearColor.g, mClearColor.b,
(gdb) p mClearColor
$2 = {r = 0, g = 0, b = 0, a = 0}
(gdb) mClearColor.b = 1.0
Undefined command: "mClearColor".  Try "help".
(gdb) set mClearColor.b = 1.0
(gdb) p mClearColor
$3 = {r = 0, g = 0, b = 1, a = 0}
(gdb) 

I'm surprised to discover that this also has no effect on ESR 78. I'm left wondering whether there might be some other part of the code that's clearing the background instead. I'm going to need to investigate this further. However, one other issue I'm experiencing is that the ESR 91 build has lost its debug source annotations. This is as a result of me having performed partial builds almost exclusively for the last week or so. Partial builds can result in the debug source and library packages getting out of sync, the only solution to which is to perform a full rebuild. So I've set a full rebuild off in the hope that it will help provide more clarity tomorrow.

But that also means that there's no scope to do more partial building of the code today. Once the full rebuild has completed I'll return to this topic to see whether I can get any more concrete results.

In the meantime, if you'd like to read any of my other gecko diary entries, they're all available on my Gecko-dev Diary page.