GitLab

Sprout from master 2001-07-30 15:02:39 UTC Dan Ellis <dellis@gitlab.riscosopen.org> '  Added pollidle handling for INKEY (OS_Byte 129)'
Cherrypick from master 1997-05-01 17:56:56 UTC Kevin Bracey <kbracey@gitlab.riscosopen.org> 'Version RO_3_71 merged':
    Syntax
    Version
    s/TaskIcon
Cherrypick from master 2000-05-31 15:31:21 UTC Stewart Brodie <sbrodie@gitlab.riscosopen.org> '  32-bit compatible':
    s/Redirect

Detail:
  Taskwindow sits of BYTEV and waits for n*2 Vsyncs when INKEY(n) is called.
This isn't quite correct as VSyncs aren't a reliable timing source, however,
leaving that aside for the moment, what Taskwindow was doing was sitting on
Null events until it read that enough Vsyncs had passed, thus eating up CPU
time.

  The new behaviour is to call Wimp_PollIdle instead, which should also
correct the amount of time waited for.  This behaviour can be toggled with
the build switch PollIdleHandling.

Admin:
  Lightly tested on a RPC.  Using AppStat, no call were made to the
taskwindow during and INKEY, whereas they were previously.


Version 0.66. Tagged as 'TaskWindow-0_66'

Detail:
  UpCall 6 is documented as accepting a pollword which can be scanned for
being non zero to return control to the process requesting to sleep.  This
was not being used within the taskwindow module, there being a comment where
it would have been used suggesting that this would give the taskwindow too
high a priority.  What this means is that if given a pollword that is already
nonzero, the task would receive so many polls as to really make the desktop
juddery.  The solution is that if the pollword is non-zero on entry,
Wimp_Null is unmasked rather than passing the pollword.

  This means that UpCall 6 can be used either as a yield, to say 'let other
tasks have some CPU now' (by passing a pollword known to contain nonzero) or
as sleep to say 'wake me up when the pollword becomes non zero, and don't
consume any CPU time until then' (by passing a pollword that will only become
nonzero upon the occurance of a specific event).

Admin:
  Tested on RPC.

Version 0.65. Tagged as 'TaskWindow-0_65'

Detail:
  The UpCall wasn't being claimed because the common error creating return
was being used which returns to lr rather than popping the stack.  Now the
error routine is BLed to and then the stack popped so as to claim the UpCall.

Admin:
  Tested on RPC.

Version 0.64. Tagged as 'TaskWindow-0_64'

Detail:
  If output is occurring quickly, then fewer longer Wimp messages are
    transmitted rather than a stream of small messages.
  RAM Transfer buffer size increased too.
Admin:
  Tested in softloaded OS.


Version 0.63. Tagged as 'TaskWindow-0_63'

  Updated to build using objasm instead of aasm.
  Sources changed to be objasm-compatible.
Admin:
  Requires Library 0.71 or later.
  Requires BuildSys 3.06 or later.
  Requires Env 0.65 or later.

Version 0.62. Tagged as 'TaskWindow-0_62'

  ... switched to using objasm.
Detail:
  Increased parameter buffer size to 1024.
Admin:
  Requires BuildSys 3.01 or later.
  Fixes Bugzilla bug #280

Version 0.61. Tagged as 'TaskWindow-0_61'

Detail:
  TaskWindow used to enable VSync events for each new task that was
    started.  However, it failed to disable the VSync events again
    when the task exited unless the task was the last one running.
    This meant that VSyncs would be going off for no reason at all
    slowing the machine down if you had ever started a taskwindow.
    Events are now only ever enabled when the first task is created,
    and disabled when the last task is killed.
Admin:
  Tested in desktop build.

Version 0.60. Tagged as 'TaskWindow-0_60'

Detail:
  Fixed the spurious character problem.  It was due to me believing some
    misleading comments in the source code.  When the comment said "pass
    it on" (at the end of a vector handler), it actually meant "claim it".
    WrchV is now claimed correctly, and no output is "leaked" any more.
Admin:
  Module may well no longer function on RISC OS 2.00
  Tested on Ursula build.

Version 0.59. Tagged as 'TaskWindow-0_59'

Detail:
  Removed obsolete file.
  Made rest of the module 32-bit safe.
  A bug remains: when a taskwindow is started the first few characters of
    output are not being intercepted correctly (although they are sent to
    the parent task).  Looks as if something isn't initialised correctly?
    Perhaps a failure to intercept WrchV in these cases?
Admin:
  Tested in Ursula softload.


Version 0.58. Not tagged

Detail:
  Moved to srccommit, merged changes from Ursula branch.
Admin:
  Built.

Version 0.58. Tagged as 'TaskWindow-0_58'