Christian Costa wrote:
Hi,
With this patch, the indeo codec feels a little better.
Changelog: Initialize the COM libraries for the newly created worker thread in the AVI splitter. Fixed some returned error codes. Show refcount in the AddRef/Release traces in filter. Added 24 bits source in the video renderer.
Christian Costa titan.costa@wanadoo.fr
Index: avidec.c
RCS file: /home/wine/wine/dlls/quartz/avidec.c,v retrieving revision 1.11 diff -u -r1.11 avidec.c --- avidec.c 20 Dec 2004 17:07:17 -0000 1.11 +++ avidec.c 24 Dec 2004 13:31:39 -0000
Why make things difficult for Alexandre? It is Christmas after all. Provide a diff relative to the root of the wine tree.
...
Index: pin.c
RCS file: /home/wine/wine/dlls/quartz/pin.c,v retrieving revision 1.9 diff -u -r1.9 pin.c --- pin.c 16 Dec 2004 14:25:15 -0000 1.9 +++ pin.c 24 Dec 2004 13:31:52 -0000 @@ -1134,6 +1134,8 @@ REFERENCE_TIME rtCurrent; ALLOCATOR_PROPERTIES allocProps;
CoInitialize(NULL);
SetEvent(This->hEventStateChanged);
hr = IMemAllocator_GetProperties(This->pAlloc, &allocProps);
Good catch, but it would probably be better to use CoInitializeEx(NULL, COINIT_MULTITHREADED). This seems to be what Microsoft uses for the pull thread.
Rob
Robert Shearman wrote:
Christian Costa wrote:
Hi,
With this patch, the indeo codec feels a little better.
Changelog: Initialize the COM libraries for the newly created worker thread in the AVI splitter. Fixed some returned error codes. Show refcount in the AddRef/Release traces in filter. Added 24 bits source in the video renderer.
Christian Costa titan.costa@wanadoo.fr
Index: avidec.c
RCS file: /home/wine/wine/dlls/quartz/avidec.c,v retrieving revision 1.11 diff -u -r1.11 avidec.c --- avidec.c 20 Dec 2004 17:07:17 -0000 1.11 +++ avidec.c 24 Dec 2004 13:31:39 -0000
Why make things difficult for Alexandre? It is Christmas after all. Provide a diff relative to the root of the wine tree.
...
Well, it's what I usually do when the patch is related to a single component and Alexandre never complains about that. If it makes Alexandre's life easier, I can do it. It is not my intention to undermine his Christmas. ;-)
Index: pin.c
RCS file: /home/wine/wine/dlls/quartz/pin.c,v retrieving revision 1.9 diff -u -r1.9 pin.c --- pin.c 16 Dec 2004 14:25:15 -0000 1.9 +++ pin.c 24 Dec 2004 13:31:52 -0000 @@ -1134,6 +1134,8 @@ REFERENCE_TIME rtCurrent; ALLOCATOR_PROPERTIES allocProps;
CoInitialize(NULL);
SetEvent(This->hEventStateChanged);hr = IMemAllocator_GetProperties(This->pAlloc, &allocProps);
Good catch, but it would probably be better to use CoInitializeEx(NULL, COINIT_MULTITHREADED). This seems to be what Microsoft uses for the pull thread.
I was wondering about that but since I'm not very confident with this apartment stuff... I will try and see if it's still work.
Bye, Christian
Christian Costa wrote:
Robert Shearman wrote:
Christian Costa wrote:
Index: pin.c
RCS file: /home/wine/wine/dlls/quartz/pin.c,v retrieving revision 1.9 diff -u -r1.9 pin.c --- pin.c 16 Dec 2004 14:25:15 -0000 1.9 +++ pin.c 24 Dec 2004 13:31:52 -0000 @@ -1134,6 +1134,8 @@ REFERENCE_TIME rtCurrent; ALLOCATOR_PROPERTIES allocProps;
CoInitialize(NULL);
SetEvent(This->hEventStateChanged);hr = IMemAllocator_GetProperties(This->pAlloc, &allocProps);
Good catch, but it would probably be better to use CoInitializeEx(NULL, COINIT_MULTITHREADED). This seems to be what Microsoft uses for the pull thread.
I was wondering about that but since I'm not very confident with this apartment stuff... I will try and see if it's still work.
The problem with using COINIT_APARTMENTHREADED (which is what you effectively are using when you use the non-Ex version of the function) is that it depends on using window messages when marshaling. The pull thread does not have a message queue and does not dispatch messages, therefore marshaled objects could hang when called. It is an unlikely case (who would want to use marshaled objects in a performance sensitive component), but you never know with these crazy Windows applications.
Rob
Robert Shearman wrote:
Christian Costa wrote:
Robert Shearman wrote:
Christian Costa wrote:
Index: pin.c
RCS file: /home/wine/wine/dlls/quartz/pin.c,v retrieving revision 1.9 diff -u -r1.9 pin.c --- pin.c 16 Dec 2004 14:25:15 -0000 1.9 +++ pin.c 24 Dec 2004 13:31:52 -0000 @@ -1134,6 +1134,8 @@ REFERENCE_TIME rtCurrent; ALLOCATOR_PROPERTIES allocProps;
CoInitialize(NULL);
SetEvent(This->hEventStateChanged);hr = IMemAllocator_GetProperties(This->pAlloc, &allocProps);
Good catch, but it would probably be better to use CoInitializeEx(NULL, COINIT_MULTITHREADED). This seems to be what Microsoft uses for the pull thread.
I was wondering about that but since I'm not very confident with this apartment stuff... I will try and see if it's still work.
The problem with using COINIT_APARTMENTHREADED (which is what you effectively are using when you use the non-Ex version of the function) is that it depends on using window messages when marshaling. The pull thread does not have a message queue and does not dispatch messages, therefore marshaled objects could hang when called. It is an unlikely case (who would want to use marshaled objects in a performance sensitive component), but you never know with these crazy Windows applications.
Rob
Thanks for the explanation, Rob. I've just try and it still works fine with the change.
Bye, Christian
Christian Costa titan.costa@wanadoo.fr writes:
Well, it's what I usually do when the patch is related to a single component and Alexandre never complains about that. If it makes Alexandre's life easier, I can do it. It is not my intention to undermine his Christmas. ;-)
As long as it includes the full path in the "RCS file" header, patch knows how to deal with it so it's OK for me. Still, including the full path would probably make it easier to read.
Alexandre Julliard wrote:
Christian Costa titan.costa@wanadoo.fr writes:
Well, it's what I usually do when the patch is related to a single component and Alexandre never complains about that. If it makes Alexandre's life easier, I can do it. It is not my intention to undermine his Christmas. ;-)
As long as it includes the full path in the "RCS file" header, patch knows how to deal with it so it's OK for me. Still, including the full path would probably make it easier to read.
Since it takes no more effort, I will do the diff from the root for all next patches.
Bye, Christian
-
Alexandre Julliard -
Christian Costa -
Robert Shearman