Am 04.10.2013 um 17:15 schrieb Henri Verbeet :
> I guess that makes it ok in practice, but I'd still feel happier about
> this kind of patch if we actually enforced resource access flags
> first. (At which point you could also just check the access flags
> instead of the pool.)
My plan is to enfor
On 4 October 2013 15:51, Stefan Dösinger wrote:
> No codepath in wined3d_surface_blt will attempt to load a sysmem surface into
> a texture. fbo_blit_supported returns FALSE if src or destination are in
> sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills
> will go to a
Am 04.10.2013 um 15:51 schrieb Stefan Dösinger :
> No codepath in wined3d_surface_blt will attempt to load a sysmem surface into
> a texture. fbo_blit_supported returns FALSE if src or destination are in
> sysmem, and so do arbfp_blit_supported and surface_blt_special. Color fills
> will go to a
Am 04.10.2013 um 15:28 schrieb Henri Verbeet :
> On 4 October 2013 15:02, Stefan Dösinger wrote:
>> Client storage only applies to GL textures, which won't be created for
>> sysmem surfaces.
>>
> I don't think that's necessarily true at the moment. In particular,
> ddraw blits can in principle
On 4 October 2013 15:02, Stefan Dösinger wrote:
> Client storage only applies to GL textures, which won't be created for sysmem
> surfaces.
>
I don't think that's necessarily true at the moment. In particular,
ddraw blits can in principle cause a texture to be created for sysmem
surfaces. There m
On 4 October 2013 00:03, Stefan Dösinger wrote:
> @@ -2883,10 +2886,6 @@ HRESULT CDECL wined3d_surface_set_mem(struct
> wined3d_surface *surface, void *mem
> /* Now the surface memory is most up do date. Invalidate drawable
> and texture. */
> surface_validate_location(surface,
That's ok with me.Thanks for the explanation. So Valgrind will report these
"intentional" memory leaks in addition to the "unintentional" ones. Correct?
2013/5/21 Dmitry Timoshkov
> Christian Costa wrote:
>
> > Out of curiosity. Not freeing these memory allocations shouldn't disturb
> > Valgri
Christian Costa wrote:
> Out of curiosity. Not freeing these memory allocations shouldn't disturb
> Valgrind to report false memory leaks?
Avoiding heap access on process exit should avoid possible dead locks
in case a terminated by ExitProcess thread holds the heap lock.
--
Dmitry.
Out of curiosity. Not freeing these memory allocations shouldn't disturb
Valgrind to report false memory leaks?
2013/5/21 Alexandre Julliard
> Dmitry Timoshkov writes:
>
> > Alexandre Julliard wrote:
> >
> >> >>case DLL_PROCESS_DETACH:
> >> >> -msvcrt_free_popen_data();
> >> >> m
Dmitry Timoshkov writes:
> Alexandre Julliard wrote:
>
>> >>case DLL_PROCESS_DETACH:
>> >> -msvcrt_free_popen_data();
>> >> msvcrt_free_io();
>> >> +if (lpvReserved) break;
>> >> +msvcrt_free_popen_data();
>> >> msvcrt_free_mt_locks();
>> >> msvcrt_free_console();
Alexandre Julliard wrote:
> >>case DLL_PROCESS_DETACH:
> >> -msvcrt_free_popen_data();
> >> msvcrt_free_io();
> >> +if (lpvReserved) break;
> >> +msvcrt_free_popen_data();
> >> msvcrt_free_mt_locks();
> >> msvcrt_free_console();
> >> msvcrt_free_args();
> >
> >
Dmitry Timoshkov writes:
> Alexandre Julliard wrote:
>
>>case DLL_PROCESS_DETACH:
>> -msvcrt_free_popen_data();
>> msvcrt_free_io();
>> +if (lpvReserved) break;
>> +msvcrt_free_popen_data();
>> msvcrt_free_mt_locks();
>> msvcrt_free_console();
>> msvcrt_free_a
Alexandre Julliard wrote:
>case DLL_PROCESS_DETACH:
> -msvcrt_free_popen_data();
> msvcrt_free_io();
> +if (lpvReserved) break;
> +msvcrt_free_popen_data();
> msvcrt_free_mt_locks();
> msvcrt_free_console();
> msvcrt_free_args();
Shouldn't msvcrt_free_io() be
Hello Jörg,
as always it depends.
On 09/27/2012 09:37 AM, joerg-cyril.hoe...@t-systems.com wrote:
>> +#include
>
> your patch is already committed, yet I believe that the least that dsound
> needs is new asserts.
>
> Asserts in dsound have been a PITA in Wine for the last decade.
>
> It's ok
Michael,
>+#include
your patch is already committed, yet I believe that the least that dsound needs
is new asserts.
Asserts in dsound have been a PITA in Wine for the last decade.
It's ok for the kernel to crash in an assert. IMHO it is not ok for an optional
thing like sound.
The assert's
--- On Sat, 29/3/08, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote:
> From: [EMAIL PROTECTED] <[EMAIL PROTECTED]>
> Subject: Don't bother...
> To: "Hin-Tak Leung" <[EMAIL PROTECTED]>
> Date: Saturday, 29 March, 2008, 5:51 PM
> I tried compiling it a
16 matches
Mail list logo