[Bug 31914] New: Recorded frames are in reversed order

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

Bug #: 31914
           Summary: Recorded frames are in reversed order
           Product: Wine
           Version: 1.5.10
          Platform: x86-64
        OS/Version: Linux
            Status: UNCONFIRMED
          Severity: normal
          Priority: P2
         Component: -unknown
        AssignedTo: [e-mail]
        ReportedBy: [e-mail]
    Classification: Unclassified

I'm using glc-capture to record apllications and games.

https://github.com/nullkey/glc/wiki

Up to WINE-1.5.9 it was working OK, making a picture like this:

http://www.twitch.tv/nuclear_power_plant/b/334759327

Sine the update to WINE-1.5.10, the recorded frames are in reversed order,
making the first pixel to the last pixel.
It's now looking like this:

http://www.twitch.tv/nuclear_power_plant/b/334768276

Also when starting recording the console got flooded with this error:

err:d3d:context_bind_fbo >>>>>>>>>>>>>>>>> GL_INVALID_ENUM (0x500) from
glBindFramebuffer() @
/var/tmp/portage/app-emulation/wine-1.5.10/work/wine-1.5.14/dlls/wined3d/context.c
/ 84

It's reproduce able with WINE-1.5.10 to 1.5.14.

[Bug 31914] Recorded frames are in reversed order

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

--- Comment #1 from Henri Verbeet  2012-10-08 07:40:48 CDT ---
Flash isn't really helping if you want me to take a look, but from your
description this sounds like something that would be affected by enabling
"AlwaysOffscreen" by default. You should probably try disabling that and see if
it makes it any better. (See also http://wiki.winehq.org/UsefulRegistryKeys.)

I don't think this is really a Wine bug though. If this only happens while
using glc-capture, the most likely explanation is that glc-capture doesn't
properly restore some GL state it modifies, or doesn't take some GL extension
Wine uses into account.

[Bug 31914] Recorded frames are in reversed order

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

--- Comment #2 from Ralf  2012-10-08 08:08:49 CDT ---
Screenshots:

http://imgur.com/a/hjzgo

I just tried AlwaysOffscreen disabled, but i doesn't change anything.

If it's not a WINE bug, why has it worked before 1.5.10? I've used glc with a
lot of different native games and never seen such a effect.

[Bug 31914] Recorded frames are in reversed order

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

--- Comment #3 from Henri Verbeet  2012-10-08 08:31:17 CDT ---
(In reply to comment #2)
> If it's not a WINE bug, why has it worked before 1.5.10?

Probably because something changed in the way Wine renders things, and glc
can't handle the new situation very well. The main change like that between
1.5.9 and 1.5.10 was changing the AlwaysOffscreen default, but there have been
changes to e.g. winex11.drv around that time as well. If you want to narrow
down the specific commit that broke it, do a bisect between 1.5.9 and 1.5.10.

[Bug 31914] Recorded frames are in reversed order

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

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |regression

--- Comment #4 from Austin English  2012-10-09 13:12:20 CDT ---
Please run a regression test:
http://wiki.winehq.org/RegressionTesting

[Bug 31914] Recorded frames are in reversed order

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

Henri Verbeet  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|regression                  |

--- Comment #5 from Henri Verbeet  2012-10-09 13:18:52 CDT ---
That's not what the regression keyword is for. Strictly speaking this is almost
certainly INVALID, but I think it's useful to figure out what exactly is
happening.

[Bug 31914] Recorded frames are in reversed order

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

--- Comment #6 from Austin English  2012-10-09 13:54:23 CDT ---
(In reply to comment #5)
> That's not what the regression keyword is for. Strictly speaking this is almost
> certainly INVALID, but I think it's useful to figure out what exactly is
> happening.

Until it's certainly invalid/upstream, I don't think it hurts that much to have
the regression keyword, but I'm not concerned enough to start a discussion
about it.

It should be UPSTREAM, however, not invalid.

[Bug 31914] Recorded frames are in reversed order

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

--- Comment #7 from Henri Verbeet  2012-10-09 15:58:49 CDT ---
Created attachment 42055
  --> http://bugs.winehq.org/attachment.cgi?id=42055
glc patch

Glc doesn't take the current framebuffer binding into account, it's mildly
surprising this works for anything at all. Applying the attached patch to glc
should fix it, although it's not quite a proper patch. For example, it should
check if FBOs are available before calling FBO functions, and the current
framebuffer binding isn't the only GL state that can break glc. At the very
least there's also various GL_PACK_* state and the pixel pack buffer binding to
take into account. I'll leave those issues as an exercise for the glc
maintainers.

[Bug 31914] Recorded frames are in reversed order

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

Henri Verbeet  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
         Resolution|                            |UPSTREAM

--- Comment #8 from Henri Verbeet  2012-10-09 16:00:33 CDT ---
Resolving UPSTREAM.

[Bug 31914] Recorded frames are in reversed order

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

--- Comment #9 from Ralf  2012-10-10 13:14:45 CDT ---
(In reply to comment #7)
> Created attachment 42055 [details]
> glc patch
>
> Glc doesn't take the current framebuffer binding into account, it's mildly
> surprising this works for anything at all. Applying the attached patch to glc
> should fix it, although it's not quite a proper patch. For example, it should
> check if FBOs are available before calling FBO functions, and the current
> framebuffer binding isn't the only GL state that can break glc. At the very
> least there's also various GL_PACK_* state and the pixel pack buffer binding to
> take into account. I'll leave those issues as an exercise for the glc
> maintainers.

Thank you for the patch.

[Bug 31914] Recorded frames are in reversed order

https://bugs.winehq.org/show_bug.cgi?id=31914

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |CLOSED

--- Comment #10 from Austin English  ---
Closing.

[Bug 31914] Recorded frames are in reversed order

https://bugs.winehq.org/show_bug.cgi?id=31914

Austin English  changed:

What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|CLOSED                      |RESOLVED

--- Comment #11 from Austin English  ---
This was inadvertently caught up in my unclosed bugs filter. NOTOURBUG should
only be closed when fixed upstream.

Setting back to RESOLVED NOTOURBUG.

Sorry for the spam.