🚀 go-pugleaf

Michael van Elst (mlelstv@serpens.rhein.de) writes:
>petrin@walrus.megabaud.fi (Petri Nordlund) writes:
>>>That's something that you do not want. You want I/O, decoding and
>>>rendering done concurrently and this means: at the same priority so
>>>that they are timesliced.
>
>>  I don't think that would be a good idea. You don't want image decoding
>>  to slow down rendering or response to GUI events. The magic word here
>>  is: threads.
>
>Where is the problem with decoding "slowing down" rendering ? The total
>time is the same and concurrent operation will give a wanted visual
>progress.

  If rendering just means drawing the decoded images, then it
  doesn't matter. But things like scrolling the document and
  opening other windows like hotlists etc. must not be slowed
  down by this.

>I also didn't say anything about "response to GUI events". I/O means
>network I/O. Sorry, if that was confusing.

  Ok, but why should rendering and decoding slow down network I/O?

>>  The best way to implement a WWW browser would be to use threads with
>>  fixed priorities.
>
>That's what AWeb does, although it runs the threads at the same fixed
>priority of 0.

  Which doesn't make much sense because image decoding slows down
  everything else. You must remember that when the decoder task
  is running and you click on a gadget, the main task is not
  waked up immediately, Exec will let the decoder task run for
  a full quantum. The result is that the main task gets LESS
  than 50% of available CPU time to handle the GUI and user input.

>>     3 rendering
>>     2 decoder (small images)
>>     1 decoder (large images)
>
>And this is something you do not need. Why should rendering stop decoding ?

  Let's say you are scrolling the display, why should decoding make
  scrolling slower?

>>  You can implement this on Amiga, but it doesn't work with dynamic
>>  priorities. If we would have threads on Amiga, there would be only
>>  one task to be scheduled.
>
>We have threads, thank you. And no, most systems schedule threads.

  We have LWPs (Light-Weight Processes), not real threads.
  We need user-level threads run as a single process. All threads
  share the same address space and are scheduled by a selectable
  thread-scheduler. Now we can only guess what would be good
  priorities for different LWPs, hoping that the main task is
  always run at priority 0.

  And if AT decides to bring Amiga OS and multitasking up-to-date,
  we need threads, either OS supported or as a 3rd party shared
  thread-library.
-- 
                                      __
 ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~///~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
       Petri Nordlund             __///         petrin@megabaud.fi
 ---------------------------------\XX/----------------------------------