Opened 12 years ago

Closed 12 years ago

#1157 closed enhancement (fixed)

Mesa Software Renderer add-on doesn't support direct mode

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

Description (last modified by phoudoin)

Now that BGLView::DirectConnected() pass correctly clipped screen region to the delegated renderer, we should make some use of it in our defacto default/fallback renderer, the fully software one.

In single buffer opengl mode, we're supposed to blit/span/clear this screen region directly, while in double buffer we could spawn/awake at SwapBuffers() time a thread drawing (eventually doing dithering at fly) the bitmap buffer into the screen region.

Change History (11)

comment:1 Changed 12 years ago by korli

Summary: Mesa Software Renderer add-on don't support direct modeMesa Software Renderer add-on doesn't support direct mode

comment:2 Changed 12 years ago by phoudoin

Description: modified (diff)

comment:3 Changed 12 years ago by korli

Status: newassigned

I began an implementation which obviously requires a buffer colorspace synched with the colorspace of the view's screen (to directdraw). The problem I encounter at the moment is a bad init, which is fixed when moving the window around...

comment:4 Changed 12 years ago by korli

Committed a working implementation in hrev20797. Works fine, though when moving the window, it happens that GLTeapot draws outside of its window, due to a lack of locking. Also, each screen colorspace would have to be supported by the renderer for direct draw. So a check on a supported colorspace should be done before going to direct draw. This way we should still be able to display something with BView::DrawBitmap()

comment:5 in reply to:  4 ; Changed 12 years ago by jackburton

Replying to korli:

Committed a working implementation in hrev20797. Works fine, though when moving the window, it happens that GLTeapot draws outside of its window, due to a lack of locking. Also, each screen colorspace would have to be supported by the renderer for direct draw. So a check on a supported colorspace should be done before going to direct draw. This way we should still be able to display something with BView::DrawBitmap()

I'll add locking. On a side note... maybe it would also be worth to make the renderer addon more generic and able to draw on a generic framebuffer ? That way we could implement BGLWindow more easily.

comment:6 Changed 12 years ago by korli

Stefano, I noticed a lock up after playing a bit with GLTeapot : the teapot keeps running, CPU load is low, the mouse cursor can be move around, but no window can be moved. Could it be a deadlock in app_server ?

comment:7 in reply to:  6 Changed 12 years ago by jackburton

Replying to korli:

Stefano, I noticed a lock up after playing a bit with GLTeapot : the teapot keeps running, CPU load is low, the mouse cursor can be move around, but no window can be moved. Could it be a deadlock in app_server ?

I noticed that too. Maybe it's due to some port limit or excess of messages? It's reproducible also with the "direct_info_test" application.

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

Replying to jackburton:

I'll add locking.

Added in hrev20844.

comment:9 Changed 12 years ago by jackburton

Can we close this bug ?

comment:10 Changed 12 years ago by korli

I'm ok with it. Philippe, what about you ?

comment:11 Changed 12 years ago by phoudoin

Resolution: fixed
Status: assignedclosed

Let's close this ticket, indeed ;-)

Note: See TracTickets for help on using tickets.