http://bugs.winehq.org/show_bug.cgi?id=31029
Bug #: 31029 Summary: TrackMania United Forever: Images not show properly (regression) Product: Wine Version: 1.5.7 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: windowscodecs AssignedTo: wine-bugs@winehq.org ReportedBy: ralfjung-e@gmx.de CC: dmitry@baikal.ru Classification: Unclassified Regression SHA1: fd31112ab0a0528fd9be99e0afd49dd98f523d2f
Some images in TrackMania United Forever are not displayed properly anymore in wine 1.5.7: Only the first few lines are shown, the rest is just grey. This affects the flags shown all over the place as well as the preview images of tracks. I will attach a screenshot. This used to work fine in 1.5.4.
I did a bisect (which was a bit troublesome as TrackMania crashes with wine 1.5.5 and 1.5.6, but I think I got it right by applying the simple work-around patch from that crash [1]). This is the result:
fd31112ab0a0528fd9be99e0afd49dd98f523d2f is the first bad commit commit fd31112ab0a0528fd9be99e0afd49dd98f523d2f Author: Dmitry Timoshkov dmitry@baikal.ru Date: Mon May 28 18:41:27 2012 +0900
windowscodecs: Add support for preferred vendor guid in CreateDecoderFromStream.
:040000 040000 2b792fb45444dbb1f7569a0ca8300b9c6b4f38c5 dddf1b044911cbcd8824f28029db1e1a5429e3c9 M dlls
I verified that going to the commit before this one indeed fixes the problem. A log file of starting TrackMania with a broken wine is attached. A free version of TrackMania is available at http://trackmaniaforever.com/
[1] http://bugs.winehq.org/show_bug.cgi?id=30885
http://bugs.winehq.org/show_bug.cgi?id=31029
Ralf Jung ralfjung-e@gmx.de changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression Summary|TrackMania United Forever: |TrackMania United Forever: |Images not show properly |Images not show properly |(regression) |
http://bugs.winehq.org/show_bug.cgi?id=31029
--- Comment #1 from Ralf Jung ralfjung-e@gmx.de 2012-06-26 11:40:53 CDT --- Created attachment 40729 --> http://bugs.winehq.org/attachment.cgi?id=40729 A logfile of TrackMania not showing the images properly
http://bugs.winehq.org/show_bug.cgi?id=31029
--- Comment #2 from Ralf Jung ralfjung-e@gmx.de 2012-06-26 11:43:17 CDT --- Created attachment 40730 --> http://bugs.winehq.org/attachment.cgi?id=40730 A screenshot of TrackMania demonstrating the problem
http://bugs.winehq.org/show_bug.cgi?id=31029
--- Comment #3 from Vincent Povirk madewokherd@gmail.com 2012-06-26 13:58:15 CDT --- Created attachment 40735 --> http://bugs.winehq.org/attachment.cgi?id=40735 possible fix
Does this patch help?
http://bugs.winehq.org/show_bug.cgi?id=31029
--- Comment #4 from Ralf Jung ralfjung-e@gmx.de 2012-06-26 15:25:21 CDT --- Wow, that was quick! I applied it on top of wine-1.5.7, and now the artefacts are gone :)
http://bugs.winehq.org/show_bug.cgi?id=31029
--- Comment #5 from Dmitry Timoshkov dmitry@baikal.ru 2012-06-27 01:30:09 CDT --- (In reply to comment #3)
Created attachment 40735 [details] possible fix
Does this patch help?
The problem with this approach is when there are several decoders from the same vendor (one of which understands the stream format and another one which doesn't). Probably either a decoder needs to rewind the stream after initialization is done, or CreateDecoderFromStream needs to do that before calling a decoder.
http://bugs.winehq.org/show_bug.cgi?id=31029
--- Comment #6 from Vincent Povirk madewokherd@gmail.com 2012-06-27 10:32:38 CDT --- What's the problem when there are multiple encoders that match the pattern? If the file format isn't supported, Initialize will fail, and seeking the stream afterwards won't break an existing decoder.
It doesn't matter what is the stream position when Initialize is called. What matters is that the position is left alone between calls into the decoder after it is initialized.
http://bugs.winehq.org/show_bug.cgi?id=31029
--- Comment #7 from Dmitry Timoshkov dmitry@baikal.ru 2012-06-27 10:40:11 CDT --- (In reply to comment #6)
What's the problem when there are multiple encoders that match the pattern? If the file format isn't supported, Initialize will fail, and seeking the stream afterwards won't break an existing decoder.
It doesn't matter what is the stream position when Initialize is called. What matters is that the position is left alone between calls into the decoder after it is initialized.
So, what happens when a decoder from vendor1 is found and initialized, but then a decoder from vendor2 is found and vendor2 is the preferred one?
http://bugs.winehq.org/show_bug.cgi?id=31029
--- Comment #8 from Dmitry Timoshkov dmitry@baikal.ru 2012-06-27 10:43:37 CDT --- (In reply to comment #7)
So, what happens when a decoder from vendor1 is found and initialized, but then a decoder from vendor2 is found and vendor2 is the preferred one?
Or rather, decoder1 from vendor1 is found, reports that it supports this stream format, and gets initialized, then decoder2 from preferred vendor2 is found, but it reports that it can't handle the stream format?
http://bugs.winehq.org/show_bug.cgi?id=31029
--- Comment #9 from Vincent Povirk madewokherd@gmail.com 2012-06-27 10:50:45 CDT --- If a preferred vendor is specified, the loop runs first trying only decoders from the preferred vendor. If that fails, the loop runs again trying all decoders. The first decoder to successfully initialize is immediately returned.
The important point here is that we don't seek the stream after we've used it to initialize a decoder, or if we do we don't go on to try to use that decoder. That pretty much means the last thing we do has to be an Initialize call.
http://bugs.winehq.org/show_bug.cgi?id=31029
--- Comment #10 from Dmitry Timoshkov dmitry@baikal.ru 2012-06-27 11:19:02 CDT --- (In reply to comment #9)
If a preferred vendor is specified, the loop runs first trying only decoders from the preferred vendor. If that fails, the loop runs again trying all decoders. The first decoder to successfully initialize is immediately returned.
Then I'd factor out the decoder search into a separate helper to avoid a needless goto:
decoder = find_decoder(preferred_vendor, stream); if (!decoder) decoder = find_decoder(NULL, stream); return decoder;
http://bugs.winehq.org/show_bug.cgi?id=31029
--- Comment #11 from Dmitry Timoshkov dmitry@baikal.ru 2012-06-27 11:20:52 CDT --- Let it be: decoder = NULL; if (preferred_vendor) decoder = find_decoder(preferred_vendor, stream); if (!decoder) decoder = find_decoder(NULL, stream); return decoder;
http://bugs.winehq.org/show_bug.cgi?id=31029
--- Comment #12 from Dmitry Timoshkov dmitry@baikal.ru 2012-06-28 01:11:34 CDT --- (In reply to comment #11)
Let it be: decoder = NULL; if (preferred_vendor) decoder = find_decoder(preferred_vendor, stream); if (!decoder) decoder = find_decoder(NULL, stream); return decoder;
http://www.winehq.org/pipermail/wine-patches/2012-June/115658.html implements this.
http://bugs.winehq.org/show_bug.cgi?id=31029
Dmitry Timoshkov dmitry@baikal.ru changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |39f80e56fb15858e1d057facae5 | |6fa7f8527bd80 Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #13 from Dmitry Timoshkov dmitry@baikal.ru 2012-06-29 07:52:29 CDT --- Should be fixed now.
http://bugs.winehq.org/show_bug.cgi?id=31029
--- Comment #14 from Ralf Jung ralfjung-e@gmx.de 2012-06-29 14:02:59 CDT --- (In reply to comment #13)
Should be fixed now.
Yes it is, thanks a lot!
http://bugs.winehq.org/show_bug.cgi?id=31029
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #15 from Alexandre Julliard julliard@winehq.org 2012-07-03 14:15:45 CDT --- Closing bugs fixed in 1.5.8.
-
wine-bugs＠winehq.org