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

RE: Using pthread_create within Wine

by Phil Lodwick

> There was a problem like this with the CoreAudio library on macos, but I am > not sure about the details. > Is there any reason why you cannot use CreateThread? I can't use CreateThread because the pthread_create is in a Linux library I am calling. My initial test of creating two threads, one that is Win32-aware and then synchronizing between the two of them appears to work. Does anybody know why this might be a bad idea? Phil

Aug. 22, 2007

gphoto2.ds: remove camera import UI

by Luke Bratch

--- Alexandre Julliard <julliard at winehq.org> wrote: > > 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. How about a registry key? ___________________________________________________________ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html

Aug. 22, 2007

Re: Compositing GL

by H. Verbeet

On 22/08/07, Roderick Colenbrander <thunderbird2k(a)gmx.net> wrote: > There are two distinct cases. You have programs that use a toplevel for GL/D3D > rendering (in general this is the case for games). Further you > have 'windowed' programs e.g. programs that mix GL/D3D with a GDI gui. The > use of GL Composition is limited to these 'windowed' programs. So the > performance hit is also only limited to those programs. In my case the hit in > the dx9 swap chains and the dx8 dolphin demo is about 1/3th but still there's > a hit. As I said before in cpu limited cases I don't expect problems. > I thought it was required in both cases to get additional pixel formats?

Aug. 22, 2007

Re: include: add some definitions to winioctl.h (patch)

by Robert Shearman

Mikolaj Zalewski wrote: > -#define IOCTL_STORAGE_GET_MEDIA_TYPES CTL_CODE(IOCTL_STORAGE_BASE, 0x0300, METHOD_BUFFERED, FILE_ANY_ACCESS) > -#define IOCTL_STORAGE_GET_MEDIA_TYPES_EX CTL_CODE(IOCTL_STORAGE_BASE, 0x0301, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_GET_MEDIA_TYPES CTL_CODE(IOCTL_STORAGE_BASE, 0x0300, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_GET_MEDIA_TYPES_EX CTL_CODE(IOCTL_STORAGE_BASE, 0x0301, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_GET_MEDIA_SERIAL_NUMBER CTL_CODE(IOCTL_STORAGE_BASE, 0x0305, METHOD_BUFFERED, FILE_ANY_ACCESS) > The above should be 0x0304 instead of 0x0305. > +#define IOCTL_STORAGE_GET_HOTPLUG_INFO CTL_CODE(IOCTL_STORAGE_BASE, 0x0305, METHOD_BUFFERED, FILE_ANY_ACCESS) > +#define IOCTL_STORAGE_SET_HOTPLUG_INFO CTL_CODE(IOCTL_STORAGE_BASE, 0x0306, METHOD_BUFFERED, FILE_READ_ACCESS) > -- Rob Shearman

Aug. 22, 2007

Re: Compositing GL

by Roderick Colenbrander

On Wednesday 22 August 2007 20:57, H. Verbeet wrote: > > This solution is the best way to go. Luckily Microsoft made similar > > changes in Vista. > > Conceptually its probably correct, but I think the speed hit is pretty > large, and it's not like we've got a lot of performance to spare. As > for the Vista comparison... Vista isn't exactly well known for it's > OpenGL performance either. What is the performance hit for something > like the CSS stress test? That should be a bit more representative > than dx9 swapchains. > > I'm certainly not saying it's not a good idea, but I do think the > performance hit shouldn't be quite as noticeable. There are two distinct cases. You have programs that use a toplevel for GL/D3D rendering (in general this is the case for games). Further you have 'windowed' programs e.g. programs that mix GL/D3D with a GDI gui. The use of GL Composition is limited to these 'windowed' programs. So the performance hit is also only limited to those programs. In my case the hit in the dx9 swap chains and the dx8 dolphin demo is about 1/3th but still there's a hit. As I said before in cpu limited cases I don't expect problems. Roderick

Aug. 22, 2007

Re: Using pthread_create within Wine

by Stefan Dösinger

Hi, > 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) There are some problems if Linux libraries create a thread behind the calling application in Wine. I do not know what the problem is precicely, but I think Win32 code can be confused if it is called from a thread that doesn't have the Win32 thread structures that should belong to it. If the library creates a thread, and this thread calls back into the Windows app's code, the code running in the windows application can't find the current thread ID, simply because the Win32 thread information is not there. There was a problem like this with the CoreAudio library on macos, but I am not sure about the details. Is there any reason why you cannot use CreateThread?

Aug. 22, 2007

Re: [2/5] WineD3D: Refuse to lock locked surfaces

by H. Verbeet

On 22/08/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > LockRect() and LockRect(), then GetDC(). But since UnlockRect doesn't take a > rectangle parameter, the runtime wouldn't know which rectangle is now locked > or unlocked, so it is unlikely that two rectangles can be locked > concurrently. Makes sense.

Aug. 22, 2007

Re: Compositing GL

by H. Verbeet

> This solution is the best way to go. Luckily Microsoft made similar changes in > Vista. > Conceptually its probably correct, but I think the speed hit is pretty large, and it's not like we've got a lot of performance to spare. As for the Vista comparison... Vista isn't exactly well known for it's OpenGL performance either. What is the performance hit for something like the CSS stress test? That should be a bit more representative than dx9 swapchains. I'm certainly not saying it's not a good idea, but I do think the performance hit shouldn't be quite as noticeable.

Aug. 22, 2007

Re: gphoto2.ds: remove camera import UI

by Dan Kegel

On 8/22/07, Alexandre Julliard <julliard(a)winehq.org> wrote: > > 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. Would that setting be persistant? If so, wouldn't we want a way to flip that option back later? Winecfg is the logical place for that. winecfg is our control panel. (It should be exploded into control panel applets, IMHO, but that's another matter.) Most users don't care about 95% of the stuff in the Windows control panel, but those controls have to be there for the 5% that do. - Dan

Aug. 22, 2007

Re: [2/5] WineD3D: Refuse to lock locked surfaces

by Stefan Dösinger

Am Mittwoch, 22. August 2007 11:36 schrieb H. Verbeet: > On 22/08/07, Stefan Dösinger <stefan(a)codeweavers.com> wrote: > > Spotted by DCT > > I don't know what the DCT actually tests, but should it refuse to lock > any locked surface, or only when the rectangles overlap? Of course a > test would be nice, considering surface locking behaves somewhat > different between ddraw, d3d8 and d3d9. I agree that we need some tests, but all docs I've read so far indicate that a surface(opposed to index/vertex buffers) can't be locked two times, no matter what rectangles there are. The DCT test in question tested GetDC(), then LockRect() and LockRect(), then GetDC(). But since UnlockRect doesn't take a rectangle parameter, the runtime wouldn't know which rectangle is now locked or unlocked, so it is unlikely that two rectangles can be locked concurrently. But I'll write a test for this.

Aug. 22, 2007