Opened 17 years ago

Last modified 17 years ago

#1310 closed bug

[GLTeapot] The teapot can't be controlled by a mouse — at Version 15

Reported by: diver Owned by: korli
Priority: normal Milestone: R1/alpha1
Component: Kits/OpenGL Kit Version: R1/pre-alpha1
Keywords: Cc: jackburton
Blocked By: Blocking:
Platform: All

Description (last modified by jackburton)

The teapot in GLTeapot can't be controlled by a mouse if video mode depth is other than. It used to work sometime in the past.

Change History (15)

comment:1 by korli, 17 years ago

Cc: jackburton added

comment:2 by diver, 17 years ago

It seems it just ignore mouse events, keboard (alt+n) works though.

comment:3 by korli, 17 years ago

It seems changing the priority of the direct daemon thread to less than 15 let me control the teapot with the mouse. Stefano, should I change the priority of the direct daemon thread to (B_DISPLAY_PRIORITY - 1) ?

comment:4 by korli, 17 years ago

Milestone: R1R1/alpha

comment:5 by jackburton, 17 years ago

But does work well here. Especially since Axel's changes to the scheduler.

comment:6 by korli, 17 years ago

This bug is only exposed with 1 CPU machine and VMs. Is it your test case ?

comment:7 by diver, 17 years ago

Yes it is.

comment:8 by jackburton, 17 years ago

Description: modified (diff)
Summary: [GLTeapot] can't be controlled by a mouse anymore[GLTeapot] The teapot can't be controlled by a mouse

Sorry, I hadn't understood what you were talking about. I thought you were talking about the GLTeapot _window_. Not the teapot itself. I can reproduce the bug. I removed the part about the black cursor because that depends on not having a hardware cursor.

in reply to:  3 ; comment:9 by jackburton, 17 years ago

Replying to korli:

It seems changing the priority of the direct daemon thread to less than 15 let me control the teapot with the mouse. Stefano, should I change the priority of the direct daemon thread to (B_DISPLAY_PRIORITY - 1) ?

I find it weird that lowering the priority would fix the problem. Or does it make sense ?

in reply to:  9 comment:10 by jackburton, 17 years ago

Replying to jackburton:

Replying to korli:

It seems changing the priority of the direct daemon thread to less than 15 let me control the teapot with the mouse. Stefano, should I change the priority of the direct daemon thread to (B_DISPLAY_PRIORITY - 1) ?

I find it weird that lowering the priority would fix the problem. Or does it make sense ?

BTW Doesn't work here. I tried lowering the priority using ProcessController but the teapot isn't controllable via mouse.

in reply to:  7 comment:11 by modeenf, 17 years ago

Replying to korli:

This bug is only exposed with 1 CPU machine and VMs. Is it your test case ?

Replying to diver:

Yes it is.

And VMs are vmware? If that's the case and it works on reale HW perhaps it's the OS then? I have tested this on Zeta 1.21 without problems (no not in vmware).

comment:12 by modeenf, 17 years ago

Have tested it in hrev23050 with vmware and the problem are there. GLTeapot also have problem when maximized looks like the BGLView or GLTeapot ObjectView have some problems. As the GLTeapot works in zeta and probably in BeOS i think that the problem are in BGLView?

comment:13 by modeenf, 17 years ago

Tested to add the VMware graphic driver and now I can control the teapot with my mouse. So apparently if you don't use an accelerated driver then the teapot can't be controlled.

in reply to:  13 comment:14 by jackburton, 17 years ago

Replying to modeenf:

Tested to add the VMware graphic driver and now I can control the teapot with my mouse. So apparently if you don't use an accelerated driver then the teapot can't be controlled.

I tested without the VMWare graphic driver, but in 32 bit depth video mode, and the teapot can be controlled. So apparently the problem appears only when using a double buffered video mode (i.e. any mode other than 32 bit depth).

comment:15 by jackburton, 17 years ago

Description: modified (diff)
Note: See TracTickets for help on using tickets.