Showing posts with label webgl. Show all posts
Showing posts with label webgl. Show all posts

Thursday, August 28, 2025

Khronos Notes 8/28/2025

 

I am unclear about what is going on with Khronos especially as it affects OpenXR and WebGL and the various browsers.  

1. Khronos appears to have 23 active standards including OpenXR and WebGL

2. Each of these standards has a working group.  Most groups are 4 people or less.  All of the members of the group are affiliated with a company that is a member.  However these groups are tiny and probably do not represent the "real" working or advisory groups, which are not listed on their web site.  There are no individuals listed.

3. There are 4 levels of membership for companies and 1 for academia.  Costs per year vary from $90,000, $22,000, $9,000 to $4,000 plus.  Academic membership is $1,000 per year.  There is no way for an individual to join.  NYU is not a member nor is UC, CMU, MIT or Stanford.

4. As all members of the working groups are by definition employed by a member company, I do not know what it means for them to be a "volunteer".  

5. I know that the working group for OpenGL was much larger than anything mentioned here, on the order of maybe 30-50 members so obviously there is something I do not understand here.

6. Meta is a contributing member, but I am told is not a supporter of OpenXR.

7. It is not clear whether WebGL is a volunteer or a supported activity at each of the various browser companies.  Given the potential for performance and stability issues it seems difficult to believe that it would be a pure open source, volunteer activity but maybe it is.  WebGL is essentially a repurposing of OpenGL ES 2.0 and 3.0 so maybe there are robust implementations that can be trivially incorporated.

8. It is not possible for an individual to be a member of Khronos.  It is possible that they can be invited onto a working group (or other advisory group).

To be updated.



Tuesday, February 10, 2015

Enabling Google Chrome FPS (Frames Per Second) Display



There is a hidden feature in Google Chrome that displays the FPS and GPU memory utilization of the browser.

To turn it on, go to the page “about:flags” but without the quotes.

Find the flag “FPS Counter” and enable it.  In the following image it has already been enabled.




Restart chrome with the button at the bottom of the page, which seems to be faster than just closing the browser and restarting it.

This is what the FPS display looks like.




The FPS counter is in the upper right.  Here is a closeup.





Now, does it make any sense?  In other words, are the numbers accurate.  Its hard to tell, but they are not obviously wrong.  I plan to use this feature for all my WebGL development.

Friday, February 14, 2014

WebGL on Second Thought and a Brief Note on OpenGL ES 3.0


This is a brief note to say that after all the sturm und drang expressed on this blog while learning WebGL 1.0, that it has become my favorite way to write little graphics programs.

I now realize that it is very unusual to be able to do anything dynamic in HTML/Browsers without always having to deal with the server for information. And yet I am able to write very complicated WebGL (or at least reasonably complicated) WebGL programs without using the server at all (except for saving images).

The "framework" mess in writing "dynamic web pages" for browsers is astounding, but I would not necessarily count on finding a framework that worked well with WebGL. Such a thing may in fact exist, but it is far outside the normal range of what the frameworks are intended (and tested) for.

Even Javascript has grown on me such that it has become a pleasant language to write in.

I think this is moderately funny given the amount of noise I made learning these two things (javascript development and WebGL).

On a related matter, I spent a half day or so reading the specification of OpenGL ES 3.0 and it is far different from WebGL 1.0, no matter what you hear. Although the shading language part is nearly identical, the OpenGL part is richer in capability. OpenGL 4.x, however, upon reading is vastly more complicated and a completely different beast.

So the takeaway information of this post is: WebGL is very useful if a little annoying to learn, and WebGL is remarkably different from OpenGL ES 3.0. The power of WebGL comes from its shader language, its integration into the browser and HTML, and the interactive nature of Javascript and Javascript development.

I apologize for lapsing into optimism and a positive attitude in this post.   I will no doubt resume my normal negative approach in future posts.

Friday, January 24, 2014

Semi-Automatic Ernst Haeckel & Procedural Modelling


The following demo is online but only while my server is up and until AT&T changes my IP number. Go to http://108.232.26.40/mscript53/mscript.html.  

Type "H" for help information.

