Multitask UI Like it’s 1995

full window random rectangles

full window random rectangles

Time to put up some pictures, because words are so boring.

I setup a GameWindow and asked for 1,000 frames per second, and the above is what I got, roughly 940 frames per second.


local win = GameWindow({
		Title = "Game Window",
		KeyboardInteractor = keyboardinteraction,
		MouseInteractor = mouseinteraction,
		FrameRate = 1000,
		OnTickDelegate = ontick,
		OnQuitDelegate = onquit,
		Extent = {1024,768},

animites.rectangler = Animite(win.GDIContext,
  Behaviors.rectangles({Left=0, Top=20, Width=win.Width, Height=(win.Height-1)-20}))

-- get the mites running
for name, mite in pairs(animites) do


This is a bit deceiving, because I’m not actually using the “ontick” routine to do anything but report the frames per second. The rectangle drawing is running in a concurrent task (cooperative coroutine). But, it amounts to the same as running in ontick, because the scheduler doesn’t advance until the rectangle “frame” is drawn.

Alright, so, not bad, with a single ‘task’ we can get 900+ frames per second. Now, how about with multiple tasks? Will that still work?


3 concurrent drawing tasks

3 concurrent drawing tasks

In this case, there are three conccurrent tasks running.  The rectangles, random lines, and random ellipses.  In this case, instead of 900+ frames per second, we’re down into the 600+ fps range.  Still not a bad outcome.  In the cases of the rectangles and lines, only a single item is drawn per frame.  For the ellipses, there are 30 being drawn for each frame.  This all goes by fast enough that it looks like things are happening concurrently (in parallel).  So, I guess string theory is right, and there is just one really fast wiggling particle that makes up our entire universe!

Why did I select the title I did for this little example?  Well, it strikes me that before we had multi-core processors, any semblance of “multi-tasking”, was nothing more than the simple time slicing that I’m doing here.  You could get more fancy and have a kernel that does preemptive interruption of threads, but ignoring that, this is essentially the essence of multi-tasking.

The earliest forms of Windows were like this.  You wrote your code in such a way thay you would yield the CPU or the whole Windows environment would come to a screeching halt.  Then along came the preemptive Windows NT and the world has been a better place ever since.

I think there is still room for the old ways though.  Now, instead of your window cooperating with other windows in the system, you’re concerned with doing various and different things asynchronously, and displaying them independently.  Being able to easily multi-task within your window makes this almost mind numbingly simple to achieve.  Just code up whatever it is you want, and spawn() a task to do it.  The rest is just taken care of.  Within your spawned task you can make network calls, do file manipulation, do some drawing, whatever.  As long as you yield every once in a while, everything will be just fine.

So, there you have it.  One of those otherwise hard programming tasks made relatively easy.  I hope President Obama is watching…

Multitasking single threaded UI – Gaming meets networking

There are two worlds that I want to collide. There is the active UI gaming world, then there’s the more passive networking server world. The difference between these two worlds is the kind of control loop and scheduler that they both typically use.

The scheduler for the networking server is roughly:

while true do

This is great, and works quite well to limit the amount of resources required to run the server because most of the time it’s sitting around idle. This allows you to serve up web pages with a much smaller machine than if you were running flat out, with say a “polling” api.

The game loop is a bit different. On Windows it looks something like this:

while true do
  ffi.fill(msg, ffi.sizeof("MSG"))
  local peeked = User32.PeekMessageA(msg, nil, 0, 0, User32.PM_REMOVE);
  if peeked ~= 0 then
    -- do regular Windows message processing
    local res = User32.TranslateMessage(msg)		


So, when I want to run a networking game, where I take some input from the internet, and incorporate that into the gameplay, I’ve got a basic problem. Who’s on top? Which loop is going to be THE loop?

The answer lies in the fact that the TINN scheduler is a basic infinite loop, and you can modify what occurs within that loop. Last time around, I showed how the waitFor() function can be used to insert a ‘predicate’ into the scheduler’s primary loop. So, perhaps I can recast the gaming loop as a predicate and insert it into the scheduler?

I have a ‘GameWindow’ class that takes care of creating a window, showing it on the screen and dealing with drawing. This window has a run() function which has the typical gaming infinite loop. I have modified this code to recast things in such a way that I can use the waitFor() as the primary looping mechanism. The modification make it look like this:

local appFinish = function(win)

  win.IsRunning = true
  local msg ="MSG")

  local closure = function()
    ffi.fill(msg, ffi.sizeof("MSG"))
    local peeked = User32.PeekMessageA(msg, nil, 0, 0, User32.PM_REMOVE);
    if peeked ~= 0 then
      local res = User32.TranslateMessage(msg)

      if msg.message == User32.WM_QUIT then
        return win:OnQuit()

    if not win.IsRunning then
      return true;

  return closure;

local runWindow = function(self)

  -- Start the FrameTimer
  local period = 1000/self.FrameRate;
  self.FrameTimer = Timer({Delay=period, Period=period, OnTime =self:handleFrameTick()})

  -- wait here until the application window is closed

  -- cancel the frame timer
end = function(self)
  -- spawn the fiber that will wait
  -- for messages to finish
  Task:spawn(runWindow, self);

  -- set quanta to 0 so we don't waste time
  -- in i/o processing if there's nothing there

Starting from the run() function. Only three things need to occur. First, spawn ‘runWindow’ in its own fiber. I want this routine to run in a fiber so that it is cooperative with other parts of the system that might be running.

Second, call ‘setMessageQuanta(0)’. This is a critical piece to get a ‘gaming loop’. This quanta is the amount of time the IO processing part of the scheduler will spend waiting for an IO event to occur. This time will be spent every time through the primary scheduler’s loop. If the value is set to 0, then effectively we have a nice runaway infinite loop for the scheduler. IO events will still be processed, but we won’t spend any time waiting for them to occur.

This has the effect of providing maximum CPU timeslice to various other waiting fibers. If this value is anything other than 0, let’s say ‘5’ for example, then the inner loop of the scheduler will slow to a crawl, providing no better than 60 iterations of the loop per second. Not enough time slice for a game. Setting it to 0 allows more like 3000 iteractions of the loop per second, which gives more time to other fibers.

That’s the trick of this integration right there. Just set the messageQuanta to 0, and away you go. To finish this out, take a look at the runWindow() function. Here just a couple of things are set in place. First, a timer is created. This timer will ultimately end up calling a ‘tick()’ function that the user can specify.

The other thing of note is the use of the waitFor(appCheck(self)). This fiber will block here until the “appCheck()” predicate returns true.

So, finally, the appFinish() predicate, what does that do?

Well, I’ll be darned if it isn’t the essence of the typical game window loop, at least the Windows message handling part of it. Remember that a predicate that is injected to the scheduler using “waitFor()” is executed every time through the scheduler’s loop, so the scheduler’s loop is essentially the same as the outer loop of a typical game.

With all this in place, you can finally do the following:

local GameWindow = require "GameWindow"
local StopWatch = require "StopWatch"

local sw = StopWatch();

-- The routine that gets called for any
-- mouse activity messages
function mouseinteraction(msg, wparam, lparam)
	print(string.format("Mouse: 0x%x", msg))

function keyboardinteraction(msg, wparam, lparam)
	print(string.format("Keyboard: 0x%x", msg))

function randomColor()
		local r = math.random(0,255)
		local g = math.random(0,255)
		local b = math.random(0,255)
		local color = RGB(r,g,b)

	return color

function randomline(win)
	local x1 = math.random() * win.Width
	local y1 = 40 + (math.random() * (win.Height - 40))
	local x2 = math.random() * win.Width
	local y2 = 40 + (math.random() * (win.Height - 40))

	local color = randomColor()
	local ctxt = win.GDIContext;


	ctxt:MoveTo(x1, y1)
	ctxt:LineTo(x2, y2)

function randomrect(win)
	local width = math.random(2,40)
	local height = math.random(2,40)
	local x = math.random(0,win.Width-1-width)
	local y = math.random(0, win.Height-1-height)
	local right = x + width
	local bottom = y + height
	local brushColor = randomColor()

	local ctxt = win.GDIContext;

	--ctxt:RoundRect(x, y, right, bottom, 0, 0)
	ctxt:Rectangle(x, y, right, bottom)

function ontick(win, tickCount)

	for i=1,30 do

	local stats = string.format("Seconds: %f  Frame: %d  FPS: %f", sw:Seconds(), tickCount, tickCount/sw:Seconds())

local appwin = GameWindow({
		Title = "Game Window",
		KeyboardInteractor = keyboardinteraction,
		MouseInteractor = mouseinteraction,
		FrameRate = 24,
		OnTickDelegate = ontick,
		Extent = {1024,768},


This will put a window on the screen, and draw some lines and rectangles at a frame rate of roughly 24 frames per second.

And thus, the two worlds have been melded together. I’m not doing any networking in this particular case, but adding it is no different than doing it for any other networking application. The same scheduler is still at play, and everything else will work as expected.

The cool thing about this is the integration of these two worlds does not require the introduction of multiple threads of execution. Everything is still within the same single threaded context that TINN normally runs with. If real threads are required, they can easily be added and communicated with using the computicles that are within TINN.