[app_server] miscalculates GLTeapot clipping region when dragging it across workspaces

[ttcoder]

Steps:

• configure workspaces in two different resolutions
• launch GLTeapot in an 1024x768 workspace
• click-hold its titlebar
• hit Alt-Fn, where 'n' refers to a 800x600 workspace

Behavior: the teapot view continues animating in the new workspace, but _outside_ of its BWindow (!)

Easily reproduced here, and by a friend with a different HW setup.

Looks like BDirectWindow (or it is BGLView) does not like the resolution going down (oddly the bug does not occur in the other direction, when the resolution goes up.. -- maybe the x,y coords of the mouse pointer are changed in the former case and not the latter; and the bug does not occur with normal BWindow/BView's it seems).

[ttcoder]

GLTeapot after abusing Dragging/Alt-²

[ttcoder]

Looks like it's a more general problem in fact, it also occurs when switching between workspaces of the same resolution:

Though it's much more difficult to reproduce in that case: you have to keep Alt-² depressed and drag the teapot window around.

Come to think of it, I've had others troubles on workspace switching -- with a different outcome -- a few weeks ago, that might be related: they involved a bad interaction between audio/VESA; could be triggered by the same bug.. The difference is that it would result in a system freeze (even KDL was inaccessible IIRC), it would be triggered easily at first or second WS switch, and it would occur only if in VESA mode and playing an mp3 in MediaPlayer.

So this could help narrow down the list of suspects: we're seemingly looking at a piece of code close to workspace-switching, that holds a ressource/lock for the duration of the switch and is sensitive to how long the switch takes: if switching to a different resolution (hence taking more time to return) and a concurrent change occurs in some also-sensitive guys (BGLView, some audio drivers, VESA ..etc) then bad things happen easily, otherwise they occur rarely.

[ttcoder]

Can't reproduce this behavior with my current dev PC (laptop, hence LCD display, instead of CRT I had tried with back then) and with the current haiku hrev.

[ttcoder]

Found a trivially easy way to trigger a/the bug in hrev45681:

• launch GLTeapot
• resize its window by 1 pixel or more
• close it.

Note: resizing up by 1 pixel does the trick, whereas resizing down by one pixel does not trigger any bug.

Also this observation might be more useful in another ticket, since the bug I'm seeing in this scenario only involves leftovers/remnants of the teapot, not an actually spinning (moving) teapot.

[ttcoder]

Note to self: check again after hrev53711 & friends.