[MediaPlayer] jumping on screen

[diver]

One could make MediaPlayer window to jump all over the screen if he will grab it by holding moveable part of it (not title bar) and start moving around, you could notice that it's window will not follow your mouse and will start living with it's own life.

[diver]

Same thing happens with LaunchBox btw.

[diver]

Can't reproduce it anymore, i think it's been fixed.

[stippi]

I tested this too yesterday, extensively, and could not reproduce it. So I am closing this now. I think Axel's recent changes to mouse messages handling in the queue must have fixed it.

[diver]

It's back! i could reproduce it in hrev22333

[diver]

Still here with hrev23879.

[marcusoverhagen]

I think this is a bug in the interface kit.

The code in src/apps/mediaplayer/MainWin.cpp MainWin::_MouseMoved() is pretty simple and works on BeOS R5 and Zeta.

[stippi]

Yes. I can reproduce it again. (Depends on how fast your graphics are.) I think what happens is that mouse messages contain coordinates which make sense if the window is at a specific location on screen. There appears to be a backlog of messages, but since the window was moved, the coords are off. Or something like that. I think mouse coords are actually sent to the window in screen space, so the problem must be somewhere later, when they are converted to the view and then back to the screen space. Or somewhere along those lines... I am gonna have a look.

[jackburton]

Replying to diver:

Same thing happens with LaunchBox btw.

Indeed, but only if you grab it around using the "grippy". IOW: Dragging it around using the window tab works fine instead.

[leavengood]

I can no longer produce this with LaunchBox or MediaPlayer. I tested hrev25091 built with GCC4 in VMware.

Diver could you check again?

[stippi]

This bug is definitely still present, but you cannot reproduce it if your drawing is fast enough. For example, on QEMU you could reproduce it easily. The problem seems to be that mouse coords in the event queue are invalidated by the new window position. The tricky part is that this shouldn't be possible, because those coords are in screen space. But it must be a problem along those lines. Have not looked into it since a while. If screen redraw is fast enough, you don't ever get enough messages piled up into the queue to see the problem.

[jackburton]

Could this have been fixed in hrev26491 ?

[diver]

Can't reproduce it in VirtualBox. Maybe it's fixed indeed?

[stippi]

It's definitely still there, but you need a slow graphics speed, like when the system is under load. It's more easily reproducible with LaunchBox, which uses the same technique as MediaPlayer.

[stippi]

I thought about this some the other day, and I realized what actually caused the problem. The window frame size/position used to be adjusted in MoveBy() and ResizeBy() - sending the app_server relative values. If the real window position/size inside the app_server got seriously out of sync with the client side, because messages piled up, it would cause the behavior described in this ticket. Some time ago (I think) Axel changed that so the commands to the app_server are based on the absolute values (moved the implementation to MoveTo() and ResizeTo()). That made it more robust and actually also solved this ticket.

What still happens is that when the MediaPlayer window is very large, you can see it lagging behind, because mouse messages pile up as before. However, no jumping around on the screen anymore.