It doesn't really work, and trying to make multisampling work with onscreen
rendering is probably more trouble than it's worth, both for us and the
driver.
We'll probably want to make this default to TRUE at some point, but at least
for the moment there still seem to be some performance advantages to rendering
onscreen in most cases.
If CreateDevice is called with hFocusWindow belonging to another thread,
then any code that does SendMessage (or equivalent) to the window while
holding the main wined3d mutex causes a deadlock, because wined3d_wndproc
tries to acquire the same mutex for wndproc_table access.
In particular, if we'd unregister a window when the application replaced our
window proc, but still forwards to us, we'd create a loop when we register
the same window again later.
The basic rule is that you can't call anything that takes the user32 / gdi32
lock while under the GL (winex11) lock. As a consequence, you can't call
anything like context_acquire() or context_destroy() either.
While some performance hit from the extra flushes was expected and would be
acceptable, the performance hit can be over 50% on some configurations, which
clearly isn't acceptable. This patch introduces a "StrictDrawOrdering"
registry key for applications affected by this, until we have a more
structural solution.
We will need this for d3d10, where both dxgi and d3d10core are making wined3d
calls. Right now d3d8/d3d9 also use this to protect their own data, but
eventually we should push this down into wined3d itself and use something a
bit more fine-grained. There's no good reason that doing e.g. a vertex buffer
upload in some thread should block all of wined3d.
This adds code for handling fixed function fragment processing with the
GL_ATI_fragment_shader extension. This is a sort-of programmable
interface for fragment processing at the level of shader model 1.4 in
d3d. This code is of use on r200, r250 and r280 cards(radeon 8500 to
9200) which do not support GL_ARB_fragment_program, but support pixel
shader 1.4 on Windows. This code is somewhat a counterpart to the
existing fragment processing code using GL_NV_register_combiners and
GL_NV_texture_shader.
Henri Verbeet