c3dl Ref Tester 0.3

Closing out OSD before extracurricular work sets in. Let me break done the work and the problems I encountered.

Before I begin let me explain what c3dl is. C3dl is a javascript library used to make writing 3D applications easier. Most notably it utilizing webGL for graphic accelerated rendering in your browser which is all the rage now.

Structure (before my upcoming rework) was taken from Processing.js. My goal was to take that test structure rip all signs of processing out of it and mash c3dl in. I've adjusted my scope a bit, currently my goal is to rework the tester so that it simply tests 2 canvases and spits the result into a third canvas. That way any method of rendering into a canvas can be used because a pixel by pixel comparison won't care how the pixels got there. Of course my contribution will inject c3dl into one canvas and an image into the other.

The purpose behind putting an image and a c3dl rendered scene is this. The reference images were taken at a point of time where that particular scene rendered properly. Comparing that to the same scene rendered now as you load the test. The idea is any changes that broke or changed the result of c3dl rendering would be apparent.

Some problems I encountered were:

• Wasted 2 weeks trying to generate the reference images. Until I realized you can either canvas.getPNG or even better right click "save as" and get a png.
• Learning c3dl, adding multiple canvases and multiple callback mains for each test case revealed many bugs, learning not to test everyone else code was a huge hurtle.

Future problems and goals:

• Break apart the tester and make it focus more on just the pixel arrays of canvases, not how the canvases were filled.
• Change the test case library to something friendly of a larger scale, based on feedback from David Humphrey. That I have no clue.
• Confirm that the pixel comparison and blurring actually work, so I can trust there results. It seems a bit questionable at the moment but it's out of my current abilities.

Links:

• Matrix hosting
• http://matrix.senecac.on.ca/~cwdesautels/osd600/

• Github Repo
• https://github.com/cwdesautels/c3dl/tree/0.2

c3dl Ref Tester 0.1

What is C3DL?
The Canvas 3D JS Libary (C3DL) is a JavaScript library that will make it easier to write 3D applications using WebGL. It provides a set of math, scene, and 3d object classes that makes WebGL more accessible for developers that want to develop 3D content in browser but do not want to have to deal in depth with the 3D math needed to make it work. Website found here.

Ref Tester

Largely ported from David Humphreys Processing.js ref tester found here. I attempted strip out processing and replace it with c3dl to do similar pixel comparisons between canvas's. This proved far more complicated then I anticipated, i had a lot of trouble interpreting all open source projects I encountered. This was solved through exhaustive scanning of Mozilla Development Network and project specific documentation, in addition to asking the pros on #moznet!

0.1

Numerous errors in implementation can be found here, however 0.1 contains:

• ported Processing.js ref tester
• integration of a single c3dl demo
• blurring and comparison of the canvas's 

Beyond

look forward to a fast 0.2 release pending the reviews requested on current release, future goals include:

• exhaustive still tests
• modularization of tests

Links

• Wiki
• Github
• Lighthouse

Osd Lab moz-transform matrices

Last week David Humphrey challenged us to create some video demos, we were instructed to watch these javascript tutorial lectures:

• The JavaScript Programming Language:
• part 1
• part 2
• part 3
• part 4

• Advanced JavaScript:
• part 1
• part 2
• part 3

I attempted to use moz-transform: matrix() to alter videos with wild success. Click here for mozillas MDC.

• GitHub

My lab code can be found here.  Any suggestions are appreciated, I would like to become more proficient with javascript.

Revised Project Plan

Project Name

C3DL test suite

Project Description

Create and implement an automated test suite which compares C3DL still frame render demos and a still frame pictures. Additional innovation will be required for the implementation of moving C3DL demos.

Project Leaders

Andor Salga
Catherine Leung

Project Contributors

Andor Salga
Catherine Leung
Carlin Desautels
Peter Leaning

Project Details