Boy is it slow!   I think that is the fault of the speed of the upload of my internet connection.  Not all that interactive on this server, I am afraid.  But if you are patient, it should refresh.  And a "reload" gets a whole new set of objects.


Generations of computer animators have been inspired by Ernst Haeckel (1834-1919), famed and sometimes controversial German scientist and artist, whose Ontogony Recapitulates Phylogony is one of the more famously incorrect, yet memorable, scientific principles of the natural sciences.

But for us digital dependent imagers, it is his meticulous drawings of the natural world that hold endless appeal. Obsessive, stylized, and completely delightful, there isn't a one of us who would not be thrilled to own a print of one of his works on his or her wall.

Whether Radiolarian or Anemone, his Kunstformen are an endless inspiration.






I wrote a modest program to generate small, probably water based organisms inspired by the master. Although the results are no where near where they would need to be be worthy of the art that inspired them.   I need to emphasize that I am trying to duplicate Haeckel, although it almost sounds that way, nor am I trying to recreate the fabulous range of creatures.  I am trying to procedurally define a class of objects that somewhat resemble what you might see in a microscope looking at a drop of pond water ... one of the classes of those creatures, not all of them by any means.

The idea is that you are looking at a semi-automatic catalog of obscure life forms, each of them different, yet related by an unknown (to the viewer) process or processes.

There is also some shader stuff going on to try and achieve a certain technical look.  There is much more to do there.

Each time the program's browser page is refreshed it comes up with a new set of objects. It was written in Webgl.  Of course that wont work on the following images, it only works when running it live.  If you are lucky my server will be up and the IP number at the top will be working.  (One day I will have my own server or a server I can use with a real, known IP number.)

The creatures and their look is defined by about 32 (or so) parameters.  8 of these parameters define the physical object geometry, 8 define an overall look, and the rest are miscellaneous parameters to define things like scale and overall reflectivity.  










Ernst Haeckel on Wilipedia

Die Radiolarien

Saturday, January 18, 2014

You Could Upload an Image from WEBGL or You Could Just Go Shoot Yourself


Lets say that you embrace the WebGL world and write some nifty graphics application in it.   Now lets suppose you want to save an image or two from your interactive application and doing a screengrab is not appropriate. Perhaps this is because you wish to save many images, such as an animation.   Maybe you are debugging a complicated problem and wish to save snapshots in various parts of a process.

Maybe you are iterating through a space and need to make a record of each step.  I do this all the time in animation production to do what is called a "wedge", which is a way of making choices among many parameters.  

But this is WEBGL and the bold new Internet paradigm, so things are not so easy.

In fact, its a really annoying process to save an image under program control and the reason for this has less to do with WebGL than it does to do with Internet architecture and the awful state of documentation in our bold new Internet based reality.

I present here one solution to the "save an image" problem.  Here are choices that had to be made to get to this solution:

1. In order to save an image, you must upload it to a server.
2. In order to upload anything you must use "Ajax", which really means XMHHttpRequest.
3. The server side is written in node.js
4. We are going to use POST.
5. We are going to use base64.
6. We are not going to use FORMS or BLOBS.
7. Our server is going to do nothing but receive an image and save it out.
8. You may save as many images as you like, the filename will be incremented by 1 each time.
9. All images are saved in PNG format.
10. We are going to use getDataURL() directly from the canvas and not use gl.readPixels at all.
11. Therefore we do not have to set any special flags when we acquire the 3D canvas.
12. If a file already exists of the same name, it will be written over without comment.
13. The images are put in the directory that you run the node server out of.

If you are new to this, these choices made above eliminate a billion or so other possible solutions and therefore makes the problem solvable (instead of iterating through an infinite search space getting half baked quasi solutions on the internet).

When it is all said and done, the result is about 1/2 page of code on the browser/client side and about 1 page or a little more on the server side.  Everything is written in Javascript, with the server side making use of node.js.

Here is the code that works for me.  If you try it and it does not work for you, please let me know.   

Uploading An Image (Client/Browser Side)

When the 3D canvas has an image you wish to save, do the following: 

// generate "dataURL" for the image on the screen
// "canvas" is what is returned from document.getElementById on your webgl canvas

   var newimg_dataurl = canvas.toDataURL("image/png"); 

