Two big retrospective changes to the lessons

I’ve just made two large sets of changes to the lessons. If you started looking at the lessons after the date of this post, you’ve already seen the new and improved versions, so you can ignore the rest of this :-) Otherwise, read on…

The two changes are:

  1. I’ve changed all references to CanvasXXXArray to the equivalent WebGLXXXArray. As I noted, Oliver Hunt said on Twitter that he’d changed WebKit to use this new naming convention, and as murphy noted in the comments to the last lesson, this broke things here. Mark Steele has confirmed that this change will find its way into Firefox sometime soon, so it was obviously time to change. There is now a wart of compatibility code at the start of all of the lessons so that they will work in both Firefox and WebKit, but the code itself just uses WebGL- prefixed classes. I must admit that I’m in two minds about the change to the class naming; it’s true that the Canvas- prefix was odd, given that the classes weren’t really canvas-related, but as Vladimir Vukićević pointed out the other day, the classes could be useful for JavaScript code that has nothing to do with WebGL. Perhaps something more generic would have been better? Still, if the spec says we should use WebGL- prefixes, then that’s what we should be using for these lessons. [UPDATE] I’ve added the WebKit/Minefield compatibility code to the WebGL Cookbook.
  2. I’ve changed the code so that instead of creating new buffers for vertex positions, colours, texture coordinates and normals every time we redraw the scene, we create them all once in a new function called initBuffers — which is called during the initialisation phase — put them into global variables, and then use them when redrawing. I’d originally put in the code that created them every time because I didn’t really understand how buffers worked, but had kept it that way even after I had a better idea of what was going on because it seemed easier to explain, and didn’t seem to have any major disadvantages for small demos like mine — beyond a small loss in efficiency. However, reports of memory leaks, and of what sounded like it might be a related crash for my second Mandelbrot demo, changed my mind. And, on reflection, recreating the buffers on every redraw sounds like it might be a bad habit to get people into, so perhaps it was never a good idea… anyway, it’s all fixed now. If it’s not obvious to you how the new code works, I really recommend you scan quickly through lesson 1 once more and look at how it has changed. It should be pretty clear (and if it’s not, then do tell me in the comments).

Anyway, I’ve checked all of the changed lessons and demos under Minefield, and everything looks OK. I won’t have a chance to check them out on WebKit for a few days, so if any Mac users reading this fancy having a quick look and letting me know whether or not they work, I’d be eternally grateful! Here are links directly to the WebGL pages:

You can leave a response, or trackback from your own site.

6 Responses to “Two big retrospective changes to the lessons”

  1. subblue says:

    Thanks for the update. I’ve checked the examples in Webkit in Snow Leopard and they are all working fine.

  2. giles says:

    That’s great news, thanks for checking them out!

  3. loku says:

    Both examples crashing my minefield.

  4. giles says:

    Oh dear, that’s less good :-(

    What kind of system/graphics card do you have? Are you using software rendering? And I assume the lessons work, at least?

    The examples run so slowly on my old laptop that it can look like it’s crashed; it has a crappy Intel graphics driver with no OpenGL 2.0 support, so it switches over to software rendering, giving about one frame every 20 seconds.

  5. loku says:

    No, it’s closing when I navigate to page with example and crash raporter appears. I’ve got XP on athlon xp 2,2 cpu with my old radeon 9600 ;) but other demos working fine

  6. giles says:

    Weird! I’m not sure of the best way to work out what’s going on. Do you know if you’re using software rendering? I think that Minefield can use it, even if you have it switched off, if your OpenGL version is too low for it (I think it needs at least version 3).

    If the spinning cube in lesson 5 is spinning smoothly, I think you can safely assume it’s not using software rendering; if it jumps around doing about 2fps then it probably is software rendering.

Leave a Reply

Subscribe to RSS Feed Follow Learning WebGL on Twitter