The project will require the initial step of porting Processing.js automated test suite created by David Humphrey. That will produce a framework for which the C3DL demos can be added. The framework will need to be tailored for the project needs, such as: moving demos need to be integrated, replacing Processing.js still frame demos with C3DL ones.

Project Plan

Goals for each release:

•  0.1: 
• Port Davids code 
• Integrate a C3DL demo
• Archive with git and github.com
• Integrate github with C3DL dev team
•  0.2: 
• Integrate all still C3DL still demos
• Streamline automation to developers needs
• Attempt method of including moving demos
•  0.3:
• Fully integrate existing moving C3DL demos
• Attempt personal demo.

Project News

C3DL lighthouse

•  http://c3dl.lighthouseapp.com/dashboard

Processing.js Repo

•  http://github.com/annasob/processing-js

Initial Project Plan

What is your chosen project?

If your reading this and haven't looked at my last post, my project is available here. All I can offer is a brief description of the project, I know it will require me to piece together an automated test auite to compare Mozilla's webGL implementation development with other possible implementations to ensure Mozilla's development doesn't slow. It will also involve some webGL demo creation. Unfortunately that's all I know for now. However a call next week with David's contact Vlad from Moznets #gfx channel.

What will your process be for doing this work?

As per the course requirements I will be doing three project releases, you can also keep track of my progress on my personal wiki. Important dates:

• 15% – 0.1 Release (Due Oct 22)
• 15% – 0.2 Release (Due Nov 16)
• 25% – 0.3 Release (Due Dec 7)

From my understanding the first release goal is to put out an automation tool. Refine it by the second release in addition to putting out a webGL demo. At the third release get an openGL control of a similar demo and comparison tools within the automation.

Plan for 0.1, 0.2, and 0.3 releases

For each release I will need expanding knowledge of HTML5 and it's canvas object in addition to Javascript for the suite and webGL for the demos. I'm not entirely sure what I'm doing or even how to do it. Dave simply pointed me in the direction focused on webGL research for now. He also suggested getting a web page up that uses webGL, even if its very basic.

Who do you need to know and who will you work with?

I'll have three main contacts my teacher David Humphrey, another knowledgeable professor Catherine Leung, lastly Vlad from #moznet. Other then these specific people I'll have access to #seneca and #gfx on irc. So far my conversations have been solely with Dave, with some supplemental lurking on IRC.

Collaboration and contribution? 

Other then these specific people I'll have access to #seneca and #gfx on irc. So far my conversations have been solely with David Humphrey. A phone call with Vlad will happen next week to help flesh out the project and deadlines. My project can help out any my colleagues playing any sort of video or animation using the canvas tag in HTML5. By utilizing my projects functions they should see serious performance gains. On the other hand it would be beneficial for me to get a hold of code used for similar systems so that I can adapt and learn from it.

What barriers stand in your way? 

I'm worried about simply juggling my projects this semester, but I guess baby steps in this new world will help me succeed. Possible risks include shear scope overwhelming me, so I would have to figure out a way to scale it down or scale is back into something more manageable. In order to lessen my risks I need to ask for advice from Dave and simply listen to his sugeestions in addition and applying it to Vlads vision for the project.

Nailing down an OSD project

After a fair bit of procrastination, and finishing other project proposals. The time came around to choose an DPS901/OSD600 project. After briefly going through the list of projects found here. I decided that having a paltry 12 projects to choose from wasn't quite enough.

After speaking to my teacher Dave on IRC I expressed my interest in WebGL, without hesitation David was hitting up his contacts and threw a brand new project to: create a webGL performance test suite. Now that sounds a little daunting. However with the #moznet community and David's guidance, I can't wait soak up these readings and get started.

Here is a list of reading sources thus far:
WebGL Wiki 
Learning WebGL Blog
Mozilla Dev Central WebGL
WebGL Mainpage

I haven't gone through every source in great detail yet. If anyone has more reading suggestions, comment!

