August 2007 - Wine-Devel - list.winehq.org

Re: [5/5] WineD3D: Fake occlusion queries if the wrong context is active

by Stefan Dösinger

Am Mittwoch, 22. August 2007 11:44 schrieb H. Verbeet: > On 22/08/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > Can't we wait for the other thread & context to become active? Afaik > occlusion queries are allowed to block on Windows. Queries do not block, but they can return that no data is available, and we could do that here. Unfortunately many games seem to do something like while(!dataAvailable(query));, which would cause problems in that case.

Aug. 22, 2007

Re: gphoto2.ds: remove camera import UI

by Alexandre Julliard

"Dan Kegel" <dank(a)kegel.com> writes: > Rather than remove all that nearly-working code, > how about keeping it, adding the winecfg option, > and making it default to off for now? That option is much too specific to go in winecfg, it's something most users don't care about. What you could do though is have a "don't show this dialog again" option in the dialog itself. -- Alexandre Julliard julliard(a)winehq.org

Aug. 22, 2007

Using pthread_create within Wine

by Phil Lodwick

Greetings, I have a proprietary library that has both Windows and Linux ports. The Windows DLL has problems running on Wine, so I have created a builtin version of this DLL in Wine. This has worked fine, except for one function that basically creates a new thread and fires back events to the calling Window application. I believe I have traced this down to the Linux version of the library creating the new thread with pthread_create. Windows.exe Call_dll_to_spawn_thread_and_register_callback(MyCallbackfunc); Windows DLL implemented in wine: void * NewThread(void *p) { MyParams *params = (MyParams *)p; for (i = 0; i < 500000; i++) p->Callback(); } void Call_dll_to_spawn_thread_and_register_callback(void (*callback)()) { MyParams *params = (MyParams *)malloc(sizeof(MyParams)); params->Callback = callback; pthread_create(&MyThread, NULL, NewThread, (void *)params); } If instead of using pthread_create I use CreateThread, I never have a problem. I notice no other wine DLLs are using pthread_create and I have seen hints that this might not work. If so, how do I use the Linux library. (Call_dll_to_spawn_thread_and_register_callback is just simulating what the Linux library would do) Do I create a separate thread using CreateThread to communicate back to the Window application, so that Call_dll_to_spawn_thread_and_register_callback effectively creates two threads, one using CreateThread (Wine DLL), one using pthread_create (Linux Library) and then do synchronization between the two? Any help, suggestion, ideas, questions would be greatly appreciated. Phil

Aug. 22, 2007

Re: Compositing GL

by Roderick Colenbrander

