Opened 7 years ago

Closed 6 years ago

Last modified 5 years ago

#9442 closed bug (invalid)

BDirectWindow Timeout Too Short

Reported by: AGMS Owned by: jackburton
Priority: normal Milestone: R1
Component: Kits/Game Kit Version: R1/Development
Keywords: BDirectWindow, DirectConnected, vnc Cc: agmsmith@…
Blocked By: Blocking:
Has a Patch: yes Platform: All

Description

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.

Attachments (1)

0001-Change-DirectConnected-time-limit-fixes-9442.patch (1.3 KB ) - added by AGMS 7 years ago.
Patch to change the DirectConnected() timeout to three seconds.

Download all attachments as: .zip

Change History (12)

comment:1 by jackburton, 7 years ago

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.

by AGMS, 7 years ago

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

comment:2 by AGMS, 7 years ago

Has a Patch: set

comment:3 by AGMS, 7 years ago

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.

Last edited 7 years ago by AGMS (previous) (diff)

comment:4 by axeld, 7 years ago

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.

comment:5 by AGMS, 7 years ago

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!

Last edited 7 years ago by AGMS (previous) (diff)

comment:6 by ttcoder, 7 years ago

Cc: degea@… added

comment:7 by AGMS, 7 years ago

Keywords: vnc added

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.

comment:8 by axeld, 7 years ago

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.

comment:9 by AGMS, 7 years ago

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.

comment:10 by jackburton, 6 years ago

Resolution: invalid
Status: newclosed

comment:11 by ttcoder, 5 years ago

Cc: degea@… removed
Note: See TracTickets for help on using tickets.