Opened 12 years ago

Closed 10 years ago

#1307 closed bug (fixed)

[MediaPlayer] jumping on screen

Reported by: diver Owned by: stippi
Priority: normal Milestone: R1
Component: Kits/Interface Kit Version: R1/pre-alpha1
Keywords: Cc: stippi
Blocked By: Blocking:
Has a Patch: no Platform: All

Description

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.

Change History (15)

comment:1 by diver, 12 years ago

Same thing happens with LaunchBox btw.

comment:2 by diver, 12 years ago

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

comment:3 by stippi, 12 years ago

Resolution: fixed
Status: newclosed

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.

comment:4 by diver, 12 years ago

Resolution: fixed
Status: closedreopened

It's back! i could reproduce it in hrev22333

comment:5 by diver, 12 years ago

Cc: stippi added

Still here with hrev23879.

comment:6 by marcusoverhagen, 12 years ago

Cc: stippi removed
Component: - Applications/MediaPlayerKits/Interface Kit

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.

comment:7 by marcusoverhagen, 12 years ago

Cc: stippi added
Owner: marcusoverhagen removed
Status: reopenednew

comment:8 by stippi, 12 years ago

Owner: set to stippi
Status: newassigned

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.

in reply to:  1 comment:9 by jackburton, 12 years ago

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.

comment:10 by leavengood, 11 years ago

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

Diver could you check again?

comment:11 by stippi, 11 years ago

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.

comment:12 by jackburton, 11 years ago

Could this have been fixed in hrev26491 ?

comment:13 by diver, 11 years ago

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

comment:14 by stippi, 11 years ago

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.

comment:15 by stippi, 10 years ago

Resolution: fixed
Status: assignedclosed

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.

Note: See TracTickets for help on using tickets.