home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #16 / NN_1992_16.iso / spool / comp / sys / acorn / 8007 < prev    next >
Encoding:
Internet Message Format  |  1992-07-23  |  3.4 KB
  1. Path: sparky!uunet!comp.vuw.ac.nz!waikato.ac.nz!bwc
  2. From: bwc@waikato.ac.nz (Ug!)
  3. Newsgroups: comp.sys.acorn
  4. Subject: Graphics context switching.
  5. Message-ID: <1992Jul24.102619.9594@waikato.ac.nz>
  6. Date: 24 Jul 92 10:26:19 +1200
  7. Organization: Vooniersity fo Kaiwato
  8. Lines: 60
  9.  
  10. I thought I might have a wee spiel about Graphics context switching; excuse me
  11. if this is all boring stuff.
  12.  
  13. Recently, Owen Smith at Acorn made a comment about printer driver multitasking
  14. only becoming feasible with the advent of several things, among them 'fast
  15. graphics context switching'.
  16.  
  17. So what is it?  Why is it important to the printer drivers?  Why is the
  18. Archimedes slow at switching graphics contexts?
  19.  
  20. When RiscOS swaps from one application or 'task' to another, it needs to save
  21. some information regarding what that task was doing.  This information is
  22. usually referred to as a 'context'.  It's important to keep a whole heap of
  23. information about what each task is doing with graphic: imagine that you are
  24. half way through drawing a line, your application gets swapped out, and when
  25. you come back, the starting point of your line has changed!  That would cause
  26. all sorts of wierd behaviour.
  27.  
  28. Okay, so we've established what graphics contexts are, why they are necessary,
  29. and why they get switched.  So why is the Archimedes slow at this?
  30.  
  31. When RiscOS switches, it copies *all* (or maybe just most) of the information
  32. regarding what the graphics system is currently doing (have a look at
  33. OS_ReadVDUVars sometime to see how much information there is) into the context
  34. of the application which has just finished, and then copies all the information
  35. back again from the application which is about to recommence.  That's a fair
  36. bit of copying.
  37.  
  38. Can this situation be improved?  There are several ways in which changes in
  39. this area are feasible.  One of them is to provide graphics context 'handles'
  40. (much like file handles).  This can be done within RiscOS without the
  41. applications needing to know about it at all.
  42.  
  43. Let me explain.  When RiscOS starts up each tas, it requests a graphics
  44. context handle for that task.  The graphics system sets aside some space
  45. in which a graphics context is stored for the new task, and knows that
  46. whenever this particular handle is used, it should use the context which is
  47. stored in this particular address.
  48.  
  49. That way, when RiscOS swaps from one task to another, it simply tells the
  50. graphics system to use 'context B' (where B is the graphics context handle
  51. of the new task).  No copying.  No saving required.  Fast.
  52.  
  53. So whats the problem with it?  Currently, the only problem is that some
  54. programs may read and alter the graphics context directly, and if the
  55. graphics context is no longer stored in a fixed address in memory, then these
  56. programs will fail.  Of course, this is bad practice on behalf of the program;
  57. they should be using 'OS_ReadVDUVars' and so forth, which would all still
  58. work correctly with the changes mentioned above.  However, there are many
  59. programs out there which use bad practice of some sort or another, and if
  60. they all suddenly upped and failed, then where would we be?
  61.  
  62. Okay, perhaps it's worth it though.  Fast graphics context switching would
  63. not only improve the multitasking capabilities of the printer drivers, but
  64. it would also decrease overall 'task latency' (latency is the time it takes
  65. to switch from one task to another), making RiscOS appear just that little
  66. bit faster.
  67.  
  68. Worth thinking about?
  69.                             Ug!
  70.