Opened 17 years ago
Last modified 16 years ago
#1310 closed bug
[GLTeapot] The teapot can't be controlled by a mouse — at Version 23
Reported by: | diver | Owned by: | stippi |
---|---|---|---|
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 )
The teapot in GLTeapot can't be controlled by a mouse if video mode depth is other than 32bit. It used to work sometime in the past.
Change History (23)
comment:1 by , 17 years ago
Cc: | added |
---|
comment:2 by , 17 years ago
follow-up: 9 comment:3 by , 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 , 17 years ago
Milestone: | R1 → R1/alpha |
---|
comment:5 by , 17 years ago
But does work well here. Especially since Axel's changes to the scheduler.
comment:6 by , 17 years ago
This bug is only exposed with 1 CPU machine and VMs. Is it your test case ?
comment:8 by , 16 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.
follow-up: 10 comment:9 by , 16 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 ?
comment:10 by , 16 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.
comment:11 by , 16 years ago
comment:12 by , 16 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?
follow-up: 14 comment:13 by , 16 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.
comment:14 by , 16 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 , 16 years ago
Description: | modified (diff) |
---|
comment:16 by , 16 years ago
Yes, it used to work when the mesa renderer wasn't implementing DirectConnected(), and using DrawBitmap(). See hrev20797.
follow-up: 18 comment:17 by , 16 years ago
Could the problem be glReadPixels()? It is used in ObjectView to implement hit testing the objects. Where do I need to look for this function?
comment:18 by , 16 years ago
Replying to stippi:
Could the problem be glReadPixels()? It is used in ObjectView to implement hit testing the objects. Where do I need to look for this function?
It's a mesa function. What could happen is that, since we are using a BDirectWindow, the colorspace of the front buffer (used by directwindow) is different than the one of the back buffer (used by the GL Addon), and somehow the GL addon doesn't account for this.
follow-ups: 20 22 comment:19 by , 16 years ago
Or maybe it does, but it shouldn't in certain circumstances, since the objects are drawn as quickly as possible for the hit test (in flat shading mode with special colors that indicate their ID). Such an image never shows, so it looks like it is drawn in some back buffer. Any hints as to where I should look for this?
comment:20 by , 16 years ago
Replying to stippi:
Or maybe it does, but it shouldn't in certain circumstances, since the objects are drawn as quickly as possible for the hit test (in flat shading mode with special colors that indicate their ID). Such an image never shows, so it looks like it is drawn in some back buffer. Any hints as to where I should look for this?
Tried the gl addon in src/add-ons/opengl/mesa_software_renderer/ ?
comment:21 by , 16 years ago
Owner: | changed from | to
---|---|
Status: | new → assigned |
Thanks. Well the MesaSoftwareRenderer's CopyPixelsIn/Out() methods only support 32 bit colors spaces. Maybe that's the problem already. I am going to look into it later.
comment:22 by , 16 years ago
Replying to stippi: Any hints as to where I should look for this?
The GL dispatcher should route the call to : src/kits/opengl/mesa/swrast/s_readpix.c function _swrast_ReadPixels() The Mesa function should then call the render buffer function fRenderBuffer->GetRow(). This one can be get_row_RGBA32(), get_row_RGB32() or get_row_RGB16().
comment:23 by , 16 years ago
Description: | modified (diff) |
---|
It seems it just ignore mouse events, keboard (alt+n) works though.