Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

2013-10-04 Thread Stefan Dösinger
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

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

2013-10-04 Thread Henri Verbeet
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

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

2013-10-04 Thread Stefan Dösinger
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

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

2013-10-04 Thread Stefan Dösinger
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

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

2013-10-04 Thread 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 cause a texture to be created for sysmem surfaces. There m

Re: [PATCH 1/5] wined3d: Don't bother about client storage in wined3d_surface_set_mem.

2013-10-04 Thread Henri Verbeet
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,

Re: Alexandre Julliard : msvcrt: Don't bother to clean up at process exit.

2013-05-21 Thread Christian Costa
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

Re: Alexandre Julliard : msvcrt: Don't bother to clean up at process exit.

2013-05-21 Thread Dmitry Timoshkov
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.

Re: Alexandre Julliard : msvcrt: Don't bother to clean up at process exit.

2013-05-21 Thread Christian Costa
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

Re: Alexandre Julliard : msvcrt: Don't bother to clean up at process exit.

2013-05-21 Thread Alexandre Julliard
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();

Re: Alexandre Julliard : msvcrt: Don't bother to clean up at process exit.

2013-05-21 Thread Dmitry Timoshkov
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(); > > > >

Re: Alexandre Julliard : msvcrt: Don't bother to clean up at process exit.

2013-05-21 Thread Alexandre Julliard
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

Re: Alexandre Julliard : msvcrt: Don't bother to clean up at process exit.

2013-05-20 Thread Dmitry Timoshkov
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

Re: dsound: Don't bother shrinking the secondary buffer list.

2012-09-27 Thread Michael Stefaniuc
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

dsound: Don't bother shrinking the secondary buffer list.

2012-09-27 Thread Joerg-Cyril.Hoehle
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

Re: Don't bother...

2008-03-30 Thread Hin-Tak Leung
--- 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