[Bug 31442] Guild Wars 2 freezes on text input fields

[wine-bugs at winehq.org]

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

--- Comment #34 from voidcastr <voidcastr at gmail.com> 2012-10-07 09:00:49 CDT ---
Thanks for the clue, Henri!


+seh does not yield any output in the moment the freeze occurs or afterwards.


As far as I can tell from +tid, there are several threads doing the d3d/9 work,
with split tasks:
- "002f": deals with resource preparation (CreateTexture, surface operations,
...)
- "0038" (/"0044", see below): deals with the actual rendering (swapchain ops,
...)

So, this is basically how GW2's multithreaded (actually: dualthreaded)
rendering works... it's the first time we really get a notion of it, as far as
I can tell.

Unsurprisingly, "002f" does all the initialization work and writes hundreds of
thousands of lines to the log before "0038" is called for the first time.

Nevertheless there is a remarkable aspect about the second thread: It changes
after some time, i.e. the ID of the tread announcing "new frames" in the log
shifts from "0038" to "0044", with "0038" never being reused. Though, I don't
think that means much -- possibly the game just lets the original rendering
thread die and creates a new one (btw, the first thing both "0038" and "0044"
ever log, respectively, is d3d9:d3d9_device_GetBackBuffer). I'd interpret this
as being caused in the moment the launcher closes and the actual game gets
started... at least this kind of makes sense.

When starting the application with its -dx9single flag, there is only one
thread ("002f") doing all of the above work -- as expected.


Concerning +relay:
I analyzed the log a bit and created an annotated except of it (see
attachment). Thereby I concentrated on the last drawn frame and on the relay
output of the threads with the aforementioned TIDs.

However, I did not yet take into account that the problem could also have its
roots in a previous frame. This is because I hope that the reason for the
freeze can already be derived from what I've got so far (in the attachment).

The most suspicious thing I see is a call to "user32.SendMessageW(...)" by TID
0044 apparently never returning... at least this could explain the many
"KERNEL32.WaitForSingleObjectEx()" messages repeated over and over again by TID
002f, which might just be waiting for 0044. Btw, throughout the entire log (not
just the excerpt), there is only one other call of TID 0044 to
"user32.SendMessageW(...)" and that one's immediately returning (it can be seen
at the end of the 3rd block in the attachment).

But I don't know if that's critical or how to go on from here. The reason for
the freeze might also be something different in the log... or something I
totally missed so far.

This is once more a request for help.

-- 
Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email
Do not reply to this email, post in Bugzilla using the
above URL to reply.
------- You are receiving this mail because: -------
You are watching all bug changes.