BDirectWindow is broken.

[bga]

1 - Start Chart.
2 - Resize its window to a bigger size.
3 - Start animation (it can be "Free motion".
4 - Enable display with DirectWindow.

You will see that it is not using the entire drawing area (it seems to be using an area that has the size of the window before it was made bigger (but I am not 100% sure about this). Then, to make things worse, move the window around... the animation starts being draw outside the Window.

Also Chart does not quit correctly, getting stuck waiting for a semaphore:

#0  0xffff0114 in ?? ()
#1  0x004e4de5 in acquire_sem_etc () from /boot/system/lib/libroot.so
#2  0x002df51e in BLooper::_LockComplete () from /boot/system/lib/libbe.so
#3  0x002df479 in BLooper::_Lock () from /boot/system/lib/libbe.so
#4  0x002de784 in BLooper::Lock () from /boot/system/lib/libbe.so
#5  0x002d60ab in BApplication::_WindowQuitLoop ()
   from /boot/system/lib/libbe.so
#6  0x002d61a3 in BApplication::_QuitAllWindows ()
   from /boot/system/lib/libbe.so
#7  0x002d3561 in BApplication::QuitRequested () from /boot/system/lib/libbe.so
#8  0x002dfca0 in BLooper::_QuitRequested () from /boot/system/lib/libbe.so
#9  0x002de272 in BLooper::DispatchMessage () from /boot/system/lib/libbe.so
#10 0x002d4ca9 in BApplication::DispatchMessage ()
   from /boot/system/lib/libbe.so
#11 0x002dfbf5 in BLooper::task_looper () from /boot/system/lib/libbe.so
#12 0x002d3415 in BApplication::Run () from /boot/system/lib/libbe.so
#13 0x00207b6a in main ()

Also reproducible with the GLTeapot demo, which is also using a BDirectWindow.

[jackburton]

That's just great. I'm sure it's caused by my latest changes. I was sure I tested extensively but obviously not THAT extensively :) I'm on it, anyway.

[jackburton]

After more debugging... I found that the BDirectWindow B_DIRECT_START notification sent on window show deadlocks in some way with the other things done in the app_server, when a windows is shown. The only reason this isn't a deadlock is that the app_server waits with a timeout on the client semaphore. When changing the #if 0 to in DirectWindowData::_SynchronizeWithClient(), line 90, to #if 1, we get a deadlock. Why this has started to happen only lately I don't know. I'll try to use the kernel debugger (which, btw, I can't enter on QEMU with this laptop due to the weird placement of the sysreq key) to see where's the deadlock.

[mmlr]

You can use the QEMU monitor to enter KDL. Press ctrl-alt-2 to switch to the monitor, enter "sendkeys alt-sysrq-d" to enter KDL and then press ctrl-alt-1 to switch back to the OS.

[jackburton]

Replying to mmlr:

You can use the QEMU monitor to enter KDL. Press ctrl-alt-2 to switch to the monitor, enter "sendkeys alt-sysrq-d" to enter KDL and then press ctrl-alt-1 to switch back to the OS.

Thanks!

BTW, I managed to avoid the deadlock by using an extra thread to carry the acquire/release part of DirectWindowData::_SyncronizeWithClient(). The problem, in this case, is that the notification could lag behind a bit, and in fact, I get again spurious redraws outside the clipping region. Back at work...

[jackburton]

Interestingly, the DirectWindowStars demo doesn't suffer of this problem, but if I add a "Lock(); Unlock();" pair in its BWindow constructor, it starts to behave like the other (nonworking) tests. Freaky.

[jackburton]

Fixed by Axel in hrev32742. The deadlock was caused by the changes in hrev32566 and hrev32420.