[PATCH] winmm: Default to 1ms resolution like we used to

[Zebediah Figura]

On 8/15/20 5:43 AM, Rémi Bernon wrote:
> On 2020-08-15 09:39, Stefan Dösinger wrote:
>>
>>
>>> Am 15.08.2020 um 01:44 schrieb Myah Caron <qsniyg at protonmail.com>:
>>>
>>> Sorry I'm a bit new so I'm not quite sure what the rules are
>>> regarding TRACEs, but would adding a TRACE here be an issue? I think
>>> it might be helpful for future debugging if there are any other
>>> issues with it.
>>
>> Those 'rules' are somewhat inconsistent. I would say adding a TRACE
>> here is a good idea, but not strictly necessary.
>>
>> A lot of functions in kernel32/kernelbase and ntdll have no TRACEs
>> because they show up in a +relay log. But since I am used to COM
>> interfaces in d3d which don't show up in relay logs (+relay injects
>> code into DLL exports, and COM interfaces aren't PE exports) I am very
>> used to +ddraw showing me all ddraw calls, so at times I am confused
>> when +winmm doesn't show half the winmm calls.
>>
> 
> Also, +relay doesn't work with some DRMs, so IMHO adding TRACE messages
> is always useful unless there's a performance penalty or too much
> verbosity.
> 
> For instance I would say ntdll could use more TRACE but it may be
> subjective so I've always kept these patches local.

The lack of traces in kernel32/ntdll is often an annoyance. +relay is
often just not an option, due to slowness or excessive output size.

With regard to timeGetTime(), though, and time functions in general, I
think it is likely better not to trace it. They may be called many times
per second.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: OpenPGP digital signature
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20200815/c7fb5e0a/attachment.sig>