// NB  The server is going to be looking on socket 8080 and a path of  /imagehandler.  
// But these are arbitrary and can be whatever you like 

   s_postimage(newimg_dataurl, "image/png", "http://localhost:8080/imagehandler"); 

// the function that actually posts the image 

var s_postimage = function(dataurl, imagetype, dest_url) {

    var xr = XMLHttpRequest(); 
    xr.addEventListener("error", xfer_error, false); 
    xr.addEventListener("load", xfer_complete, false); 

    xr.open("POST", dest_url); 
    xr.send(dataurl);

    return;
}; 

var xfer_complete = function(e) {
    // document.write("<br>xfer complete");
}; 

var xfer_error = function(e) {
    if (e) throw e; 
}; 


Uploading an Image (Server Side)

This is run with the command "node imageup.js" where the file imageup.js contains:

var http = require('http');
var url = require('url'); 
var querystring = require('querystring');
var util = require('util'); 
var fs = require('fs'); 

var img_seqno = 0; 

http.createServer(function (req, res) {

    switch(req.url) {

     // This is where you would put in handlers for situations/requests other than 
      // the request to upload an image

    case '/imagehandler':

if (req.method == 'POST') {
           console.log("[200] " + req.method + " to " + req.url);
           var fullBody = "'';
           var fname = "upimage_" + img_seqno.toString() + ".png"; 
           console.log(fname); 

           req.on('data', function(chunk) {
          // append the current chunk of data to the fullBody variable
              fullBody += chunk;
             console.log("data received"); 
});

        req.on('end', function() {
           // request ended -> do something with the data
           res.writeHead(200, "OK", {'Content-Type': 'text/html'});
           console.log("end received"); 

           var base64Data = fullBody.replace(/^data:image\/png;base64,/,"");
           fs.writeFile(fname, base64Data, 'base64', function(err) { 
              if (err) throw err; 
             console.log("image saved " + fname); 
             img_seqno ++; 
}); 
        res.end();
});
} else if (req.method == 'OPTIONS') {

            var headers = {};
            headers["Access-Control-Allow-Origin"] = "*"; 
            headers["Access-Control-Allow-Methods"] = "PUT, POST, GET, DELETE, OPTIONS"; 
             headers["Access-Control-Allow-Credentials"] = false;
             headers["Access-Control-Max-Age"] = '86400'; // 24 hours
             headers["Access-Control-Allow-Headers"] = 
                 "X-Requested-With, X-HTTP-Method-Override, Content-Type, Accept";
            res.writeHead(200, headers); 
            res.end(); 
            console.log("OPTIONS received"); 

        } else {
            console.log("[405] " + req.method + " to " + req.url);
            res.writeHead(405, "Method not supported", {'Content-Type': 'text/html'});
            res.end('<html><body>Method not supported</body></html>');
}
break;


    default:
        res.writeHead(404, "Not found", {'Content-Type': 'text/html'});
      res.end('<html><body>Not found</body></html>');
console.log("[404] " + req.method + " to " + req.url);
    };
}).listen(8080, "127.0.0.1"); // listen on tcp port 8080 on the localhost

// end of server code




Friday, October 11, 2013

Is Anyone Home at Khronos / WebGL ? Hello ?


Is anyone home at WebGL / Khronos ?   I mean, does anyone work there?  Or is it just a front from some sort of criminal organization or venture capital firm that is involved in corporate fraud or something similar?

Maybe, if someone does work there, they could get them to update their documentation, so they do not waste everyone's time?  

About two years ago, a flaw was found in WebGL security and a fix was implemented by Google and Mozilla that completely broke using texture mapping.   There is a work around it for those who want to use texture mapping, but it requires implementing something known as CORS and most people have not.   So bye bye texture mapping.  Who needs it anyway?   No problem.

However, isn't it odd that Khronos and WebGL don't say a word about this on their web site?  Its been over two years since this was broken and they don't mention it once, nor is it mentioned in the few tutorials that they have on their web site that happen to be about texture mapping.  So the question is, what are those people thinking?  A few words on the topic could certainly have saved me some time.  Of course WebGL makes it clear, your time doesn't matter to them.