Chrome experiments: A Bug's Life

Phase 2 of our: Firefox Performance Testing Lab

After narrowing down all the fun Chrome experiments which use the latest open standards including: HTML5, Canvas, SVG and more! Into significant test cases. That is where most of my class mates would experience our first taste of becoming a contributor to the open source community.

As you can see in my lab link students collaborated together and compiled our results in one place. From there we were on our own. However Not at all because D.Humphrey was available every step of the way to show us how a bug is filed or even if a bug a bug, along side all of the open source community at our finger tips.

My first bug available here. I filed a bug concerning the JavaScript engine when running this chrome experiment.
Steps to recreate:

1. Click launch experiment
2. Drag mouse across experiment window to give you something to bounce against
3. Turn up ball drop rate 15x

Interestingly within minutes of posting the bug and sending to Humph on irc he replied telling me the javascript for the experiment was out of date. So I downloaded the experiment and swapped out the JS with this one provided.

The end result? Minefield performed beautifully and all was well in the world. However I'm still watching the bug for updates to see how I can contribute.

OSD performance

Our latest bit of homework for OSD was for the Firefox javascript engine. Here's what we did:

- Download Minefield(Firefox nightly build)
- Download Chromium(Chrome nightly build)

Got that? Good! Now check out this. These Google experiments are done with functionalities in HTML5.

As a class we divided and conquered all the experiments, taking approximately ten each. That however didn't stop me from wasting far too much time in the other cool experiments. The goal was to identify any problems in Firefox's: speed, responsiveness, and smoothness. Also along the way report any bugs encountered (unfortunately I didn't find any) and finally record our results. Fridays class should show us where were taking this lab.

OSD Lab & Biz

Getting into the mystical world of IRC. A previous semester course OOP344 introduced me to IRC as a medium to meet with our entire group and the teacher for meetings or help. However that was just the tip of the iceberg. D.Humphrey described in brief how useful IRC can be and how we can unlock its potential, much of this was go over a bit more in detail here. More importantly it speaks of the Mozilla community in the very same way I needed to hear about it (it's a recorded lecture). They go over mozilla mailing lists, which after hearing about I promptly joined some. The basic community navigation. The most important thing I think that everyone should listen to again was the handling of Bugzilla. Not only how to use the tool, but how to submit them. Very useful!

The second piece of information was an interesting piece speaking of the potential value of open source for education. I have to agree with Dave in his piece available here. We do want meaningful things to do and open source technology is a great avenue to explore that. The original article is available here.

Delayed Intro to OSD600

OSD600 has completely blown away my expectations of the course, and I haven't even started working yet (more on that tonight).

Let me start off by saying, Early last year when I took OOP344 the teacher Fardad explained in baby steps through the course the tip of the open source iceberg. From my limited exposure I could tell this was something interesting. Over the previous year I wondered what does open source mean? how could it possibly work?

Revolution OS is a beautiful documentary of some of the first open source movements. It elaborated on how open source works, the flagship success story of Linux and its creator Linus' theory of "Release early, release often". Open source did something its proprietary parallel models did not, Eric Raymond's paper The Cathedral and the Bazaar touched on this topic. Applying the theory: Given enough eyeballs are problems are shallow. 


Open source development succeeded in the Bazaar model of development which is apparent confusion from the on looker. It worked because the community grew off free software, and the user suddenly became the developer. People got there pride of being part of something big, they got the customization to their own needs and serious faults became small ones under the community. Just like Eric's experiences and Linux's birth.


Last year the NYTimes told a tail of Mozilla, which is now arguable the most successful open source project to date. In brief it told of Mozilla's success, why it worked against IE. Googles relationship with Mozilla, and the release of Chrome. 


In conclusion I highly anticipate being part of the open source community, if not for career, then to simply share my passion for software and finally contribute to the community. Such as downloading the nightly builds and starting on our first tangible piece of work in OSD.