home *** CD-ROM | disk | FTP | other *** search
- Path: sparky!uunet!dtix!darwin.sura.net!wupost!uwm.edu!linac!att!ucbvax!upjomon.usl.com!lithgow
- From: lithgow@upjomon.usl.com (Malcolm Lithgow)
- Newsgroups: comp.sys.acorn
- Subject: Re: Graphics context switching.
- Message-ID: <9207240115.AA20056@ucbvax.Berkeley.EDU>
- Date: 23 Jul 92 23:57:29 GMT
- Sender: daemon@ucbvax.BERKELEY.EDU
- Lines: 26
-
- [In message "Graphics context switching.", Ug! writes:]
- >I thought I might have a wee spiel about Graphics context switching; excuse me
- >if this is all boring stuff.
-
- I'll just add my 2 cents worth, since I've already commented on this
- extensively a few months ago...
-
- >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.
-
- As far as I am aware, there are only two cases where graphics context is
- actually switched: when switching output to the printer, and when
- switching output to a sprite. There is no need to swap graphics context
- at task swaps because task swaps are co-operative, and only occur when a
- program has finished playing with its output. (As for things like VMode,
- it writes to a sprite, so it is forced to swap the graphics context,
- anyway.) Task swaps are a bit slow because all the handler vectors have
- to be saved and restored, I think.
-
- Other than that, I agree with what Ug! said in his post, and hope that
- this improvement is made to RISC OS at some time in the (near) future.
-
- -Malcolm. lithgow@usl.com These are merely my opinions.
-