[haiku-development] Re: BGLView changes
- From: Philippe Houdoin <philippe.houdoin@xxxxxxxxx>
- To: haiku-development <haiku-development@xxxxxxxxxxxxx>
- Date: Wed, 18 Apr 2012 18:27:55 +0200
Hi,
> Currently every addon has to deal with direct and indirect mode,
> and this makes the code more complex.
Indeed. But it was done for a purpose: while BGLView know how to
interface with a BDirectWindow and collect states information, it
doesn't and should not know how the actual BGLRenderer (living in an
add-on) use these information. An hardware accelerated renderer add-on
may use it to find which area of the framebuffer is the current color
buffer object for instance, and inject the clipping list directly into
the hardware clipping feature of the GPU, making it actually
accelerated.
Depending on its hardware constraint, the renderbuffer content may or
may not be in video memory, mayu or may not have the color buffer in a
BBitmap supported colorspace (not even talking about interleaved
buffers).
That's why the direct mode states information are passed to the
renderer, as it's up to him to do what make sense for him with such
information.
In software renderer case, this can sounds unnecessary, indeed. But
the BGLRenderer interface was not designed with software renderer in
mind.
> I've removed this code, and moved it into the BGLView. The addons now
> just render to a BBitmap, and expose this bitmap via a
> BGLRenderer::Buffer() method.
> The BGLView, in DirectConnected(), copies the buffer into the card's
> framebuffer, taking into account the clipping.
This will be great if all renderers are able to render in a BBitmap
supported colorspace, which is a bet I wont take for hardware
renderer.
For hardware renderer, usually the rendering is directly done in some
area of video memory which is somewhat clipped and blitted by hardware
at buffer swap time. Read the rendered data from video memory in order
to hand it to the BGLView software blitting code will hit a lot
performance.
> This has the following advantages:
> 1. Simplifies the code in the BGLRenderer addons, since the addons
> don't have to care about direct/nondirect mode, and just render into
> their own BBitmap buffer.
They don't have to care about direct mode indeed, but hardware ones
will have to care about clipping list in order to blit correctly each
new frame. The final colorspace could also be useful, as most GPU does
colorspace conversion on silicon too.
> 2. Fixes tickets #7050, #5369, and probably #7738 aswell.
Sure. But making the software renderer ignoring direct mode, relying
on app_server's DrawBitmap to clip and convert color space will do
too.
And that's what I tried to explain in some of these tickets : we win
nothing at supporting direct mode in software rendering, au contraire,
we get issue with software cursor ghost trail, out-of-sync clipping,
etc.
I hope I bring some lights on the purpose of the BGLRenderer interface.
Bye,
Philippe.
Other related posts:
