NetNews Offline 2/NetNews Offline Volume 2.iso/news/comp/sys/amiga/programmer/2784

Internet Message Format | 1996-08-05 | 3.8 KB

Path: Hermes.grace.irl.cri.nz!maths!peterm
From: [e-mail] (Peter McGavin)
Newsgroups: comp.sys.amiga.programmer
Subject: Re: Demo/game to OS friendly part II
Date: 05 Feb 1996 00:19:10 GMT
Organization: Industrial Research Ltd
Message-ID: <[e-mail]>
References: <[e-mail]>
    <[e-mail]>
    <4ek6bo$[e-mail]> <4ekl5d$[e-mail]>
    <[e-mail]>
    <4ep546$[e-mail]>
    <[e-mail]>
    <4eq5s3$[e-mail]>
NNTP-Posting-Host: tui.grace.cri.nz
In-reply-to: [e-mail]'s message of 1 Feb 1996 11:49:39 +0100

[e-mail] (Michael van Elst) writes:
>[e-mail] (Peter McGavin) writes:
>>[e-mail] (Michael van Elst) writes:
>>>[e-mail] (Peter McGavin) writes:
>>>>Current high-level gfx calls have a queue limit of 1 (or less than 1).
>>>Right. But that's as good as N.
>>I assume you mean by creating another task to process the queue.
>No, I mean for the interface. A caller now cannot rely on the operation
>being completed which means that you could extend the queue to any
>depth.

Ah, I thought you were talking about the current implementation.  Part
of my original proposal is that some future implementation of the OS
should maintain a longer queue.  I never proposed breaking apps using
the current interface.  Only the internal implementation would change.
(OK, apps that sync with WaitBlit() could be problematic.)

>>There is a problem with the current implementation that WaitBlit() is
>>CPU-intensive for large blits.
>
>Yes.
>
>>So queuing large gfx operations
>>(perhaps with some smaller operations in the queue as well) eats CPU
>>time.
>
>No, because you usually do not need to call WaitBlit() explicitely.
>The graphics functions do. And if these were using a real queue they
>could Wait() for a signal from the queuer.

Again, I was still talking about the current implementation, for which
the problem still exists.  I agree that implementing a queue and an
alternative wait mechanism would fix it.

>>Also, there may be problems queuing some operations like
>>ChangeScreenBuffer() when the Screen is opened by the parent task (or
>>perhaps not --- I don't really know).
>
>This function would need to take care of queued operations. Right.

I wasn't sure about sharing a Screen and other gfx structures between
tasks in the current implementation (i.e, if the user's app starts
another task to process the queue).

>If you queue an operation and rely on the results you have to
>synchronize with the rendering. Just waiting "for the blitter" works
>if the blitter is the only hardware that you could wait for. For other
>hardware a WaitBlit() would have to synchronize with that
>hardware. And that is a big waste and WaitBlit() becomes slow
>too. What I propose is a WaitBitMap() that stops your task until all
>rendering done to that bitmap had been completed. After all you are
>not interested into other BitMaps when you want to examine the result
>(or free the BitMap). You would also need a lower-level function that
>gives you a message port or signal bit so that you can Wait() for it
>concurrently with other events.

I agree those are good ideas.

Now, isn't a queue of gfx-operations simply a queue of messages (or
packets)?  Wouldn't a straightforward implementation be that a
high-level gfx function sends a message to some handler task for the
bitmap?  Except some gfx calls would only construct a portion of a
message as a form of buffering, or simply return a status or
something.  Or do you propose hanging everything off interrupts, like
QBlit() (which would get messy IMO)?  In the former case, haven't we
come full circle?
--
Peter McGavin.   ([e-mail])