Make sure that we bind the right buffer (draw or read) when rebinding
the window framebuffer (the api doesn't allow binding different draw and
read buffers at the same time, but the default window framebuffer is basically
2 fb objects, one for read, one for write, which can be different). Pass both
of these two down the driver api (no driver uses this right now).
remove some already ifdefed out, no longer functional and used code.
Don't do our own scissor clipping in the pixeldraw/copy paths,
as meas already does that for us...
Make sure the relevant fields in window fbs get updated at appropriate time
(those are NOT the same as fbos!!!), and fix up related code accordingly.
This is a bit ugly, but there's a reason the issues section in EXT_fbo is
a couple hundred pages long...
Hopefully correct now.
manywin got broken (when intelPageflip got no longer called).
Make sure that intelFlush is getting called when a context gets unbound,
to handle later swapbuffer calls on that context's drawable better.
Related, fix non-current cliprects getting used on unbound drawables.
Construct the vertprog instruction in the 4 DWORD parts...
DWORD 0: Opcode and Output.
DWORD 1: First Argument.
DWORD 2: Second Argument.
DWORD 3: Third Argument.
Allow the opcode translation functions to generate more than one instruction;
useful for when an instruction must be emulated. FLR, XPD, etc.
Make sure that we bind the right buffer (draw or read) when rebinding
the window framebuffer (the api doesn't allow binding different draw and
read buffers at the same time, but the default window framebuffer is basically
2 fb objects, one for read, one for write, which can be different). Pass both
of these two down the driver api (no driver uses this right now).
the framebuffer objects attached to drawables can have invalidate state
associated with them, since for the window framebuffer this is per-context
state and not per-fbo state. Since drivers rely on that information
(otherwise would need to check if currently the window-framebuffer is
bound in a lot of places) fix it up in _mesa_make_current (ugly).
(Brought over from i915tex_privbuffers, where it fixes xdemos/wincopy
when switching to front buffer rendering.)
pack->alignment doesn't matter usually if the image is sufficiently aligned
anyway. Speeds up some tests/readrate cases by a factor of 100 (since
the pack->alignment default which noone ever bothers to change is 4).
