On Fri, 13 Apr 2007 14:21:31 -0400
"Timothy Normand Miller" <[EMAIL PROTECTED]> wrote:
> Something we need to be able to do is enable the interrupt for video.
> Generally, we only need one interrupt per frame, so what we need to do
> is set the interrupt bit in one of the instructions at the end of the
> last active scanline. The thing is, it's not adequate to make that a
> parameter to the programming function... we need to turn the interrupt
> on and off quite a lot,
Why do we need to turn it on and off a lot?
The video apps i know switch it on when they start playing
and switch it off again when the video finishes.
Well, that is if they use an interrupt at all.
Another way to avoid tearing is to use tripple buffers on
the card. One that is currently shown, one that is the next
one to be shown and one that is currently updated by the application.
It uses more memory (three buffers instead of two) and needs
image flip in hardware, but it simplifies programming on the
software side (no interrupts to take care off) and thus seems
to be somewhat prefered. (at least for video apps)
> so what would be nice is to have another
> function to call that enables/disabled interrupts by rewriting the
> right instruction with the flag changed. The problem is that we need
> to somehow keep track of which instruction this is, for multiple cards
> with more than one video head each.
I don't really see the problem here.
> Perhaps it would just be simpler to always set the interrupt in the
> right instruction and have a mask bit in the global config registers.
IMHO we should use the simplest way possible. More complicated
solutions might be more efficient, but they tend to be unused
because they often get too complicated or work only under certain
assumptions efficient.
Attila Kinali
--
Praised are the Fountains of Shelieth, the silver harp of the waters,
But blest in my name forever this stream that stanched my thirst!
-- Deed of Morred
_______________________________________________
Open-graphics mailing list
[email protected]
http://lists.duskglow.com/mailman/listinfo/open-graphics
List service provided by Duskglow Consulting, LLC (www.duskglow.com)
