Canvas Intellisense in Visual Studio

I was playing with HTML5 Canvas element to see how it could be useful in future web based game developments. I like that it is easier than GDI. I haven't yet done much performance testing but it is definitely faster than making games by animating DOM elements.

Recently I had some free time so I decided to create vsdoc documention for Canvas element interface for Visual Studio. I added intellisense (auto competition) and some helps and tips.

Download canvas-vsdoc.js and canvas-utils.js from CodePlex.



It is tuned to work with VS2010, but we can make it work with VS2008 too.

canvas-vsdoc.js contains the intellisense documentation.

canvas-utils.js has a few utility functions (like detecting if the browser supports Canvas) and some enumeration types for things like Line Joins, Repeations, Text Aligns, etc.

To use the intellisense you need to reference canvas-vsdoc.js in the beginning of your JavaScript file, like this:

/// <reference path="canvas-vsdoc.js" />

Note you can just drop the .js file and Visual Studio will write the reference.

Then use a utility method to get a reference to canvas element:

var canvas = Canvas.vsGet(document.getElementById("canvas1"));

Canvas.vsGet(element) receives a HTML element and returns the given element itself if it is in runtime. But in design time it returns Canvas.vsDoc.VSDocCanvasElement object that contains the documentations.

Then you can use the canvas element as usual:

var ctx = canvas.getContext("2d");
ctx.arc(50, 50, 25, 0, Math.PI, true);
…

Please note canvas-vsdoc.js must not be included  in runtime but canvas-utils.js should be included (if you want to use Canvas.vsGet() and other utilities).

In VS2008 you should trick the environment by assigning the variable that refers the 2D context to Canvas.vsDoc.Canvas2dContext, by something like this:

var ctx = canvas.getContext("2d");
if (typeof DESIGN_TIME != "undefined" && DESIGN_TIME)
ctx = Canvas.vsDoc.Canvas2dContext;

DESIGN_TIME global variable is defined inside canvas-vsdoc.js. In runtime it should be undefined or false.

Just a note: if you still want to work in IE, you will find this Google extension very interesting: http://code.google.com/chrome/chromeframe/

Update: Visual Studio 11 natively supports canvas intellisense.

 

 

 

 

 

 

iframe Cookies in Safari

Older Hyzonia games depend on session and authentication cookies. This dependency has been fixed in the newer games by storing session ID in JavaScript variables. The cookie independent services explicitly require a session ID to be sent by their clients.

In this post I am not going to dig into the details of session management in Hyzonia platform, I just want to highlight a series of problems in the old schema that led us to redesign the session management behavior.

Hyzonia games can be embedded in publishers websites using a piece of code we call Hyzobox. Hyzobox basically renders an iframe in the webpage. The internet domain where the actual game is hosted could be different from the publisher's domain. If you have ever tried this before you know that we gonna have a lot of cross site security issues.

To address cross site scripting issues we developed Hyzobox In/Out API. A publisher can control certain things in the game and be notified about the events that are occurring inside the game using In/Out. It is a JavaScript based solution and strangely is widely supported in all major browsers. The In/Out API is not made public yet, but we are using it extensively in www.hyzogames.com. For instance whenever you win in a game Hyzogames.com will be notified about this event (winning) and may show you a message box.

But cookies are another issue. Different browsers have way different behaviors when it comes to handling cookies in iframes.  For starters for it  to works in IE you need a P3P header like this:

CP="IDC DSP COR ADM DEVi TAIi PSA PSD IVAi IVDi CONi HIS OUR IND CNT"

There's a lot to say here, I have a long standing view that P3P is generally useful but this kind of usage is pointless. Anyway for now just add it in your response and relax.

But still Safari rejects the cookies that iframes try to write. The rationale here is that Safari only wants to write cookies from websites that the user directly visits. It's not a bad idea for privacy. Let's assume that you are visiting a fan website for The Grudge! thegrudgefans.com is using  Google AdSense  (put any evil multibillion dollar internet ad service instead of Google :D) to display you some ads or even just in the background. The AdSense is running inside an iframe and it writes a cookie on your computer indicating you're a fan of nonsense horror teen movies. Now it is written on your face that you're a fan of The Grudge. AdSense can use this cookie anywhere else in the internet. OK you got the idea.

The problem was this privacy feature in Safari was causing our Hyzobox User Integration (a kind of Single Sign On service) to break. Safari users can always turn on a checkbox in the preferences to accept all cookies. But it's not the case by default. The workaround is that the page that writes the cookies must be initiated as a result of a direct user request. Literally meaning that prior to writing any cookie you have to provide a hyperlink (an explicit anchor tag) in your iframe that takes the user to the page that writes the cookie.