[Bug 28899] New: Arcanum: portion of the screen gets corrupted as the mouse pointer passes over it

http://bugs.winehq.org/show_bug.cgi?id=28899

Bug #: 28899
           Summary: Arcanum: portion of the screen gets corrupted as the
                    mouse pointer passes over it
           Product: Wine
           Version: 1.3.31
          Platform: x86
               URL: http://www.fileplanet.com/59649/50000/fileinfo/Arcanum
                    :-Of-Steamworks-&-Magick-Obscura-Demo
        OS/Version: Linux
            Status: NEW
          Keywords: download, regression
          Severity: minor
          Priority: P2
         Component: directx-d3d
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
                CC: [e-mail]
    Classification: Unclassified
   Regression SHA1: 2da4f87a7e7551f17cd650ef6d8596f595efc13b

There are screens in the game where moving the mouse pointer over a certain
part of the screen results in corrupted graphic:

- the confirmation dialog when exiting an active game
- the Skills tab in the character sheets page

Steps to reproduce the problem in the demo:
Install...launch. Start a new game by picking an existing character. There is a
short conversation at the beginning of the game; press 'c' after the
conversation ended. This will pop up the character sheets.
Move the mouse pointer to the right half of the screen, where the skills are
displayed --> you should see that that part of the screen where the skills are,
becomes corrupted as the mouse pointer passes through it.

The problem only occurs in hardware rendering mode. When starting the game by
'Arcanum.exe -no3d' (software renderer), the issue doesn't exist.

This is due to

2da4f87a7e7551f17cd650ef6d8596f595efc13b is the first bad commit
commit 2da4f87a7e7551f17cd650ef6d8596f595efc13b
Author: Henri Verbeet 
Date:   Mon Oct 24 20:45:42 2011 +0200

wined3d: Upload directly from the source surface in wined3d_surface_blt(),
if possible.

This avoids either loading sysmem surfaces into video memory (wasting GPU
    memory) and then doing a blit on the GPU, or downloading GPU surfaces to
    sysmem, doing a blit on the CPU, and likely uploading it again. This mostly
    matters for ddraw and d3d8 applications, d3d9 already has to go through
    wined3d_device_update_surface() to transfer data from sysmem surfaces to
GPU
    surfaces.

:040000 040000 de2e083e774b6605b4330430830583b12fb510f4
16fd239dcdf7e70872e0ff77f91e66b135638d2b M    dlls

The reverted patch fixed the problem.

Terminal output doesn't reveal anything suspicious, it is the same as before
commit 2da4f87a7e7551f17cd650ef6d8596f595efc13b.

Fedora 15 x86
Nvidia 250 / driver 280.13