> The bad thing is that I can't have many windows open when I start mplayer > or DirectFB can't allocate video memory when blitting.
Bah! That sucks. > I think the surface > manager should throw out less used stuff but this doesn't seem to happen > consistently. Perhaps the other windows are really busy somehow or video > memory may be too fragmented. This is problem happens @ 32bpp Which at 640x480 is about 9MB. Just under a third of the memory on the card. > with a 32MB > card. With a 16 MB card I can't even run XDirectFB @ 32bpp since there > won't be enough memory left for the CRTC2 buffers. Wow. Remember when 1MB of video memory was lots and 2MB was a dream? :-) > It allows mplayer to do something useful while we wait for the vsync. Right. I figured that. But how much does it do while the thread waits for vsync though? Does it actually even get to decoding an additional (third right? One being displayed, a second in the back buffer which will become displayed when the vsync happens and the third in main memory which gets blitted to the back buffer when the vsync happens) frame? Which makes me wonder... the video card does the flip between the back buffer and the "front" buffer automatically, right? The process of flipping to the back buffer (the new front buffer) is simply pointing the card at the address space of the back buffer and telling it to display that buffer when the vsync happens (every other vsync though, because each buffer holds both odd and even fields), right? So we have two chunks of memory (buffers) on the card and we just keep pointing the display engine on the card to the two chunks, alternating one after the other, round robbin-like. Do I have it correct so far? We are also decoding MPlayer frames into main memory and copying them to the back buffer rather than decoding them directly into the back buffer. Still right so far? The waiting for vsync in MPlayer is just waiting for the card to be done with the current buffer and switch to the new buffer so that MPlayer can copy the in-main-memory buffer to the back buffer and decode another frame to the in-main-memory buffer. Do I have it all correct? I really should sit down one day and dissect the actual a/v playing engine of MPlayer. > Unfortunately this doesn't help as much as I'd like. Flip() waits > for the > card to become idle before flipping What do you mean "idle"? Is there a good reason to wait for it to be idle? What exactly does Flip() do? I thought it's only purpose was to block the calling process until the vsync interrupt arrives (i.e. to let the process know that the next frame is being displayed). > and since we do Blit() and Flip() in > this order the blit will keep the card busy for some time. The wait for > idle function polls the status register in a tight loop which keeps > my CPU busy. Perhaps it would work better with a dual CPU machine. Yeck. b. -- Brian J. Murrell
msg01239/pgp00000.pgp
Description: PGP signature
