The idea would be that you could have multiple send messages going on
if nothing depended on the previous message's results and you used a
different send message. The problem is that the later send requires
the VUE handle returned by the first send's allocate anyway.
The test for env['platform'] caused an exception since 'env' is not
defined at that point. Instead, determine the target platform by
scanning sys.argv[].
Before we would throttle in the flush callback prior to round-tripping
to the server to do copyregion or swapbuffer. Now, instead just note
that we need to throttle and do it in intel_prepare_render(), which
will be called after receiving the response from the server but before
we start rendering the next frame. Even if the server also throttles
us in swapbuffer, this just makes the throttling a no-op when we hit
intel_prepare_render(). With that we can drop the
using_dri2_swapbuffers hack and just always throttle.
Use front/back instead of cw/ccw throughout.
Also, use offset_point/line/fill instead of offset_cw/ccw.
Brings gallium representation of this state into line with its main
user, and also what turns out to be the most common hardware
representation.
This fixes a long-standing bias in the interface towards the
architecture of the software rasterizer.
This extension adds a new function which provides an alternative to
eglSwapBuffers. eglSwapBuffersRegionNOK accepts two new parameters in
addition to those in eglSwapBuffers. The new parameters consist of a
pointer to a list of 4-integer blocks defining rectangles (x, y,
width, height) and an integer specifying the number of rectangles in
the list.
When there is no user driver or any matching display drivers we fall
back to the default driver. This patch lets us have a list of default
drivers instead of just one. The drivers are loaded in turn and we
attempt to initialize the display. If it fails we unload the driver
and move on to the next one.
Compared to the display driver mechanism, this avoids loading a number
of drivers and then only using one. Also, we call Initialize to see
if the driver will work instead of relying on Probe. To know for sure
that a driver will work, Probe really have to do a full Initialize, so
we will just use Initialize directly.
