BDirectWindow Timeout Too Short

[AGMS]

The BDirectWindow callback function isn't allowed enough time to do its work. According to the BeBook, DirectConnected() has three seconds to finish. In Haiku it seems to be much less.

Needed for VNCServer so that it has time to finish copying the screen to an off-screen buffer, or to compare a slice for differences with the previous frame.

[jackburton]

Yes, the timeout has been reduced (to half a second), since 3 seconds was considered to be too long. Do you experience this problem on an old machine? Because BeScreenCapture does the same, and I've never encountered this issue.

[AGMS]

Patch to change the DirectConnected() timeout to three seconds.

[AGMS]

Yes, it causes trouble when switching resolutions. VNCServer needs to reallocate memory and do a bunch of other things before it can switch to the new screen resolution. And that clocks in at almost 2 seconds in the worst case.

[axeld]

Holding the direct connected lock stalls the complete UI. I'd say if you need two seconds, it's a bug that needs to be fixed on your end. It's not acceptable to lock down the UI that long.

[AGMS]

Sounds reasonable. I'll have to set up some way to abort compressing data from the previous frame (which requires the old bitmap pointer and takes time) so that DirectConnected() can return faster.

Though come to think of it, it's not too long. The user is at the other end of the VNC connection and won't notice the delay. Nobody's there to see the real screen!

[AGMS]

I've worked around it to a large extent by partially ignoring the locking on the bitmap. Rather than waiting for VNC to finish using the bitmap for an update while DirectConnected() is trying to report changes, I just let DirectConnected() do the changes to the bitmap pointer, resolution, etc. The update in progress usually keeps on working, though the end user may see some garbage on their screen due to the change in video memory usage.

[axeld]

You're saying that you'll continue to (read) access the former frame buffer directly, right? As long as you don't write without the lock, nothing bad should happen, at least.

This might not work in future releases, though, as having the complete frame buffer area exposed to user applications, is something we will eventually get rid of. But once we get there, you'll probably be in charge of your window buffer anyway, so it will get even simpler then.

[AGMS]

That's correct. It just reads, so it may be reading garbage but at least it's currently not page faulting.

For the future, it would need some way of getting access to the full screen final compositing bitmap, not just one window's bitmap. Otherwise I may have to do something odd and awkward, like making a fake video card. Come to think of it, the X11 version of VNC does something like that.