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…

One Comment on “Multitask UI Like it’s 1995”

  1. […] Multitask UI Like it’s 1995 […]

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s