https://bugs.winehq.org/show_bug.cgi?id=35718
--- Comment #112 from Alex Henrie alexhenrie24@gmail.com --- (In reply to Ken Thomases from comment #111)
The pixel format dictates the fbconfig. The fbconfig dictates the visual. The visual is a property of the window set at creation.
OK, thanks for the answer. I read the wine-devel discussion from May 2014 as well, and it sounds like we need more tests to determine whether native d3d supports having multiples surfaces per window. If it does, then we can add multiple surface support because some applications might need it anyway, then capitalize on that feature to give user32 and d3d separate surfaces to avoid context switching. If native d3d does not permit multiple surfaces, then maybe we can cache the old X window in the X11 driver and just move it to the front if the previous pixel format is needed again.
Unfortunately, I do not know how to write the tests we need for this. I might be able to come up with something eventually, but it would be better if someone familiar with d3d tackled this.
Sorry if these seem like stupid questions...this bug has attracted my interest not because I particularly like messing with d3d code, but rather because the problem here is so severe and there are a large number of applications affected.