May 2012 - Wine-Devel - list.winehq.org

Re: windowscodecs: Add a stubbed out IWICMetadataBlockReader interface.

by Vincent Povirk

Please add a test showing that some builtin metadata handler implements this interface. On Thu, May 24, 2012 at 4:39 AM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > --- > dlls/windowscodecs/metadatahandler.c | 69 ++++++++++++++++++++++++++++++++++ > 1 file changed, 69 insertions(+) > > diff --git a/dlls/windowscodecs/metadatahandler.c b/dlls/windowscodecs/metadatahandler.c > index afcff21..ffe6763 100644 > --- a/dlls/windowscodecs/metadatahandler.c > +++ b/dlls/windowscodecs/metadatahandler.c > @@ -39,6 +39,7 @@ typedef struct MetadataHandler { > IWICMetadataWriter IWICMetadataWriter_iface; > LONG ref; > IWICPersistStream IWICPersistStream_iface; > + IWICMetadataBlockReader IWICMetadataBlockReader_iface; > const MetadataHandlerVtbl *vtable; > MetadataItem *items; > DWORD item_count; > @@ -55,6 +56,11 @@ static inline MetadataHandler *impl_from_IWICPersistStream(IWICPersistStream *if > return CONTAINING_RECORD(iface, MetadataHandler, IWICPersistStream_iface); > } > > +static inline MetadataHandler *impl_from_IWICMetadataBlockReader(IWICMetadataBlockReader *iface) > +{ > + return CONTAINING_RECORD(iface, MetadataHandler, IWICMetadataBlockReader_iface); > +} > + > static void MetadataHandler_FreeItems(MetadataHandler *This) > { > int i; > @@ -92,6 +98,10 @@ static HRESULT WINAPI MetadataHandler_QueryInterface(IWICMetadataWriter *iface, > { > *ppv = &This->IWICPersistStream_iface; > } > + else if (IsEqualIID(&IID_IWICMetadataBlockReader, iid)) > + { > + *ppv = &This->IWICMetadataBlockReader_iface; > + } > else > { > *ppv = NULL; > @@ -317,6 +327,64 @@ static const IWICPersistStreamVtbl MetadataHandler_PersistStream_Vtbl = { > MetadataHandler_SaveEx > }; > > +static HRESULT WINAPI MetadataHandler_MetadataBlockReader_QueryInterface(IWICMetadataBlockReader *iface, > + REFIID iid, void **ppv) > +{ > + MetadataHandler *This = impl_from_IWICMetadataBlockReader(iface); > + return IWICMetadataWriter_QueryInterface(&This->IWICMetadataWriter_iface, iid, ppv); > +} > + > +static ULONG WINAPI MetadataHandler_MetadataBlockReader_AddRef(IWICMetadataBlockReader *iface) > +{ > + MetadataHandler *This = impl_from_IWICMetadataBlockReader(iface); > + return IWICMetadataWriter_AddRef(&This->IWICMetadataWriter_iface); > +} > + > +static ULONG WINAPI MetadataHandler_MetadataBlockReader_Release(IWICMetadataBlockReader *iface) > +{ > + MetadataHandler *This = impl_from_IWICMetadataBlockReader(iface); > + return IWICMetadataWriter_Release(&This->IWICMetadataWriter_iface); > +} > + > +static HRESULT WINAPI MetadataHandler_MetadataBlockReader_GetContainerFormat( > + IWICMetadataBlockReader *iface, GUID *guid) > +{ > + FIXME("(%p,%p): stub\n", iface, guid); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI MetadataHandler_MetadataBlockReader_GetCount( > + IWICMetadataBlockReader *iface, UINT *count) > +{ > + FIXME("(%p,%p): stub\n", iface, count); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI MetadataHandler_MetadataBlockReader_GetReaderByIndex( > + IWICMetadataBlockReader *iface, UINT index, IWICMetadataReader **reader) > +{ > + FIXME("(%p,%u,%p): stub\n", iface, index, reader); > + return E_NOTIMPL; > +} > + > +static HRESULT WINAPI MetadataHandler_MetadataBlockReader_GetEnumerator( > + IWICMetadataBlockReader *iface, IEnumUnknown **enum_metadata) > +{ > + FIXME("(%p,%p): stub\n", iface, enum_metadata); > + return E_NOTIMPL; > +} > + > +static const IWICMetadataBlockReaderVtbl MetadataHandler_MetadataBlockReader_Vtbl = > +{ > + MetadataHandler_MetadataBlockReader_QueryInterface, > + MetadataHandler_MetadataBlockReader_AddRef, > + MetadataHandler_MetadataBlockReader_Release, > + MetadataHandler_MetadataBlockReader_GetContainerFormat, > + MetadataHandler_MetadataBlockReader_GetCount, > + MetadataHandler_MetadataBlockReader_GetReaderByIndex, > + MetadataHandler_MetadataBlockReader_GetEnumerator > +}; > + > HRESULT MetadataReader_Create(const MetadataHandlerVtbl *vtable, IUnknown *pUnkOuter, REFIID iid, void** ppv) > { > MetadataHandler *This; > @@ -333,6 +401,7 @@ HRESULT MetadataReader_Create(const MetadataHandlerVtbl *vtable, IUnknown *pUnkO > > This->IWICMetadataWriter_iface.lpVtbl = &MetadataHandler_Vtbl; > This->IWICPersistStream_iface.lpVtbl = &MetadataHandler_PersistStream_Vtbl; > + This->IWICMetadataBlockReader_iface.lpVtbl = &MetadataHandler_MetadataBlockReader_Vtbl; > This->ref = 1; > This->vtable = vtable; > This->items = NULL; > -- > 1.7.10.1 > > >

May 24, 2012

Re: gdiplus: Reimplement GdipIsEmptyRegion.

by Vincent Povirk

Status is still "New". I guess a test could help, but I would be very surprised if native can't detect things like empty paths. On Wed, May 23, 2012 at 11:22 PM, Dmitry Timoshkov <dmitry(a)baikal.ru> wrote: > Hello, > > I'm surprised that such a trivial patch wasn't accepted yet. But just > in case it matters, current implementation doesn't work for paths and > combined/complex regions. > > -- > Dmitry. > >

May 24, 2012

Re: Testing regedit

by Frédéric Delanoy

On Thu, May 24, 2012 at 8:47 AM, Daniel Jelinski <djelinski1(a)gmail.com> wrote: > 2012/5/24 Austin English <austinenglish(a)gmail.com>: >> On Wed, May 23, 2012 at 12:24 PM, Daniel Jelinski <djelinski1(a)gmail.com> wrote: >>> Hello, >>> I just noticed that wine's regedit has a few interesting bugs that >>> appear when running with native comctl32. Can I/should I file them in >>> the bugzilla? >>> >>> Regards, >>> Daniel >> >> What sort of bugs? In general, any bugs found with native dlls are suspect.. >> >> -- >> -Austin > > One found with both native and builtin comctl32 - if you right-click a > key and select New, the new one is created under the node that was > last selected, not under the one that was right-clicked. This is > different form windows regedit and can be confusing. Is there a bug opened for that issue? If not, could you submit one so it is tracked and (hopefully) eventually fixed? Frédéric

May 24, 2012

Re: Testing regedit

by Daniel Jelinski

2012/5/24 Austin English <austinenglish(a)gmail.com>: > On Wed, May 23, 2012 at 12:24 PM, Daniel Jelinski <djelinski1(a)gmail.com> wrote: >> Hello, >> I just noticed that wine's regedit has a few interesting bugs that >> appear when running with native comctl32. Can I/should I file them in >> the bugzilla? >> >> Regards, >> Daniel > > What sort of bugs? In general, any bugs found with native dlls are suspect.. > > -- > -Austin One found with both native and builtin comctl32 - if you right-click a key and select New, the new one is created under the node that was last selected, not under the one that was right-clicked. This is different form windows regedit and can be confusing. Two others present with Windows comctl, but work correctly with wine's: - you can't edit names of keys - even when you add a new key - if you add a subkey to a key that did not have any subkeys before, the new subkey is not visible and the parent key is not expandable. After restarting regedit the keys are present and visible. Regards, Daniel

May 24, 2012

Re: gdiplus: Reimplement GdipIsEmptyRegion.

by Dmitry Timoshkov

Hello, I'm surprised that such a trivial patch wasn't accepted yet. But just in case it matters, current implementation doesn't work for paths and combined/complex regions. -- Dmitry.

May 24, 2012

Re: Testing regedit

by Austin English

On Wed, May 23, 2012 at 12:24 PM, Daniel Jelinski <djelinski1(a)gmail.com> wrote: > Hello, > I just noticed that wine's regedit has a few interesting bugs that > appear when running with native comctl32. Can I/should I file them in > the bugzilla? > > Regards, > Daniel What sort of bugs? In general, any bugs found with native dlls are suspect.. -- -Austin

May 24, 2012

Testing regedit

by Daniel Jelinski

Hello, I just noticed that wine's regedit has a few interesting bugs that appear when running with native comctl32. Can I/should I file them in the bugzilla? Regards, Daniel

May 23, 2012

Re: [PATCH variant 1] dsound: use a low-quality FIR for games

by Alexander E. Patrakov

2012/5/23 Alexander E. Patrakov <patrakov(a)gmail.com>: > Due to this difference of latency there may be unaviodable clicks in > games (sorry, no concrete example) that frequently switch from 3 to 4 > buffers and back. The FIR-based approach eliminates this effect, > because there is no latency difference (or, because this is untested, > better say: it's a bug in my code if there is any latency difference). If your CPU is fast enough to play GTA:SA with full-quality resampler (I can't test because I don't have this game), you can test this clicking problem by setting the HQBuffersMax registry entry to something that is higher than the "normal" number of the concurrent buffers but lower than the peak number. When the threshold is crossed, something interesting (I guess, a click) should happen with the sound, and I also want to know what exactly :) -- Alexander E. Patrakov

May 23, 2012

Re: [PATCH variant 1] dsound: use a low-quality FIR for games

by Alexander E. Patrakov

2012/5/22 Andrew Eikum <aeikum(a)codeweavers.com>: > Thanks Alexander. Thoughts below... > > On Sat, May 19, 2012 at 09:09:35PM +0600, Alexander E. Patrakov wrote: >> There are two ways to implement a high-performance resampler, and I >> have prepared (conflicting, pick no more than one) patches for both: >> >> 1 (this patch): Use a shorter FIR with the existing code. This has the >> advantage of higher quality (unwanted frequencies are at least >> attempted to be rejected) and almost no new code. >> 2 (the other patch): Write new code. E.g., linear interpolation. This >> is what Windows XP does at its lowest quality setting, and it eats >> less CPU than variant 1. >> > > Do you have an opinion on which of these patches to use? The > low-quality FIR has the advantage of not introducing another codepath. > On the other hand, the linear resampler codepath is very simple, and > even easier on the CPU. Yes. And Windows has two code paths as well. OTOH the linear resampler has lower quality, and different latency from the FIR-based filter. Due to this difference of latency there may be unaviodable clicks in games (sorry, no concrete example) that frequently switch from 3 to 4 buffers and back. The FIR-based approach eliminates this effect, because there is no latency difference (or, because this is untested, better say: it's a bug in my code if there is any latency difference). > I'm leaning towards the linear resampler for its larger CPU usage > benefits. I have no real preference. If there are no other arguments (i.e. if clicks due to switching resamplers are not a valid/worthy argument), let's use the linear resampler, because I wrote it first and because GyB tested it. Anyway, it doesn't really matter, because it is possible to change this later, or even implement a 3-level quality degradation strategy (long FIR -> short FIR -> linear interpolation). As for your performance analysis - yes, get_current_sample() is cheap, and the main cost is due to caching the FIR and calculating the convolution. As far as I understand (but I can be wrong here), it would be fair enough to count only the "sum += fir_copy[j] * cache[j];" line. Still, I don't think it explains the whole picture. Let's say that the FIR length is X samples of the lowest of the two frequencies (X is a constant for a given FIR, and for my FIR it is 66). So, if upsampling, each output sample is affected by X input samples, and by X * freqAdjust input samples when downsampling. Since both GTA:SA and Darwinia use 32 buffers, we can consider only a single buffer and count the number of passes through the "sum" line per second. Darwinia downsamples, has freqAdjust ~ 2..4. Thus, it executes the "sum" line 2..4 * X times per output sample, i.e. 40000..90000 * X times per second per input buffer. GTA:SA upsamples, and thus executes the "sum" line X times per output sample, i.e. 48000 * X times per second per input buffer. The ratio seems to be consistent with the number of convolutions per buffer per time step that you report, because the number of sampes per time step is different for these two games. So I am not convinced with your analysis - but this is based on the assumption that only the "sum += fir_copy[j] * cache[j];" line really matters and that filling in fir_cache eats time proportional to the summing (it has to go through the same number of iterations). -- Alexander E. Patrakov

May 23, 2012

Re: vbscript: Add support for integer values in conditional jumps.

by Francois Gouget

On Wed, 23 May 2012, Marvin wrote: > Hi, > > While running your changed tests on Windows, I think I found new failures. > Being a bot and all I'm not very good at pattern recognition, so I might be > wrong, but could you please double-check? > Full results can be found at > http://testbot.winehq.org/JobDetails.pl?Key=18547 I believe this is the usual VBScript test issue. At least the test passed on my Windows XP VM. -- Francois Gouget <fgouget(a)codeweavers.com>

May 23, 2012