Tag Archives: webkit

Every Delphi programmer knows how to use the canvas. Its easy, its straight forward and it can be a source of phenomenal frustration if you want to do more than draw straight lines. Good old TCanvas is, despite it’s ease of use, a dinosaur in terms of modern features. The moment you start thinking about anti-aliasing, alpha blending or anything pertaining to rotation – it’s game over for TCanvas.

A smarter canvas

Smart mobile studio implements (or wraps) the HTML5 canvas directly, which means that you have access to all the latest features. The HTML5 canvas was implemented by Apple (webkit codebase) and is the browser equivalent of their Quartz API. This means first of all that it’s a bit trickier to get going, but on the flipside once you master it you can generate some truly amazing graphical effects.

Before we dig into the canvas, i thought it might be best to get up to speed with some of the terminology you are bound to encounter. Some of the concepts are not bound directly to HTML5 but are loosely related to computer programming in general.

Double buffering

Double buffering simply means that you draw your graphics to an offscreen bitmap rather than directly onto the visible canvas. When you are finished drawing you copy (also called “blitting”) the result to the visible display in one fast operation. This technique reduces flickering and makes movement appear smooth. The reason double buffering works is because there is often a delay between your calls – and the actual pixel memory being altered by the CPU/GPU (graphical processing unit). It greatly depends on the kind of hardware you are running, but either way – double buffering is what people do.

On a side note I can mention that Delphi actually uses double buffering by default. If you look up the drawing mechanism for TWinControl you will find that Delphi allocates a new bitmap, draws the control, then copy the result onto the device context. The problem with Delphi is that it allocates a bitmap for each draw, which is extremely slow. Thankfully, we dont have to care about that under Smart Mobile Studio.

Per scene rendering

Under Delphi whenever you use the canvas and call methods like lineto, circle, ellipse etc. these functions are executed “as is”. So once you issue a call to lineTo the underlying WINAPI draws a line into the bitmap your canvas is connected to. This method is very effective, bare bone and does it’s job well. Sadly it is very tricky to create anything modern with this. It’s perfect for 1990’s user interfaces but doesnt cut it for 2013.

HTML5 doesnt really work this way (nor does quartz) because here everything is based on paths. A path is basically just an array of TPoints that you pre-calculate before anything is drawn on screen. So to draw a line you first have to call beginpath, then issue a moveto and lineto command (which we already know under delphi), and finally you draw the line with a call to stroke or endpath. Here is a code snippet from HTML5 Canvas Tutorials:

      canvas.beginPath();
      canvas.moveTo(100, 20);

      // line 1
      canvas.lineTo(200, 160);

      // quadratic curve
      canvas.quadraticCurveTo(230, 200, 250, 120);

      // bezier curve
      canvas.bezierCurveTo(290, -40, 300, 200, 400, 150);

      // line 2
      canvas.lineTo(500, 90);

      canvas.lineWidth := 5;
      canvas.strokeStyle := 'blue';
      canvas.stroke();

Paths are cool

As you can probably imagine, by automating the variables involved you can really get some amazing results with very little effort. Check out this liquid particles demo for instance (click image):

Nice canvas demo

My personal favorite JavaScript demo has to be: or so they say

Also make sure you check out the graphics demos that ship with Smart Mobile Studio for more inspiration! And remember, the smart canvas maps more or less directly to the HTML5 canvas. We have added a few helper routines to make life easier for pascal programmers (and helper classes) but you will have no problems following a HTML5 JavaScript canvas tutorial with Smart Mobile Studio.

Alpha blending

Alpha blending simply means that you can draw graphics that is semi-transparent. Typically alpha blending is associated with 32bit graphics (RGBA) where each pixel or dot on the display is represented by 4 bytes. The first 3 bytes represents red, green and blue while the last byte defines the opacity of the pixel. When you copy a bitmap onto another which uses opacity as an option, it will merge with the existing graphics rather than overlap with it.

Sprites

In the golden days of 16 bit home computers (Amiga and Atari) the hardware supported sprites. A sprite is basically just a small, transparent picture which game programmers use to display and animate characters. In our day of fast processors and high speed 3d effects – there is no longer hardware support for sprites, but the concept of a “sprite” (as a moving graphical element) is still widely used. So if someone uses the term “sprite” or “bob” (the graphical co-processor in the Amiga was called “the blitter”, hence “blitter object”) you what they are talking about.

Next article

In this first installment we have taken a quick look at related concepts that you are bound to meet when programming graphics. Concepts like double buffering, sprites, alpha blending are universal and are deployed on all platforms regardless of language. So it’s handy to get to know these concepts straight away. We have also introduced how the HTML5 canvas works, that it uses paths rather than ad-hoc, brute force like good old TCanvas.

In the next installment we will dive into Smart Mobile Studio and familiarize ourselves with the API and draw some stuff. We will further look at how each of the above concepts work, things like double buffering, in real-life.

Reference material

• W3Schools HTML5 canvas tutorial
• HTML5 path tutorial
• Liquid particles demo
• Apple Quartz API documentation
• Or so they say JS demo