There is more misinformation out there about WebGL then there is genuine up-to-date and helpful information.   Good old internet.  Gotta love it.  Bold new paradigm, you know.


See how Perlin noise adds a certain grunginess to our rocketship without using texture mapping per se.  Hey, I have an idea!   WebGL could have had noise in specification instead of making everyone implement it on their own.   Oh, that would have been too much trouble, I guess.

Thursday, October 10, 2013

Information about WebGL for the Graphics Professional


There are many aspects of WebGL 1.0 that are somewhat documented and somewhat undocumented. These lacuna are very annoying. Well-meaning web pages that repeat tutorials for absolute beginners over and over again clutter the search engine space and make finding solutions diffiicult.

This post does not have information for beginners or dilettantes.   These notes are for the serious graphics person who is trying to get work done and wants to be more productive. Some of what follows are hard facts or details, some are loose impressions or generalizations.  

-- WebGL is deeply intertwined into Javascript, DOM and the browser, so you must know exactly what you are using because there are differences.

-- Chrome's javascript does not allow "const" in strict mode
-- Chrome's browser throws security violations when attempting to load a texture map
-- Firefox's javascript allows const and does not throw security violations (on linux)
-- Failure to test on your selected OS & browser delivery targets will bite you in the ass
-- You must be very aware of this as you desperately try to get information from the internet

-- Do not assume anything from other OpenGL's will be there.

-- WebGL is not OpenGL ES 2.0
-- WebGL 1.0.2 is derived from OpenGL ES 2.0, but they are not identical
-- WebGL is closeer to OpenGL ES than any of the other OpenGLs though
-- There are almost no carryovers of concepts and ideas and intent from the earlier OpenGLs
-- This is a VERY low level graphics interface, you will reinvent the wheel over and over
-- The WebGL shader language is the same as the shader language of OpenGL ES 1.0 GLSL.

-- Documentation is broken

-- The Khronos site does have a WebGL 1.0.2 specification.
-- The specification is highly concise (at best) or just incomplete (at worst)
-- The shader language is not described beyond the statement that it is the same as GLSL ES 1.0
-- The documentation for GLSL ES 1.0 Shader Language documentation is excellent (see link)
-- There is a pretty good concise WebGL synopsis in PDF form (see link)
-- There is no active forum, the one on Khronos was killed years ago
-- There are a few helpful tutorials on the Khronos site, but not too many, some are wrong
-- The examples on Khronos use techniques that have not worked for years (loading textures)
-- There are relevant articles on the Mozilla developer site, but they are incomplete and the
comments are closed

-- WebGL is fragile and unhelpful

-- Things have to be done exactly their way or it will not work
-- Once something does not work, other errors cascade from it, some of them inexplicable
-- Relentlessly check for webgl errors, do not assume things worked
-- Errors appear either as return codes from WebGL, or in browser error windows, or not at all
-- Most of the WebGL error messsages just say "error"
-- Remember that checking for errors will slow you down, so they must be removed for
production code
-- Sometimes when a problem is unsolvable, I move on to other problems, then come back,
rewrite from scratch using the exact same techniques and everything works.

-- Specific Issues

-- drawArrays "count" is not well defined. It probably wants the number of vertices,
not the number of drawn elements (e.g. triangles) or number of floats, etc.
-- drawElements restricts the number of elements to what will fit in a short. This is not
enough to be useful for many if not most applications
-- The documentation for how to load a texture is wrong and will cause security violations
on modern browsers, it is not clear how much the CORS solution helps
-- texture maps must be exact powers of two in size
-- "const" is not cross-browser, do not use
-- functions are only defined in the shader portion being compiled. A function defined in
a vertex shader will not be available in a fragment shader
-- functions must be defined before use (prototypes may work)

-- Recommendations

-- Use the strict mode of javascript
-- Write or pick a matrix manipulation package for javascript. I use gl-matrix.js
-- Expect to write your own display list manager, object manager, texture manager, etc
-- Expect to spend a lot of time reverse engineering the documentation
-- Be very cautious about what you read on the internet. It is often out of date or applies to
something else that sounds similar but isn't
-- Of course the above warning applies to this post as well.  
-- Test on your target platforms as you develop.  Don't be surprised at the end.

