The condition that triggers the bug is this: we use a texture for rendering
heap-based images into accelerated surfaces. This surface (at tile) is
256x256, so if the image is too large to fit it is tiled.
The texture is created with DYNAMIC use flag. This means that we can
use DISCARD when locking the contents of the surface, letting the
runtime know that we don't care about previous contents of the surface.
The current code only locks with the discard flag if the loaded bits
fill whole image. This is probably due to misinterpretation of the
documentation for DISCARD/DYNAMIC, which says that you could only
use DISCARD if you're replacing every single texel in the texture,
since the contents of the texture locked with DISCARD are not guaranteed
to be the same from lock to another lock.
What they meant to say is "every single texel that you care about",
so if we only care about and access 10x10 part of 256x256 texture
we could still use the DISCARD flag when locking.
Anyway, I don't believe our current use is illegal - we don't *have* to
use the DISCARD flag with DYNAMIC textures, it's just recommended.
The Microsoft reference rasterizer works just fine, and so were nvidia drivers
up to the latest update.
The work around for this apparent driver bug is to always lock with the DISCARD
flag - which is the better performing option anyway.
We'll still pursue Nvidia to address this issue or explain what's
wrong with our current usage, and why the reference rasterizer doesn't