NetNews Usenet Archive 1992 #16/NN_1992_16.iso/spool/comp/sys/acorn/8010

Internet Message Format | 1992-07-23 | 4.5 KB

Path: sparky!uunet!cis.ohio-state.edu!zaphod.mps.ohio-state.edu!wupost!waikato.ac.nz!aukuni.ac.nz!cs18.cs.aukuni.ac.nz!jwil1
Newsgroups: comp.sys.acorn
Subject: Re: Graphics context switching.
Message-ID: <[e-mail]>
From: [e-mail] (TMOTA)
Date: Thu, 23 Jul 1992 23:20:24 GMT
Sender: [e-mail] (TMOTA)
References: <[e-mail]>
Organization: Computer Science Dept. University of Auckland
Lines: 72

[e-mail] (Ug!) writes:

>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.

...except that the application chooses when to be paged out - we don't have
pre-emptive multitasking. Thus, it is up to the application to remember
where it left off... In fact, in the middle of a redraw, when you call
Wimp_GetRectangle to get the next rectangle to draw, the WIMP sets the
drawing colour back to black (I spent about 3 hours trying to figure out
what was wrong with my DSEdit cursor update routine before I realised that
somebody was changing my EOR plotting mode back to black! Argh!)

>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.

Actually, it doesn't copy any of this information. It's up to the app.
to remember things like this. For example, if you select a sprite to draw
with, then after a Wimp_Poll, you cannot assume that sprite is still
the selected one, so when you start drawing again, you must re-select the
sprite (sortof "restore your graphics context"). This is actually pretty
good, because the application only restores the parts of the total context
that it is actually interested in.

The WIMP also changes some values to defaults before calling an app. so that
you can rely on the fact that when you are called, the painting mode is not
left in EOR mode or using dotted lines or whatever. But this is not restoring
a saved context - it simply wipes the context back to a safe default, which
you then modify back to the state that you need. Often this means you don't
have to do anything much (maybe just change the plotting colour)

The problem of saving contexts only happens when printing (and some other
activities) when your output is trapped and sent into a sprite rather than
to the screen - to put it simply, to print, you start the printer driver up
and then redraw your window contents - but the redraw doesn't go to screen,
it is redirected into the printer driver's own "strip buffer" sprite.

The problem with printing in a real "background multitasking" fashion is that
our current printing system uses cooperative multitasking - The printer
driver, once started on a page, is a single-tasking entity communicating
with the printing app. via SWIs. If the application doesn't Wimp_Poll, then
you don't multitask at all.

The problem is that to really do it properly you either need a new cooperative
system designed from the bottom up as a multitasking printer driving system,
or the current system has to be modified to pre-empt the current print job,
save the current graphics context, and then Wimp_Poll.

The major problem with this is that none of our applications expect to be
pre-empted in this fashion - what do you do if a message must be delivered
to the printing application? Is it re-entrant?

Thus, the only real-world solution I can see happening is that we get
partial multitasking as an option, for example, printing a single page to
a file, and then multitasking while the file is dumped in the background
to the printer - this would be very rough, but implementing a better
background printing system would (I think) mean re-designing the current
printing system completely with multitasking as it's main objective.

--
_________________  "I'd like to answer this question in two ways:
  /____ _ _/_ __       First in my normal voice, and then
 // / //_//_ /_/       in a silly, high-pitched whine." (Monty Python)