[Webkit-unassigned] [Bug 129419] New: [GTK] Wrong GL context when destroying textures

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=129419

           Summary: [GTK] Wrong GL context when destroying textures
           Product: WebKit
           Version: 528+ (Nightly build)
          Platform: Unspecified
        OS/Version: Unspecified
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: WebKit Gtk
        AssignedTo: webkit-unassigned at lists.webkit.org
        ReportedBy: itoral at igalia.com
                CC: mrobinson at webkit.org


Destroying a WebPage can trigger destruction of GL textures (via GraphicsContext3D) and we should make sure that the right GL context is bound when this happens. When closing a tab in Epiphany, it can happen that the wrong context is bound when textures are destroyed this way.

In theory, GraphicsContext3D should prevent this since it calls makeContextCurrent before executing GL commands, however, this only works when GraphicsContext3DPrivate is created with renderStyle GraphicsContext3D::RenderOffscreen. When renderStyle is GraphicsContext3D::RenderToCurrentGLContext GraphicsContext3D will be created with the currently bound GL context but won't hold a reference to it so its makeContextCurrent calls translate to no-op leaving it up to the client code to ensure that the right GL context is bound every time that the GraphicsContext3D instance is used.

This does not currently happen and thus destroying textures as part of the WebPage tear down process can produce removal of GL textures from the wrong GL context. This does not have a visible impact since all our GL contexts have a sharing context that makes sure that they all share the namespace and hence the objects, but it is a problem when we don't have a valid sharing context (which is a temporary situation for me while I am working on Wayland support). Even if having a common sharing context for all our GL contexts prevents this from actually being harmful, it is a bug that can affect new developments like the one I am doing right now and when it happens it can be hard to track down, so I think it is worth fixing.

I think the best solution for this is to have GraphicsContext3D hold a reference to the active context in use when it is created also with renderStyle GraphicsContext3D::RenderToCurrentGLContext. Actually, the Nix port was doing this before, I guess because they ran into this problem at some point. I'll attach a patch to do this shortly.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.