| Age | Commit message (Collapse) | Author |
|---|
|
|
|
|
|
Before, if we just called glXMakeCurrent() and didn't render anything we'd
still trigger a flushFrontBuffer() call.
Now only set the intel->front_buffer_dirty field at state validation time
just before we draw something.
NOTE: additional calls to intel_check_front_buffer_rendering() might be
needed if I missed some rendering paths.
|
|
This saves an inadvertent round-trip to the X Server on DrawBuffers, which was
hurting some metaops.
|
|
intel_swapbuffers.c
|
|
intelMakeCurrent is called before intelWindowMoved (in fact, it calls
it), so calculation of the correct vblank crtc has not happened yet.
Fix this by making a function that fixes up a set of vblank flags and
call if from both functions.
|
|
It's been broken and deprecated for a while, so it's time to die. This has the
wonderful benefit of cleaning up the code a fair amount; making it marginally
less twisty.
I'm unsure if the for loops in IntelWindowMoved are still needed.
|
|
This avoids issues with dereferencing stale cliprects around intel_draw_buffer
time. Additionally, take advantage of cliprects staying constant for FBOs and
DRI2, and emit cliprects in the batchbuffer instead of having to flush batch
each time they change.
|
|
The previous change gave us only two modes, one which looped over the batch
per cliprect (3d drawing) and one that didn't (state updeast).
However, we really want 4:
- Batch doesn't care about cliprects (state updates)
- Batch needs DRAWING_RECTANGLE looping per cliprect (3d drawing)
- Batch needs to be executed just once (region fills, copies, etc.)
- Batch already includes cliprect handling, and must be flushed by unlock time
(copybuffers, clears).
All callers should now be fixed to use one of these states for any batchbuffer
emits. Thanks to Keith Whitwell for pointing out the failure.
|
|
This was replaced in previous releases of xserver/dri/libGL by reporting the
damage to the frontbuffer so that the server and driver could handle it
appropriately.
|
|
|
