[PATCH] wined3d: Use GL_LINEAR for unsupported filter types.

[Józef Kucia]

Linear filtering is a much more appropriate fallback for more advanced
filtering types.

Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41929
Signed-off-by: Józef Kucia 
---
 dlls/wined3d/surface.c | 10 +++++-----
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/dlls/wined3d/surface.c b/dlls/wined3d/surface.c
index 85f94899cd60..3441f018f417 100644
--- a/dlls/wined3d/surface.c
+++ b/dlls/wined3d/surface.c
@@ -169,16 +169,16 @@ static void texture2d_blt_fbo(const struct wined3d_device *device, struct wined3

switch (filter)
     {
-        case WINED3D_TEXF_LINEAR:
-            gl_filter = GL_LINEAR;
+        case WINED3D_TEXF_NONE:
+        case WINED3D_TEXF_POINT:
+            gl_filter = GL_NEAREST;
             break;

default:
             FIXME("Unsupported filter mode %s (%#x).\n", debug_d3dtexturefiltertype(filter), filter);
             /* fall through */
-        case WINED3D_TEXF_NONE:
-        case WINED3D_TEXF_POINT:
-            gl_filter = GL_NEAREST;
+        case WINED3D_TEXF_LINEAR:
+            gl_filter = GL_LINEAR;
             break;
     }

[Fabian Maurer]

> Linear filtering is a much more appropriate fallback for more advanced
> filtering types.
>
> Wine-Bug: https://bugs.winehq.org/show_bug.cgi?id=41929

Hello Józef,

as noted in bug 46246, the apitrace made with WINE does produce a broken 
output that can't even be replayed properly on windows. While your patch is a 
nice fix, isn't there an underlying issue we should also fix?

Regards,
Fabian Maurer

[Henri Verbeet]

On Thu, 6 Dec 2018 at 18:08, Józef Kucia  wrote:
> Linear filtering is a much more appropriate fallback for more advanced
> filtering types.

Sure, but I think the question is what should happen with invalid
filter types. The documentation suggests only "NONE", "POINT" and
"LINEAR" are valid for StretchRect().

[Fabian Maurer]

> Sure, but I think the question is what should happen with invalid
> filter types. The documentation suggests only "NONE", "POINT" and
> "LINEAR" are valid for StretchRect().

But then again, even windows drivers don't seem to display it properly. 
Makes me wonder why the invalid drawing call happens in the first place, 
when it doesn't happen on windows. Meaning something deeper is 
wrong, no?

Regards,
Fabian Maurer