From: bwc@waikato.ac.nz (Ug!)
Newsgroups: comp.sys.acorn
Subject: Graphics context switching.
Date: 24 Jul 92 10:26:19 +1200
Organization: Vooniersity fo Kaiwato

I thought I might have a wee spiel about Graphics context switching; excuse me
if this is all boring stuff.

Recently, Owen Smith at Acorn made a comment about printer driver multitasking
only becoming feasible with the advent of several things, among them 'fast
graphics context switching'.

So what is it?  Why is it important to the printer drivers?  Why is the
Archimedes slow at switching graphics contexts?

When RiscOS swaps from one application or 'task' to another, it needs to save
some information regarding what that task was doing.  This information is
usually referred to as a 'context'.  It's important to keep a whole heap of
information about what each task is doing with graphic: imagine that you are
half way through drawing a line, your application gets swapped out, and when
you come back, the starting point of your line has changed!  That would cause
all sorts of wierd behaviour.

Okay, so we've established what graphics contexts are, why they are necessary,
and why they get switched.  So why is the Archimedes slow at this?

When RiscOS switches, it copies *all* (or maybe just most) of the information
regarding what the graphics system is currently doing (have a look at
OS_ReadVDUVars sometime to see how much information there is) into the context
of the application which has just finished, and then copies all the information
back again from the application which is about to recommence.  That's a fair
bit of copying.

Can this situation be improved?  There are several ways in which changes in
this area are feasible.  One of them is to provide graphics context 'handles'
(much like file handles).  This can be done within RiscOS without the
applications needing to know about it at all.

Let me explain.  When RiscOS starts up each tas, it requests a graphics
context handle for that task.  The graphics system sets aside some space
in which a graphics context is stored for the new task, and knows that
whenever this particular handle is used, it should use the context which is
stored in this particular address.

That way, when RiscOS swaps from one task to another, it simply tells the
graphics system to use 'context B' (where B is the graphics context handle
of the new task).  No copying.  No saving required.  Fast.

So whats the problem with it?  Currently, the only problem is that some
programs may read and alter the graphics context directly, and if the
graphics context is no longer stored in a fixed address in memory, then these
programs will fail.  Of course, this is bad practice on behalf of the program;
they should be using 'OS_ReadVDUVars' and so forth, which would all still
work correctly with the changes mentioned above.  However, there are many
programs out there which use bad practice of some sort or another, and if
they all suddenly upped and failed, then where would we be?

Okay, perhaps it's worth it though.  Fast graphics context switching would
not only improve the multitasking capabilities of the printer drivers, but
it would also decrease overall 'task latency' (latency is the time it takes
to switch from one task to another), making RiscOS appear just that little
bit faster.

Worth thinking about?
							Ug!
Newsgroups: comp.sys.acorn