On Wednesday 22 August 2007 03:36, Chris Robinson wrote: > Over the past several days, I've been working with some people in > #winehackers on a way to help solve the problems Wine faces with OpenGL.. > namely the lack of useable onscreen pixel formats and broken child windown > rendering. Here's a patch for your perusal in hopes to generate feedback. > > What this does is, it renders GL to an offscreen buffer the size of the > window it's rendering to, first trying a redirected window (if you have the > Xcomposite extension), then falling back to GLXPixmaps (which may be > slower, especially if you don't have AIGLX). The offscreen buffer is then > copied to the window it should be displaying on using X, acting in a manner > nearly identical to how Vista composites OpenGL (as described here: > http://www.opengl.org/pipeline/article/vol003_7/ ). I'll add some more info here as for sure people will ask about it. In short during the Winex11.drv window management rewrite Wine lost dedicated X11 windows for Direct3D/OpenGL (before everything had an X11 child window). This has broken windowed OpenGL for years. Suggested solutions at the time were to use glxpixmap rendering. At the time that was only accelerated on Nvidia hardware. More about this below. The other solution was the use of glScissor/glViewport to limit GL rendering to the place on the gui were GL was needed. This worked a bit on some drivers but there were SwapBuffers related issues, second it would also have clipping issues and the scissors/viewport override caused issues for pbuffers/fbos. At the beginning of this year we looked at several methods of 'X11 child window injection' for GL. A few methods were tried. They had the same clipping issues as the scissors path but for the rest it worked. While it fixed most drawing issues, it got X event issues back. The win32 parent window would receive X expose events and in the end those would confuse programs. The Xorg guys suggested that those events would get away when we would use automatic redirection using Composite. Even then the events are there though they are harmless but they still cause the same troubles. The current solution takes advantage of (upcoming) changes in Xorg drivers. Thanks to Compiz and friends, developers are adding AIGLX, hw accelerated glxpixmap rendering and redirected gl rendering support to their display drivers. Right now all this stuff is still limited to Nvidia but other drivers are getting support. At least the intel driver and r300 will support it in Xorg 7.4 (you can get a preview of it in the TTM branches of both drivers, in case of Intel that's i915tex). This solution is the best way to go. Luckily Microsoft made similar changes in Vista. > There is a speed hit, however. The DX9 swap chains demo, which gets about > 280 FPS for me normally, gets about 80 to 90 FPS with the compositing > method. It seems to be a ceiling though, as other more GPU intense apps > have no extra noticeable slow down. Still, as an optimization, it can > render directly to the window when it's being used on the whole window and > the selected pixel format matches the current visual (this bit is disabled > in the patch since it's for testing offscreen rendering, but it's simple to > re-enable). Demos like DX9 swap chains / 3DMark are heavily GPU limited e.g. they push the card to its limits. Normal programs are most of the time cpu limited. They are GPU limited ofcourse if you run the program on a system which the program considers lowend. Regards Roderick Colenbrander

Aug. 22, 2007

Re: Changing Bugzilla settings so a single person can't confirm bugs by "popular vote"

by Kai Blin

On Wednesday 22 August 2007 16:21:09 Jeremy Newman wrote: > I've updated the Wine product under bugzilla to the following settings: > > -- > Maximum votes per person: 20 > > Maximum votes a person > can put on a single bug: 1 > > Confirmation threshold: 2 > -- > > The setting I changed was the "Maximum votes a person can put on a > single bug". It was set to: 10000. No idea why, it's possible that was > the default back when we set it originally. I've changed it to 1. This > change also removed all the duplicate votes. Great, thanks. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developer http://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton.

Aug. 22, 2007

Re: Changing Bugzilla settings so a single person can't confirm bugs by "popular vote"

by Jeremy Newman

I've updated the Wine product under bugzilla to the following settings: -- Maximum votes per person: 20 Maximum votes a person can put on a single bug: 1 Confirmation threshold: 2 -- The setting I changed was the "Maximum votes a person can put on a single bug". It was set to: 10000. No idea why, it's possible that was the default back when we set it originally. I've changed it to 1. This change also removed all the duplicate votes. On Wed, 2007-08-22 at 08:48 +0200, Kai Blin wrote: > Hi folks, > > While working on bug 9405, I realized that all 20 votes on that bug were made > by the reporter. I think that's pretty lame, so I've asked the bugzilla folks > if there's a way to fix that. They said that the settings should be obvious > when editing the product. Can we please fix that? > > Cheers, > Kai >

Aug. 22, 2007

re: gphoto2.ds: remove camera import UI

by Dan Kegel

Lei wrote: > ... > The alternative is to keep the GUI. It is useful in the case where > there's many pictures on the camera, and the user just want to import > a few of them. We would need to: > > - modify the GUI to fix the crash > - do not automatically generate download thumbnails, but rather, > present the user with the options to download thumbnails, or just go > ahead and import all pictures > - perhaps add a winecfg option to turn off the GUI Rather than remove all that nearly-working code, how about keeping it, adding the winecfg option, and making it default to off for now? (i.e. leave fixing the bug for later.) That should be a smaller, less violent patch... - Dan -- Wine for Windows ISVs: http://kegel.com/wine/isv

Aug. 22, 2007

Re: [1/5] WineD3D: Fall back to drawStridedSlow if fog coords are used

by Ivan Gyurdiev

Stefan Dösinger wrote: > Up to now we've been lucky that all the games requireing manual fog coords > haven't used vertex buffers, thus we always went through drawStridedSlow. > Make sure that the fog also works with vertexbuffers > > As for the rejected patches from yesterday, I've moved them back to the bottom > of the queue when I fixed them, so I will resend them later. > > ------------------------------------------------------------------------ > > This patch is probably fine, but it makes me look into the surrounding code [ software blending, changing the strided data ], which is still incredibly misleading. That should go into its own function, with the FIXVBO macro removed (since all such macros are evil, without exception), and a big comment should be added that named access to the strided data is only valid in the fixed function pipeline and will not work in the shader pipeline. Maybe it makes sense to use two different structures to make this clearer - not sure.

Aug. 22, 2007

Re: advapi32: Add more tests for CryptVerifySignatureW, and correct its parameter checking

by Alexandre Julliard

"Juan Lang" <juan.lang(a)gmail.com> writes: > From 53a45e7e2adf3b8591f2c07501e7b37538d95657 Mon Sep 17 00:00:00 2001 > From: Juan Lang <juan.lang(a)gmail.com> > Date: Tue, 21 Aug 2007 15:10:35 -0700 > Subject: [PATCH] Add more tests for CryptVerifySignatureW, and correct its parameter checking This breaks the tests: ../../../tools/runtest -q -P wine -M rsaenh.dll -T ../../.. -p rsaenh_test.exe.so rsaenh.c && touch rsaenh.ok rsaenh.c:1081: Test failed: Expected ERROR_INVALID_PARAMETER error, got 80090006 make: *** [rsaenh.ok] Error 1 Also the indentation is messed up, please fix your tab size. -- Alexandre Julliard julliard(a)winehq.org

Aug. 22, 2007

Re: [5/5] WineD3D: Fake occlusion queries if the wrong context is active

by H. Verbeet

On 22/08/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > Can't we wait for the other thread & context to become active? Afaik occlusion queries are allowed to block on Windows.

Aug. 22, 2007