🚀 go-pugleaf

petrin@walrus.megabaud.fi (Petri Nordlund) writes:

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

It isn't slowed down by this because it is not "rendering".

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

Just because something _has_ to become slower when the machine spends
100% of the CPU. Simple math.

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

It doesn't slow down the GUI and it _should_ slow down rendering of the
pages.

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

Which isn't a problem. The quantum is small enough.

>  The result is that the main task gets LESS
>  than 50% of available CPU time to handle the GUI and user input.

Not really. It just gets less when it needs less. If it needs several
timeslices for an action then it is timesliced like any other CPU-intensive
process.

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

Scrolling is a job of the user-interface and not rendering a page.

>>We have threads, thank you. And no, most systems schedule threads.

>  We have LWPs (Light-Weight Processes), not real threads.

Obviously we have, one thread per task.

>  We need user-level threads run as a single process.

You mean that we need multiple threads or tasks to be scheduled as a group.

>  All threads
>  share the same address space and are scheduled by a selectable
>  thread-scheduler.

All threads/tasks in the Amiga share the same address space.

-- 
                                Michael van Elst

Internet: mlelstv@serpens.rhein.de
                                "A potential Snark may lurk in every tree."