Lionel Ulmer wrote:
You can see that this topic was already debated in the following threads :
http://www.winehq.com/hypermail/wine-devel/2002/06/0396.html
And even earlier here :
http://www.winehq.com/hypermail/wine-devel/2002/01/0392.html
Thanks, I probably should have searched the archive first before jumping in and posting. Had a read of the previous threads and I'm still trying to understand exactly what's wrong with the fix, here are some questions:
-> if gdi_display gets replaced with the thread specific display, won't this cause more problems than it fixes? Would a windows program not expect to be able to switch on directX in one thread then operate on the raw display from any thread? Using the thread specific display would require the thread which switched DGA2 on to perform all operations because most DGA2 calls throw errors if a display is not in DGA2 mode and only one display can be in this mode at any one time.
-> In a multi-threaded program, does it matter which WaitForMultipleObjects is used to collect the events? The event gets dispatched to the wineserver with the DGA window's hWnd attached in the same way as it would if 'emulated' direct access were used (i.e. drawing with normal X11 calls). This then sends the event on to the windows program. If this is a problem then wouldn't it also affect non-DGA2 modes and therefore be a separate problem? It's been ages since I did any windows programming (win 3.1), what would a multi-threaded windows app expect to happen if it starts multiple threads and runs more than one event loop?
Perhaps a better fix might be to have a thread 'own' the gdi_display if it switches DGA2 mode on. The X11drv_thread_data structure for each thread could get a new 'gdi_display' field which would default to NULL. This could get set to the global gdi_display field for the thread which switches on DGA2 and process_events could be changed to poll data->gdi_display in addition to data->display if this was non-null. I think this would produce input event behaviour identical to the 'emulated' DGA2 mode since DGA2 events would only be handled when the thread which entered DGA2 mode was polled for events.
A.