-- Links

-- Article on cross domain textures disabled

-- The WebGL 1.0.2 spec is what passes for documentation

-- The OpenGL ES 1.0 Shader Language Document

-- The WebGL 1.0 Quick Reference Card

Thursday, September 26, 2013

WebGL and the Learning Curve Saga Part III


My WebGL saga continues. If we are talking tortoise vs hare here, then I am certainly the tortoise member of this fable.

Slowly but surely we beat the thing into submission. Its not really bad, just badly documented, IMHO, like so much of the GL family. With WebGl we are definitely in a world circa 1982 or so. But MUCH faster than we ever would have achieved in 1982 no matter how rich you were. So we have vast power on all our desktops, but for some reason "we" have "chosen" to program it in a rather low level way. Well, hell, I like low level now and then. I like debugging this stuff that could have been documented but why bother, they can figure it out on their own.

So here is the kind of things I have been working on instead of figuring out how to end war or torture the rich or writing great fiction.

1. The Element Array Debacle

So, for example, if I had been paying attention, I would have noticed that the "element array" feature of WebGL (1) was defined to be a "short" or a 16 bit number. Warning alarms should have gone off in my head but its been a long time since I have programmed 16 bit machines.   Because its a short, the largest number of elements that one can therefore address is 64K vertices. In other words, it is useless for objects that are of modern complexity. Remember there are no higher order surfaces rendered directly by WebGL so we get the appearance of complexity by having a lot of triangles, I mean a lot of triangles, and maybe play with the shading. Maybe this limitation was noted in the documentation but I don't think so.

The result was that I had to rewrite the core of the object viewer to not use element arrays but just use the vertices, and the vertex attributes, etc. It took about 2 - 3 days and resulted in a much cleaner if slightly more verbose piece of code that could actually be maintained if it had to be.

2. The How Many of WHAT Exactly? Problem

The documentation says that you need to specify the number of things you are transferring. Well now, that could mean the number of triangles, or it could mean the number of vertices it takes to specify the triangles, or it could mean the number of bytes that it takes to hold the data, or ...

And the answer is: its the number of vertices you use to define the object. So the count you send is (3 * number of triangles) or (2 * number of lines). Maybe it was obvious to you, but it sure was not obvious to me from the documentation.

3. The Ongoing Normal Mystery

Look at the following picture. See anything odd? Well, its made out of flat triangles, and you should see flat surfaces. Ok, so its interpolating the normals, whats so odd about this? Its just that all the normals for a face (all triangles really) are all pointing the same direction. Unless WebGl is rebuilding the topology of the object by doing a giant vertex sort, there is no way it could be interpolating the normals.



So what is going on? No one knows, but I suspect that it is a bug in my shader that somehow does not compute the diffuse component correctly. The specular would normally and correctly be "smooth shaded", e.g. not show flat surfaces for the most part. So this maybe is just flat shaded, with transparency, and a specular. If that is not the problem then we are definitely in the twilight zone here.

"This war will be over one day".

You get extra credit for knowing what movie that is from and who said it.

____________________________________

1. Where one specifies a line or triangle by keeping a list of vertex numbers rather than repeating the vertex itself over and over again.



Friday, September 20, 2013

More on the Design of WEBGL and the Origins of .OBJ


We have made a little progress in the last few days on both WebGL and the .OBJ origins issues.

This is an image from the current .OBJ object display software written for WebGL and written in Javascript/DOM/HTML.  Now, I doubt anyone actually needs a .OBJ viewer, its just a way to get familiar with displaying geometry with WebGL.

Instead of just showing you a picture, as I do, below, I should be able to just give you a URL so you can run it yourself, but I can't because I don't actually have a place to post the files for you to address (without seeing advertisements or in other ways compromising or inconveniencing my friends). The only web server I have access to is my own and it has only temporary IP addresses which Facebook will not even let me post. Besides, why bother to post a temporary IP address? I think it is funny how money controls everything, without money, our society says, don't even try to do anything.




