Opened 12 years ago

Closed 12 years ago

Last modified 12 years ago

#1032 closed bug (fixed)

BGLView::DirectConnected() badly implemented

Reported by: korli Owned by: jackburton
Priority: high Milestone: R1
Component: Kits/OpenGL Kit Version: R1/pre-alpha1
Keywords: Cc: phoudoin, jackburton, ekdahl
Blocked By: Blocking:
Has a Patch: no Platform: All

Description (last modified by phoudoin)

BGLView::DirectConnected() is badly implemented. Several screen savers crash in it.

MesaSoftwareRenderer::DirectConnected() is not implemented yet. It could be needed to implement it to fix this bug.

Change History (15)

comment:1 Changed 12 years ago by korli

Cc: phoudoin added

comment:2 Changed 12 years ago by korli

Cc: jackburton added

comment:3 Changed 12 years ago by ekdahl

Cc: ekdahl added

comment:4 in reply to:  description Changed 12 years ago by ekdahl

Replying to korli:

BGLView::DirectConnected() seems badly implemented. Several screen savers crash in it.

What screen savers crash in it?

comment:5 Changed 12 years ago by korli

Quoting phoudoin:

"Well, the idea behind BGLView::DirectConnected is to use the input direct_info data, to keep up-to-date a private copy of such direct_info but always clipped on the GLView frame on screen (or even better, the visible part of it), not its whole BDirectWindow's parent screen frame one. The renderer will use this private copy as he wants (single buffer rendition, fast page swapping for hardware renderers), but he should not have worry about doing the clipping himself.

Clipping GLView's children view(s) could be a bonus, but I'm not sure it's even supported under R5 nor very common case..."

comment:6 Changed 12 years ago by jackburton

I could try to implement it, as I have a somewhat deep knowledge of how BDirectWindow works, but I would need a test app.

comment:7 Changed 12 years ago by korli

I had a look at GLTeapot and it uses a BDirectWindow. Maybe modifying it to have a full screen test version could help. At the moment, BGLView/MesaSoftwareRenderer always uses BView::DrawBitmap() to draw the view content. I suppose BGLView/MesaSoftwareRenderer should instead check whether the parent window is a BDirectWindow, and act differently in this case (using direct_info). I'm no expert here. Having several test cases would surely help.

comment:8 in reply to:  7 ; Changed 12 years ago by phoudoin

Description: modified (diff)
Owner: changed from korli to jackburton
Priority: normalhigh

I guess one could quickly transform Mesa's beos "sample" program to use BDirectWindow instead of plain BWindow and make the GLView not a little bit inner the window area for clipping testbed. Would make a basic test app. I'll try to commit such app as soon as possible, if RealLife (tm) give me a break.

Regarding direct window support, the renderer's EnableDirectMode() method will be first called by BGLView when direct mode is turn on or off. When on, renderer's DirectConnected() method will be called each time the direct access configuration changes, aka in the same cases than BDirectWindow::DirectConnect() method. The single difference is about view vs window. We need to clip the direct mode info to the GLView area before forward the info to the renderer. We should not touch directly ouside view visible region. This clipping task should be done whatever the renderer is, in BGLView::DirectConnected() method, *before* passing (clipped) info to the renderer. The commented out code there today doesn't do such clipping but just copying the info. Rudolf's nvidia 3D driver hack to avoid drawing over menu bar is a workaround which happens to be enough for GLTeapot because beside the menu bar the OpenGL view take full window surface. It's not enough.

The next task, indeed, is to add to our current MesaSoftwareRenderer support for direct rendering, most probably dvia a dedicated direct drawing thread. But it could/should be the subject of a seperate "MesaSoftwareRenderer don't support direct mode" ticket IMHO.

comment:9 in reply to:  8 ; Changed 12 years ago by jackburton

Replying to phoudoin:

I uncommented and changed the implementation of BGLView::DirectConnected() (in hrev20636) to clip the data to the view's bounds before passing it to the renderer. Note that I don't know if it'll work correctly, because the test app GLDirectMode crashes on startup (BWindow->Show()) with a debugger call (looper should be locked before proceeding) (also before my changes).

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

Replying to jackburton:

Replying to phoudoin:

I uncommented and changed the implementation of BGLView::DirectConnected() (in hrev20636) to clip the data to the view's bounds before passing it to the renderer. Note that I don't know if it'll work correctly, because the test app GLDirectMode crashes on startup (BWindow->Show()) with a debugger call (looper should be locked before proceeding) (also before my changes).

That crash was fixed in hrev20725. I think we can close this bug because BGLView::DirectConnected() is implemented correctly now. The mesa gl renderer add-on, though, doesn't take into account that it can write directly to the framebuffer instead of to a bitmap. I think a new bug should be opened for that.

comment:11 in reply to:  10 Changed 12 years ago by phoudoin

Resolution: fixed
Status: newclosed

Replying to jackburton:

I think we can close this bug because BGLView::DirectConnected() is implemented correctly now. The mesa gl renderer add-on, though, doesn't take into account that it can write directly to the framebuffer instead of to a bitmap. I think a new bug should be opened for that.

I've created #1157 in this purpose.

comment:12 Changed 12 years ago by phoudoin

Description: modified (diff)

comment:13 Changed 12 years ago by korli

It would be nice if the window_bounds passed to the renderer were the actual view bounds. The renderer needs to know where the view is placed on the screen, not where the window is placed. Any objections ?

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

Replying to korli:

It would be nice if the window_bounds passed to the renderer were the actual view bounds. The renderer needs to know where the view is placed on the screen, not where the window is placed. Any objections ?

I think we are free to change that, since we are the ones defining the gl addons interface (i.e. there are no be gl addons around).

comment:15 in reply to:  14 Changed 12 years ago by korli

Replying to jackburton:

Replying to korli:

It would be nice if the window_bounds passed to the renderer were the actual view bounds. The renderer needs to know where the view is placed on the screen, not where the window is placed. Any objections ?

I think we are free to change that, since we are the ones defining the gl addons interface (i.e. there are no be gl addons around).

ok it's done. Works fine, locking is still to be added.

Note: See TracTickets for help on using tickets.