I was interested in checking out JebGL because of its potential use in the code visualization system that I work on in CodeSonar. The Visualization feature for CodeSonar utilizes the OpenGL API in order to quickly draw large numbers of elements on the screen. Being a web application, it does this using a Java applet paired with the JOGL (Java OpenGL) library. Unfortunately, the Java 7 series of releases has suffered from a number of security vulnerabilities. Keeping up with these new java releases is a chore for users, and most browsers smartly block old versions, preventing perfectly safe java applets from being used.
Meet WebGL
WebGL is another way to use OpenGL from within browsers. Client code is written in javascript, and it doesn’t require the use of a third-party plugin. The only problem is that until relatively recently, not all major browsers offered a WebGL implementation. Most notably, Internet Explorer didn’t support it until the most recent release of IE 11. Of course, there’s still the issue of how to support users who aren’t running the latest and greatest version of IE.
Meet JebGL
JebGL claims to offer WebGL compatibility for browsers that don’t support it. It works by using a Java applet that uses JOGL, where the HTML canvas element that normally renders WebGL content is replaced by the JebGL applet. The WebGL context is switched for a JebGLContext, which forwards javascript calls to the Java applet, and forwards these calls to JOGL.
Building JebGL from Source
The source for JebGL can be found here. The JebGL implementation consists of two files, a javascript file and a single Java class. The build instructions that come with the source didn’t seem to work for me, but I didn’t spend much time trying to debug the issue, since I needed to incorporate it into our company build system anyway, so the applet could be signed with our certificate. I also wanted to change the way the applet was deployed to use JOGL native .jar post-loading rather than deploying it via a .jnlp file.
After building and making some minor tweaks to the applet’s deployment method, I fired up the included test page and was greeted with a mesmerizing display of colored circles. As advertised, JebGL was executing WebGL code in my IE browser… very neat stuff!
Hiccups…
Unfortunately, I noticed shortly after starting the test page that it sometimes appeared to crash – that is, the animated display would freeze and stop working. The error log in my javascript console showed that a “Not Implemented” exception was being thrown on mousewheel events. Apparently, moving the mousewheel while hovering over the applet would cause it to stop dead in its tracks.
So I tried changing the JebGL code to follow the same pattern as the other event handlers. It seemed to work, in that using the mousewheel over the applet was no longer a fatal error, although I didn’t do any other tests to make sure the event was truly working properly. There could have been good reason for leaving it as unimplemented – it wasn’t obvious without more testing.
The WebGL Conformance Test Suite for JebGL
Now, while changing the code to enable mousewheel events, I noticed a number of other places in the code where “Not Implemented” exceptions were being thrown. This led me to think about how I could test JebGL to get an idea of what parts of the WebGL spec weren’t implemented, or were otherwise not functional. There is a page on the JebGL wiki that briefly talks about testing, but it only says that a test suite is in the works, and in the meantime it can be tested manually with the tutorials.
Khronos, on the other hand, maintains an automated test suite for WebGL. These tests can be run live in a browser or they can be downloaded and run locally. I was curious to see if the tests could be modified to run JebGL in place of a WebGL enabled canvas, but sadly discovered that the test suite is organized in a way that makes it very difficult to do so. The test suite is organized as a master page (the test harness), and many individual tests that live as single html files. The main page loads these individual tests in an iframe. Each test consists mainly of javascript code that’s run as the test page is being rendered.
An example of an individual test sequence would be:
- Do some inital setup.
- Get a WebGL context from a canvas element on the test’s html page.
- Assert that a particular method call produces an expected result.
When the JebGL applet is loaded, it takes some time to initialize. This means that if a JebGL applet were to be used in place of an existing canvas element, it would take some time to load after step 2 above. Since the test’s javascript is run in a single thread from start to finish, there’s no way to have it wait for the applet to become initialized in step 2 before calling the test assertions in step 3. Using a busy loop to check the status of the applet doesn’t work because the browser never has a chance switch to another thread to load the applet’s scripting interface. Using setTimeout to trigger a callback after the applet is ready won’t work either, because by then the test will have continued execution onto step 3, and the assertions will have failed.
There is a workaround for the above issue, although it’s far from perfect. Instead of creating a new JebGL applet in place of each test’s canvas element, a single applet can be created on the master page, and this applet is used to return the same context for use by each individual test. This isn’t as nice as having a new instance for each test, because it means the results of a test can be affected by previous tests, but it does allow for some coverage. It’s also possible to run tests one at a time, rather than batched as one large run, which gives some useful results.
And… Results.
It probably wouldn’t be fair to post a numerical summary of passed/failed tests, since many of the tests failed due to issues caused by the testing system described above. (For example, one of the tests (draw-arrays-out-of-bounds.html) caused the JebGL applet to crash, which then caused almost all subsequent tests to fail.)
Of the tests that were working, however, I saw several failures due to “Not Implemented” exceptions, as well as some crashes that prevented further communication with the JebGL applet, and some other miscellaneous failures that looked legitimate. I didn’t spend much time evaluating each test that passed or failed – instead I wanted to gather a general impression of how well it did overall compared to a certified WebGL implementation.
Final Thoughts
Although running the test suite using JebGL was by no means comprehensive, it was clear that some test failures were legitimate, so it seems fair to conclude that JebGL isn’t a fully compliant WebGL implementation. That being said, it is impressive in the areas where it does work, and could hold promise for developers wanting a migration path to using WebGL while needing to support older browsers.
It would certainly be nice to have a comprehensive test suite for JebGL, but for now, developers will most likely have to discover incompatibilities through a process of trial and error. Still, the work done so far on this library is impressive, and although incomplete, it provides great potential for bringing WebGL compatibility to old browsers.
