Smallest Webgl page?

This week I was intrigued by my co worker Andor Salga trying to make a webgl page that was just an empty black canvas, but was still technically a webgl empty black canvas in as few characters as possible. It doesn’t HAVE to be black, though, just some colour of some sort.

Anyway, it ended up on twitter, and was passed around by a couple people and this is what we now have:

<canvas onclick=with(getContext('experimental-webgl'))clearColor(0,0,0,1),clear(16640)>

Please forgive the use of with

It is currently at 88 characters.

I challenge someone to reduce the character count.

I also figure this is a good chance to explain WebGL, how to set it up, and some of the dirty JavaScript tricks used here.

What you need to setup a WebGL context is a canvas, access to a reference of that canvas, three function calls, and a buffer bit seen as 16640 in the current version.

The function calls are getContext, clearColor, and clear.

getContext returns the object that clearColor and clear must be used on.

The buffer bit is actually a constant variable defined as COLOR_BUFFER_BIT, or 16384, or 0×4000, or 0100000000000000, or the bitwise operation 8<<11. With the decimal version being the smallest number of characters at 5. It is that one singular bit in the binary representation we are interested in, but I also found out that the DEPTH_BUFFER_BIT can also be turned on, usually written as COLOR_BUFFER_BIT | DEPTH_BUFFER_BIT giving us the decimal of 16640… still only 5 characters, but I am currently using… just because.

The practical and readable way to do what we need setup would be something like this:

<canvas id="canvas"></canvas>
<script>
  var canvas = document.getElementById( "canvas" );
  var graphics = canvas.getContext( 'experimental-webgl' );

  graphics.clearColor( 0,0,0,1 );
  graphics.clear( graphics.COLOR_BUFFER_BIT | graphics.DEPTH_BUFFER_BIT );
</script>

So how do we go from the above to 88 characters?

First if we drop the script in an event on the canvas element itself so we don't need to create a script element, and we no longer need to search for the element by id as it exists as the keyword "this". The only event I could get to respond in this context was onclick… so onclick it is.

Next is to drop the buffer bit and just use the pure value explained above.

If the string in the onclick event doesn't have any spaces, we don't need to put it in quotes. Good for us as we don't want to use spaces anyway.

Drop the . Valid HTML is far too long

The this word in this.getContext isn’t needed inside the onclick… the browser will find it.

Using with allows us to not have to attach clear and clearColour to an object, just so long as the object returned from getContext is inside the with parameters.

What with does is allows you to take an object as a parameter, and anything inside the following block of code that does not exist within that scope, the browser will then check if it exists inside the object supplied as a parameter. This function is dangerous and there is only ONE time to use this function, and that is when you are trying to make a WebGL page 88 characters

We should now have something that looks like this…

<canvas onclick=with(getContext(‘experimental-webgl’)){clearColor(0,0,0,1);clear(16640)}>

We are at 90 characters now.

To drop those extra two characters we need to make clearColor(0,0,0,1); clear(16640) one command, because just like any operation, if with has no curly braces, it will execute the next line, and end.

We are now going to pervert the ability to define multiple variables using a comma like “var i = 0, a = 1;” so if we drop our function calls in between the comma, it should work… in all the wrong ways… just drop the curly braces and turn the semi-colon into a comma like this “clearColor(0,0,0,1),clear(16640)” That is technically runnable JavaScript.

We now have 88 characters with this:

<canvas onclick=with(getContext('experimental-webgl'))clearColor(0,0,0,1),clear(16640)>

Again, I am challenging someone to make it less than 88 characters.

Been AWOL all year

First post of the new year, and it feels like I have been gone for a year, but I am here still, I just… To sum things up, I got wrapped up, stressed out, and learned a lot. I was burned out, so I took the holidays off, completely off… I barely touched my computer.

Anyway. Gearing up for what is left to do for Popcorn.js 0.2.

I still need to create a 0.1 XML parser using the parser plugin structure, which will be a good test in the parser plugin structure, which hopefully will make things easier in the long run.

Things should now be more organic and dynamic internally, less hassle when it comes to maintenance, and usable by more people.

We addressed the first issue by making tools, tools that can be used by anyone to do what they want, vs what I think they might want.

Second issue, we no longer have the headaches of trying to please everyone, and maintain everyone, we let them do that, and we maintain the tools that allow this.

Final issue, drawing a line between developer and film maker. The developer tools are familiar (Jquery) and the film maker tools are a visual graphical web app called Butter (Final Cut Pro).

Something I have noticed about learning something new. You always produce less short term when you learn more, but in the long run, it is better. The things I have been learning involve Popcorn.js’s 0.2 release, and working with the people over at Bocoup. We have a new code base for popcorn.js, better described in my last post. I would like to call it a re write of the code, but really the old code is still there, it just exists in plugins. The old code was a parser, some fancy timing, and a bunch of “commands”, which all still exists, except it is now wrapped inside something elegant, something new (to me) and something familiar to people familiar with Jquery (a lot of people). The changes were, conceptually nothing difficult. The hard part was learning some new standards, to see faults before I fall into them, and fix them before they are a problem. Something that I notice I spent a lot of my previous time fixing, bugs that, given enough experience, would not of existed. This is OK to me, I am OK with fixing bugs I could of avoided, just so long as I make sure to avoid them the second time, which is something I am trying to improve on.

Working with Popcorn brought me from the standards of a student, where learning is safe, making it work is the ultimate goal, and a school assignment is never actually going to be used, or maintained, just rigidly criticized. To something real, something used by people doing this for a living, maintained, and used. Working in open source, and especially David Humphrey’s OSD class was a perfect middle ground for me, where I can experiment on something real, I had to consider the use cases, maintenance, users, to think, and draw from all my tools to solve an unknown problem, instead of drawing the tools from one chapter to solve the problem stated in that chapter. I guess the main difference in all that rambling is I am now working with people where my academic success is not in their best interest, people that are not getting paid because I am paying them to teach me. Ugh, OK, I had a point here, but I think I lost it within other points. Might be time for bed.