So for fun I am posting this dilemma here and on Facebook, maybe someone will know where I can post some number of html and js files in a way that can be accessed by people on the net without inconveniencing them (e.g. no spyware, no ads, no Doubleclick tracking) at a price that even the poor can afford.

Regarding WebGL, once you realize that the designers had gutted it of any even slighlty higher level 3D and that this is a very low level interface to some of the power of the GPU without in any way providing even trivial conveniences for the programmer, everything is fine and you proceed.

I think they did this for good reasons. In the past, by making computers easier to use we opened the doors to allowing people to come in and take away our livelihood. The kind of conveniences I am talking about are trivial and do not hold back an experienced 3D technologist in the least (after they waste their time trying to figure out what the people who redesigned OpenGL were thinking ...).  (1)   So all that happens is that they inconvenience those who are writing their first 3D software and also tend to make such programs written to be a little more obscure because they will all be different (having to reinvent the wheel is trivial here, but since everyone will do it differently naturally it will be a little harder for someone to come in and read and modify because they will have to learn a new convention rather than rely on an industry-wide convention.)

I have no problem with this and in fact applaud it. As a victim of globalization and of the spread of these technologies, anything that makes knowledge that I have more arcane and valuable can only be good.

Regarding the .OBJ matter, we have learned both more and less. The ideas and the general approach to what the .OBJ format became was in the air at SIGGRAPH and the U of Utah in 1979 according to Frank Crow. According to Julian Gomez, there was no software from E&S that would have been an example of a .OBJ like format that would have come from them.   My leading hypothesis had been that the people at Abel's had received some sample software to (for example) load a geometric object and display it on the Picture System.   What would be a normal software development approach would be to start with that program and then write their own software on top of it.   Its an extension of the old joke that Unix only had one device driver (in other words, that everyone modified the original device driver when they had a new device to interface).  Julian may have written one of the first such "display an object" program at Andrews AFB long ago, but it did not use anything similar to a .OBJ-like format.

Julian also suggests that Mickey Mantle, who was in charge of customer support of E&S, may know more.

Thus it is still quite possible that the .OBJ format as we know it was based on ideas that were generally available but not based on specific code from a sample program, as I had expected. In other words, it may still turn out that the Abel version, written initially for motion control preview for Star Trek: The Motion Picture is the one that escaped into the wild (as I believe) and that it originated at Abel's, even if based on ideas more generally available.

 The time when this would have been written by the way is about 1977.

There is more to say, but also more to find out. I have been unable to find any early E&S documentation, for example, which would answer a lot of questions.

If anyone knows how to reach Mickey Mantle, please let me know.
_________________________________________

1. Well, that is not totally true.  OpenGL used to support drawing polygons, convex polygons, directly.  Now only triangles are supported so you have to subdivide into triangles yourself.  The problem is, this is a problem whose general case is actually fairly difficult.  Why not make everyone re-solve this themselves? Its good for them, it makes them think about fundamental principles.   I have no idea what these people were thinking.


Sunday, September 15, 2013

Amazing Simulation of 1970s Graphics in WebGL


Its the mid 1970s all over again.

I actually have written my first WebGL application to display a .obj file.

First you have to convert the .obj to a ".json" file, and then type in its name to some code.  But this process which might seem awkward and stupid, is actually all the more authentic.  This makes the application feel even more 1970s with a retro user interface.

The image is of my test object, a viewpoint .obj of a playing card.   By being completely flat, believe it or not, I can test certain things in my code that was useful.  Yes I know, its not the most compelling 3D object you have ever seen, and you would not even guess that the object is lit, but it is.

So far I have only found one incompatibility between Firefox and Chrome, that being the ability to see the "." as in "period" in a javascript program.   Firefox can, Chrome can not.

The great advantage in having all this in HTML is that it provides all sorts of tools for layout, fonts, scrolling and so forth.  Thus the "program log" window on the far left scrolls which was trivial to implement.


Wow!  Thats exciting, isnt it !

Technical Notes

Ok, so the status display is wrong.  In fact this is the line segments of the very flat 3D object that you are seeing.   The display does not become correct until the user rotates the object and from that point forward it is correct.   Fixed in the next release.


