Bug 45851 - Move implicit makeContextCurrent calls from GraphicsContext3D into WebGLRenderingContext
Summary: Move implicit makeContextCurrent calls from GraphicsContext3D into WebGLRende...
Status: RESOLVED WONTFIX
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebGL (show other bugs)
Version: 528+ (Nightly build)
Hardware: All All
: P2 Normal
Assignee: Kenneth Russell
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2010-09-15 16:46 PDT by Kenneth Russell
Modified: 2011-08-23 17:26 PDT (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Kenneth Russell 2010-09-15 16:46:41 PDT
Currently, the implementation of every entry point on GraphicsContext3D calls makeContextCurrent. The underlying reason for this is WebGL's semantics, which need the OpenGL context associated with the WebGLRenderingContext to be made current upon every call from JavaScript.

These makeContextCurrent calls should be made in the entry points of WebGLRenderingContext rather than GraphicsContext3D for two reasons. First, doing so will reduce the number of errors and amount of code in ports. Second, doing so will make the semantics of GraphicsContext3D more like OpenGL's.
Comment 1 Chris Marrin 2010-09-16 06:14:57 PDT
I agree with all this. The reason for putting in all the makeContextCurrent calls was because of the WebGL model of implicit context switching. But for debugging purposes, I suggest you replace makeContextCurrent in GraphicsContext3D with a checkContextConsistency call. In release builds this would be a nop, but in debug builds it would ASSERT if the current context was wrong. This will catch bugs without affect release performance.
Comment 2 Chris Marrin 2010-09-16 06:18:55 PDT
(In reply to comment #1)
> I agree with all this. The reason for putting in all the makeContextCurrent calls was because of the WebGL model of implicit context switching. But for debugging purposes, I suggest you replace makeContextCurrent in GraphicsContext3D with a checkContextConsistency call. In release builds this would be a nop, but in debug builds it would ASSERT if the current context was wrong. This will catch bugs without affect release performance.

Just to be clear, I'm not suggesting replacing the makeContextCurrent call, but replacing the call to makeContextCurrent in all the GraphicsContext3D callees with a call to a new checkContextConsistency function. This can be static inline so it compiles completely out in release builds.
Comment 3 Kenneth Russell 2011-08-23 17:26:11 PDT
Coming back around to this old bug. Some colleagues and I had a long discussion about usage of GraphicsContext3D. It seems that it's a better design to make it easier to use from elsewhere in the WebKit code, rather than worrying about the simplicity of porting GraphicsContext3D. This implies that the makeContextCurrent call should continue to be implicit in all of the GraphicsContext3D entry points. Out of necessity, this call is already cheap enough in each port that it isn't a bottleneck. It would be nice to remove it entirely from the API, but there are places in some ports where it's necessary to make a GraphicsContext3D current and then call into third-party code which makes OpenGL calls directly. We'd need to think about how this could be handled more gracefully if we wanted to remove the makeContextCurrent method. Regardless, it seems that it's better to leave the API as it stands, so I'm closing this as "won't fix". Please reopen the bug if you disagree with this decision.