Opened 12 years ago

Closed 11 years ago

Last modified 11 years ago

#1310 closed bug (fixed)

[GLTeapot] The teapot can't be controlled by a mouse

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:
Has a Patch: no 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 32bit. It used to work sometime in the past.

Attachments (1)

glteapot.patch (1.0 KB) - added by korli 11 years ago.
uses a 5 bit key value to be usable on all colorspaces

Download all attachments as: .zip

Change History (31)

comment:1 Changed 12 years ago by korli

Cc: jackburton added

comment:2 Changed 12 years ago by diver

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

comment:3 Changed 12 years ago by 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) ?

comment:4 Changed 12 years ago by korli

Milestone: R1R1/alpha

comment:5 Changed 12 years ago by jackburton

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

comment:6 Changed 12 years ago by korli

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

comment:7 Changed 12 years ago by diver

Yes it is.

comment:8 Changed 11 years ago by jackburton

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.

comment:9 in reply to:  3 ; Changed 11 years ago by 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 ?

comment:10 in reply to:  9 Changed 11 years ago by jackburton

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 in reply to:  7 Changed 11 years ago by modeenf

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 Changed 11 years ago by modeenf

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 Changed 11 years ago by 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.

comment:14 in reply to:  13 Changed 11 years ago by jackburton

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 Changed 11 years ago by jackburton

Description: modified (diff)

comment:16 Changed 11 years ago by korli

Yes, it used to work when the mesa renderer wasn't implementing DirectConnected(), and using DrawBitmap(). See hrev20797.

comment:17 Changed 11 years ago by 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?

comment:18 in reply to:  17 Changed 11 years ago by jackburton

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.

comment:19 Changed 11 years ago by 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?

comment:20 in reply to:  19 Changed 11 years ago by jackburton

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 Changed 11 years ago by stippi

Owner: changed from korli to stippi
Status: newassigned

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 in reply to:  19 Changed 11 years ago by korli

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 Changed 11 years ago by jackburton

Description: modified (diff)

comment:24 Changed 11 years ago by stippi

Owner: stippi deleted
Status: assignednew

It isn't what I thought (CopyPixelsIn/Out()) ... so anyone feel free to fix it.

comment:25 Changed 11 years ago by korli

Owner: set to korli

Changed 11 years ago by korli

Attachment: glteapot.patch added

uses a 5 bit key value to be usable on all colorspaces

comment:26 Changed 11 years ago by korli

This patch fixes the bad behavior on 16 bits colorspaces. Rendering is really done with a 16 bits colorspace buffer which is logical. Though on BeOS, it seems the rendering is done with a 32 bits colorspace buffer, which would explain why GLTeapot behaves correctly there. I think this problem is a bit implementation dependent, and GLTeapot bases its behavior on the implementation: this would be a good reason to patch GLTeapot. Thoughts ?

comment:27 Changed 11 years ago by stippi

I understand the patch only vaguely, but I am pro fixing GLTeapot if it makes some wrong assumptions about pixel depths... :-)

Thanks for figuring this one out.

comment:28 Changed 11 years ago by korli

I'll add a comment to this patch to explain the difference of behavior of rendering on Haiku.

comment:29 Changed 11 years ago by korli

Resolution: fixed
Status: newclosed

fixed in hrev23793

comment:30 in reply to:  26 Changed 11 years ago by phoudoin

I think this problem is a bit implementation dependent, and GLTeapot bases its behavior on the implementation: this would be a good reason to patch GLTeapot. Thought?

You're right, GLTeapot made the assumption that rendering is always done in a 32 bits RGB pixels buffer, so no color space conversion rounding errors could occurs.

GLTeapot code is the faulty here, as such assumption in OpenGL should not be made. Notice, BTW, that BGLView don't offer a way to specify RGB colordepth. It's BGL_RGB or BGL_INDEX, period. On other platforms, there is often a way to ask for a 16, 24 or 32bits colorspace.

Note: See TracTickets for help on using tickets.