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

[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.

[korli]

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...

[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()

[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.

[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 ?

[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.

[jackburton]

Replying to jackburton:

I'll add locking.

Added in hrev20844.

[jackburton]

Can we close this bug ?

[korli]

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

[phoudoin]

Let's close this ticket, indeed ;-)