Tuesday, September 10, 2013

Corruption and Degradation in WebGL (revised)


This review was written about a week ago when I was first into my learning curve of javascript, html, dom and webGL.  Well, its a week later and I think that what I was really responding to is / was different than what I thought it was.   Its not about WebGL, its about expectations.   See note at the end of the post.

This is a review on the process of learning Javascript and WebGL. The two are very interconnected and we will start with Javascript and then move to WebGL.

Note, I am not far enough along to have a real opinion about how well WebGL works, because I am spending all my time getting through the learning curve of getting a picture up on the screen. It shows promise, when things work it almost seems magical.

But when you first are learning WebGL you have to get through Javascript so we will start there.

Although Javascript is a little weird, it does grow on you, and there are clever even possibly reasonable solutions to various flaws in the language which, once you get used to their weird syntax, seem to be OK. For example, I am using a variation on the "module" pattern in Javascript and it seems to be working out for me in terms of hiding and keeping internal state of various parts of the program. Furthermore, javascript reminds me a bit of Lisp in its devil-may-care attitude to dynamic memory and its JSON equivalent of an S-Expression. Although initially dealing with Javascript is a problem, in time the problems fade into the background.

The problem is that learning Javascript is something of a pain in the ass, and for the following reasons:

1. Javascript has a specification and a bunch of tutorials, but no serious reference manual or best practices documentation. You are expected to get all that "out on the Internet". Ha.

2. The problem is that each of these tutorials is written by a different person with wildly different skill sets, styles and talent. They are not Kernighan and Ritchie. They are not comprehensive. They are occasionally helpful, they are more often then not incomplete or inaccurate. They are in no way a substitute for a good reference manual.

3. Each of these tutorials by helpful unpaid volunteers uses a different style, and a different set of support packages, all of which are completely incompatible with each other. There is no equivalent to "stdio" in Javascript. One person uses Ajax, another uses Jquery, still another uses something else. These different packages all seem to be useful, ad hoc, mutually incompatible and of wildly varying quality and utility.

4. Learning Javascript is usually intertwined with learning some combination of DOM and HTML, each of which exists in its own versions, varying implementations, and without documentation. Repeat problems of learning Javascript for each of these.

5. Unless you have someone with the knowledge and the time to guide you through this morass, you can count on a very frustrating period and a very time-inefficient process. Its nothing that anyone involved should be proud of. Just because they made a billion dollars at it, does not mean that they did a good job.

But the good news is that, so far at least, in conjunction with a nearly Lisp-like level of interactivity, one can pretty quickly get through the learning curve and onto whatever it is you wanted to do with the language.

But then you get to WebGL and you run into a series of problems which are very related to the ones just mentioned but with a few additional ones to make it all better. Not only is there no reference manual, nor anything close to minimally acceptable reference documentation (a specification is not a reference manual, by the way), but one more time we have the morass of internet tutorials that vary from useful to not, and each of them uses their own support packages for matrix operations and so forth.

But unlike Javascript, with WebGL and all modern graphics APIs, you have to do an awful lot correctly before you can put a cube on the screen. And if you do one of those 30 or 40 things incorrectly, then you will not see a cube on the screen. But each of those 30 or 40 things is badly documented since there is no reference manual, so you are reliant on Internet based tutorials which brings us full-circle on the discussion.

The only way I have found to proceed is to divide and conquer. Which is to work your way through the creation of a working program one module and WebGL call at a time, reverse engineer what the documentation should have been, and then move on.

That takes time.

I am not all that impressed, to tell you the truth.

So now it is a week or so since I wrote the above post.  And I think I was being a little harsh.  Once you get through the learning curve, and get a handle on what documentation that there is, one can become productive.  There are still unsolved riddles but I am able to move around them.   I think that the real problem here, however badly expressed, is one of incorrect expectations.  I expected things to be better, for us to go forward with the best, and not to have to deal with things that are no better designed or documented than what we had 20 years ago.   It is perhaps a let down that we have not come very far in certain ways and that is what I think I was expressing above, without knowing it.  As for the rest, Html, Dom, and even WebGL is fine, if a little weird now and then.