🚀 go-pugleaf

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.

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

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

>     3 rendering
>     2 decoder (small images)
>     1 decoder (large images)

And this is something you do not need. Why should rendering stop decoding ?

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

>  And with this arrangement, small images would appear more quickly,
>  not held back by one large image that takes ages to decode.

Not true. The appearance of images depends mainly on the order in which
they are retrieved. If multiple connections are used then small images
are automatically displayed faster.

Regards,
-- 
                                Michael van Elst

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