On 5/6/05, Brian Paul <[EMAIL PROTECTED]> wrote:
In the new renderbuffer scheme, the span routines are passed a gl_renderbuffer pointer to indicate which buffer is to be drawn to. Previously, the driver's set_buffer() routine was called to indicate which buffer the span routines should operate on.
I don't think I'm calling the set_buffer() routine anymore inside _swrast_Clear(). I could try to fix that, but it would be temporary since the set_buffer() stuff is really obsolete now.
I'll check in code for the short-term fix, but we should really update the fbdri span code to respect the gl_renderbuffer parameter.
I think this'll solve your problem.
I will try looking at the span routines. Let's get this one fixed right since the goal is for it to be a working sample for egl.
I think the changes will be straight-forward and intuitive:
1. SPAN_VARS needs: driRenderbuffer *drb = (driRenderbuffer *) rb;
We can do this cast because of the OO-like encapsulation.
2. INIT_PIXEL_PTR should be something like:
GLubyte *P = (GLubyte *)drb->Base.Data + (Y) * drb->pitch + (X) * 33. Remove the unneeded vars from SPAN_VARS, like fbdrawable, dPriv, etc.
4. When the renderbuffers are created in fbCreateBuffer():
4.1 Set drb->Base.Data to point to the start of the front/back
color buffers for the front/back renderbuffers. 4.2 I think the fbOrigin argument can be replaced with 0 since
it won't be needed. 4.3 the fbStrie parameter to driNewRenderbuffer() might not be
correct as-is.5. Examine the remaining code for ramifications of totally removing the set_buffer() function.
I may not have time for the Mesa-based color buffer changes I mentioned the other day. I'll be out of town all next week.
-Brian
------------------------------------------------------- This SF.Net email is sponsored by: NEC IT Guy Games. Get your fingers limbered up and give it your best shot. 4 great events, 4 opportunities to win big! Highest score wins.NEC IT Guy Games. Play to win an NEC 61 plasma display. Visit http://www.necitguy.com/?r=20 -- _______________________________________________ Dri-devel mailing list Dri-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/dri-devel
