#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: | ||
Platform: | All |
Description (last modified by )
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 by , 18 years ago
Cc: | added |
---|
comment:2 by , 18 years ago
Cc: | added |
---|
comment:3 by , 18 years ago
Cc: | added |
---|
comment:4 by , 18 years ago
comment:5 by , 18 years ago
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 by , 18 years ago
I could try to implement it, as I have a somewhat deep knowledge of how BDirectWindow works, but I would need a test app.
follow-up: 8 comment:7 by , 18 years ago
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.
follow-up: 9 comment:8 by , 18 years ago
Description: | modified (diff) |
---|---|
Owner: | changed from | to
Priority: | normal → high |
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.
follow-up: 10 comment:9 by , 18 years ago
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).
follow-up: 11 comment:10 by , 18 years ago
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 by , 18 years ago
Resolution: | → fixed |
---|---|
Status: | new → closed |
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 by , 18 years ago
Description: | modified (diff) |
---|
follow-up: 14 comment:13 by , 18 years ago
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 ?
follow-up: 15 comment:14 by , 18 years ago
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 by , 18 years ago
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.
Replying to korli:
What screen savers crash in it?