Re: windowscodecs: Implement ComponentFactory_CreateBitmapFromMemory. Take 2.

2013-01-04 Thread Marvin
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=23734

Your paranoid android.


=== WINEBUILD (build) ===
Patch failed to apply




Re: [PATCH] d3dx9_36: Implement ID3DXFileImpl_RegisterTemplates + tests. (resend)

2013-01-04 Thread Marvin
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=23733

Your paranoid android.


=== W2K8SE (32 bit xfile) ===
Failure running script in VM: The specified guest user must be logged in 
interactively to perform this operation




Re: windowscodecs: Implement ComponentFactory_CreateBitmapFromMemory. Take 2.

2013-01-04 Thread Vincent Povirk
This looks good to me (and it's hard for me to stick to my preference
for IWICBitmapLock, given how little code is needed here to accomplish
the same thing).

The remaining todo is an unrelated bug that's my fault, and I'll
resend my patch for it if this one is accepted.




Re: Patchsets that need review by experienced Wine Developers

2013-01-04 Thread Marcus Meissner
On Thu, Jan 03, 2013 at 05:22:14PM -0500, jordan wrote:
 Hi,
 
 I have been experimenting with some patchsets for Wine - based on an
 implementation of Wine originally developed By Muse Research.  It has
 improved support for a bunch of stuff, fixes (most) bottlenecks for
 Linux proaudio folks making use of Wine + Jack, and also contains some
 bug fixes for wine (that may or may not be acceptable to wine-devs.)
 
 I have a project that now lives on SF.net, but has been running for
 months now, on my machine(s), locally. It's called L-ProAudio, and the
 version of wine (L_pa-Wine) is geared towards proaudio users. We also
 have support in 1 linux application ~ which now properly handles the
 new method of mapping win/prio - linux/prio. Some of the patchset
 fixes synchronization issues (with jack), disk geomtery-io-syscl,
 fixes rendering bugs in VSTs (probably other apps too) and a bunch of
 other improvements (geared for proaudio users).
 
 L_ProAudio SF.net Page: https://sourceforge.net/projects/l-proaudio/
 
  - Wine-L_Proaudio_Arch_n_patches.tar.gz contains a pkgbuild for
 Archlinux (like gentoo' ebuild) + all patches (and probably one or two
 others, not used in my builds).
 
 But please note: this is NOT a fork of Wine. It is necessary for me to
 be able to run the applications that i want with Wine. I am just
 carrying patchwork and re-basing it, as time passes. But i decided to
 release it - since it benefits the larger community who uses this
 stuff (greatly).
 
 note 2: I am posting, in order to shed light on any improvements/bug
 fixes that _might_ be suitable for upstream. ~ If so, once a given
 stable release of Wine is issued, I would then be able to remove them
 from my patchset, minimizing duplicate efforts, among other things.
 
 The original patches/sources (that i have based my version on, are
 found here: http://www.museresearch.com/support/receptor-faq.php
 
 ...at the bottom of the page / last link:
 http://www.museresearch.com/support/receptor-faq.php
 
 these patches fix Wine problems (in most areas) for people using
 linux(-rt) + jack + ProAudio ... but may have other benefits/bug-fixes
 for wine. It's Gpl'd (obviously), so it would be worthwhile to have a
 look anyway. - didn't include every patch (some of them aren't of
 interest to me, outdated, etc).

I looked over them briefly.

0005-Expand-dos-has-entropy-in-order-to-make-collision-le.patch
Not sure why this is needed?

0010-If-a-child-of-the-window-being-disabled-is-the-captu.patch
a user32.EnableWindow 2008 patch ... is it still needed for you,
as quite some enhancements have happened...

Would need review (likely from julliard or other user32 guru)
and testcases.

0012-ntdll-Use-pipes-for-synchronization-objects.patch
0050-pipe-check-and-thread-safe-read.patch

A new synchronization method using UNIX pipe(2)s.
This is definitely not going in as is...

It would be interesting to know what deficit in regular Wine is
fixed by it. wineserver overhead?

0023-improve-IoRegisterDeviceInterface.patch

Remove the MUSE specific fixmes and use the same FIXME() style
for stub parameters as in the other FIXME()s. Then
its ready for wine-patches I would say.

0025-Add-stub-for-IoSetDeviceInterfaceState.patch
Use same FIXME() style as used for other stub functions, then
ready for submission.

0027-Add-stub-for-PoSetPowerState.patch
Good for submission as-is.

0033-overridable-default-filesystem-type.patch
Not submittable as-is ...
It would be good to know the reason and/or what MUSE expects.

0044-get-windows-label-from-registry.patch
Smells like the wrong place to do it. Perhaps mountmgr.sys,
but perhaps different.
Also unclear if Alexandre likes it.

0052-NI-drag-and-drop.patch
Looks already good for submission to me.


0054-set-realtime-priority-without-wineserver.patch
wine-rt-101107.patch
Needs design and discussion... So far a RT solution
was not accepted for Wine yet.


0061-fix-broken-cross-compiled-winegcc.patch
0063-disable-winedbg-auto-crash-dialog.patch
local hacks

0062-disable-crashing-alpha-bitmaps-for-gdb.patch
Seems like a mistaken patch that was needed as we had
the old DIB sections.

gdb would have accepted continue here.

Should not be necessary anymore these days with the 
DIBENGINE.

add-implementation-setProcessWorkingSetSize.patch
Might be submittable as-is. 

Might need autoconf checks for non-Linux.

Fix-disk-geometry-ioctl.patch
Alexandre usually does not like override files
like this unless necessary.

What is actually expected? you mentioned rendering issues?

fix-obscured-windows.patch
Hmm, needs user32 windowing guru review.


menu-border-color.patch
If this is not just a hack, could be submitted as-is.



Re: Patchsets that need review by experienced Wine Developers

2013-01-04 Thread jordan
 The original patches/sources (that i have based my version on, are
 found here: http://www.museresearch.com/support/receptor-faq.php

 ...at the bottom of the page / last link:
 http://www.museresearch.com/support/receptor-faq.php

 these patches fix Wine problems (in most areas) for people using
 linux(-rt) + jack + ProAudio ... but may have other benefits/bug-fixes
 for wine. It's Gpl'd (obviously), so it would be worthwhile to have a
 look anyway. - didn't include every patch (some of them aren't of
 interest to me, outdated, etc).

 I looked over them briefly.

 0005-Expand-dos-has-entropy-in-order-to-make-collision-le.patch
 Not sure why this is needed?

I'm not sure why either, but i am guessing it improves things in a
linux-rt/VST setting (in fact, removing it causes regressions on my
L_pa systems - so i am keeping it.

 0010-If-a-child-of-the-window-being-disabled-is-the-captu.patch
 a user32.EnableWindow 2008 patch ... is it still needed for you,
 as quite some enhancements have happened...

 Would need review (likely from julliard or other user32 guru)
 and testcases.

Seems to be, yeah.

 0012-ntdll-Use-pipes-for-synchronization-objects.patch
 0050-pipe-check-and-thread-safe-read.patch

 A new synchronization method using UNIX pipe(2)s.
 This is definitely not going in as is...

Figured as much :)  (that was pretty obvious lol.)

 It would be interesting to know what deficit in regular Wine is
 fixed by it. wineserver overhead?

Yeah, Wineserver is probably the number one thing that slows down
when, when you are looking for low-latency / high-performance. (ext4
is also terrible on stock settings).

 0023-improve-IoRegisterDeviceInterface.patch

 Remove the MUSE specific fixmes and use the same FIXME() style
 for stub parameters as in the other FIXME()s. Then
 its ready for wine-patches I would say.

Awesome :) I must have missed that ~ you will notice that i removed
them from the new variables used by L_ (didn't want any
hassles/trademark issues with Muse).

 0025-Add-stub-for-IoSetDeviceInterfaceState.patch
 Use same FIXME() style as used for other stub functions, then
 ready for submission.

Great.

 0027-Add-stub-for-PoSetPowerState.patch
 Good for submission as-is.

Great. :)

 0033-overridable-default-filesystem-type.patch
 Not submittable as-is ...
 It would be good to know the reason and/or what MUSE expects.

You can contact them. They don't seem to get the idea of FOSS - by
having our help, they could have _Less_ of a delta they are keeping.
But as far as this patch is concerned, i am not sure. (this is why i
got in touch with you guys).

 0044-get-windows-label-from-registry.patch
 Smells like the wrong place to do it. Perhaps mountmgr.sys,
 but perhaps different.
 Also unclear if Alexandre likes it.

I think for their purposes it probably is though, so i have kept it as
well (for now, unless told that i shouldn't for good reason).

 0052-NI-drag-and-drop.patch
 Looks already good for submission to me.

Yeah, it fixes BIG hassles for N.I users like myself.

 0054-set-realtime-priority-without-wineserver.patch
 wine-rt-101107.patch
 Needs design and discussion... So far a RT solution
 was not accepted for Wine yet.

Yeah - that is in fact, one of the most important patches for us
(linuxaudio folks). The FSThost developer (wraps wineVSTs, single
hosted) said it is the 'holy grail' for fixing his software to
properly handle windows VSTs and it does so very well :)  ~ windows
VSTs are highly performant, synchronized and run like normal
Jack_cleints without wineserver getting in the way.

 0061-fix-broken-cross-compiled-winegcc.patch
 0063-disable-winedbg-auto-crash-dialog.patch
 local hacks

k.

 0062-disable-crashing-alpha-bitmaps-for-gdb.patch
 Seems like a mistaken patch that was needed as we had
 the old DIB sections.

 gdb would have accepted continue here.

 Should not be necessary anymore these days with the
 DIBENGINE.

Okay, i will try reverting it locally and make sure everything is good.

 add-implementation-setProcessWorkingSetSize.patch
 Might be submittable as-is.

 Might need autoconf checks for non-Linux.

good. but i am not the guy to do this ~ i have a _ton_ of work right
now, both professionally and for my own projects. I just wanted to
make sure anything that _should_ be in wine goes into Wine to improve
the experience for everyone.

 Fix-disk-geometry-ioctl.patch
 Alexandre usually does not like override files
 like this unless necessary.

 What is actually expected? you mentioned rendering issues?

I am not sure about this one. it needs investigating but i have it
applied.  As far as rendering issues, yes upstream wine causes ugly
flickering in some apps/VSTs, while L_pa-Wine does not (at all, 

Re: Patchsets that need review by experienced Wine Developers

2013-01-04 Thread jordan
Also, as a general note Marcus (and any other wine-developer who may
be reading this).

If you guys ever happen to come accross patches that may fix issues
for me, but aren't suitable for upstream ~ please contact me and pass
them along.

since i am targeting a much smaller audience with 'particular' needs,
i would like to improve the experience, as best as i can for those
purposes.

Thanks again.

Jordan




Re: Patchsets that need review by experienced Wine Developers

2013-01-04 Thread Michael Ost

Hi, list.

We at Muse Research are happy help move our patches from custom one-offs 
to the main fork. Background info below...



The original patches/sources (that i have based my version on, are
found here: http://www.museresearch.com/support/receptor-faq.php

...at the bottom of the page / last link:
http://www.museresearch.com/support/receptor-faq.php



I looked over them briefly.



0005-Expand-dos-has-entropy-in-order-to-make-collision-le.patch
 Not sure why this is needed?


I'm not sure why either, but i am guessing it improves things in a
linux-rt/VST setting (in fact, removing it causes regressions on my
L_pa systems - so i am keeping it.


This is a really old patch. IIRC there were different long filenames 
that were being converted to the same 8.3 filename. I don't have more 
details.



0010-If-a-child-of-the-window-being-disabled-is-the-captu.patch
 a user32.EnableWindow 2008 patch ... is it still needed for you,
 as quite some enhancements have happened...

 Would need review (likely from julliard or other user32 guru)
 and testcases.


Seems to be, yeah.


This fixed a problem where FM8's 'save' window would get stuck. Once you 
opened and cancelled it, any mouse click would open it again.



0012-ntdll-Use-pipes-for-synchronization-objects.patch
0050-pipe-check-and-thread-safe-read.patch

 A new synchronization method using UNIX pipe(2)s.
 This is definitely not going in as is...


Figured as much :)  (that was pretty obvious lol.)


 It would be interesting to know what deficit in regular Wine is
 fixed by it. wineserver overhead?


Yeah, Wineserver is probably the number one thing that slows down
when, when you are looking for low-latency / high-performance. (ext4
is also terrible on stock settings).


This removes key synchronization calls from the wineserver and keeps 
them on the app side. Without it realtime performance is impossible. We 
developed this with Codeweavers, and they were pretty sure it wasn't 
general enough for the main fork.



0023-improve-IoRegisterDeviceInterface.patch

 Remove the MUSE specific fixmes and use the same FIXME() style
 for stub parameters as in the other FIXME()s. Then
 its ready for wine-patches I would say.


Awesome :) I must have missed that ~ you will notice that i removed
them from the new variables used by L_ (didn't want any
hassles/trademark issues with Muse).


Don't worry, no problem with us! This was helpful in getting Pace CDRM 
ilok support to work.



0025-Add-stub-for-IoSetDeviceInterfaceState.patch
 Use same FIXME() style as used for other stub functions, then
 ready for submission.


Great.


0027-Add-stub-for-PoSetPowerState.patch
 Good for submission as-is.


Great. :)


Ditto from 0023.


0033-overridable-default-filesystem-type.patch
 Not submittable as-is ...
 It would be good to know the reason and/or what MUSE expects.


You can contact them. They don't seem to get the idea of FOSS - by
having our help, they could have _Less_ of a delta they are keeping.
But as far as this patch is concerned, i am not sure. (this is why i
got in touch with you guys).


This is internal and not generally useful.


0044-get-windows-label-from-registry.patch
 Smells like the wrong place to do it. Perhaps mountmgr.sys,
 but perhaps different.
 Also unclear if Alexandre likes it.


I think for their purposes it probably is though, so i have kept it as
well (for now, unless told that i shouldn't for good reason).


This one is internal too.


0052-NI-drag-and-drop.patch
 Looks already good for submission to me.


Yeah, it fixes BIG hassles for N.I users like myself.


Cool.


0054-set-realtime-priority-without-wineserver.patch
wine-rt-101107.patch
 Needs design and discussion... So far a RT solution
 was not accepted for Wine yet.


Yeah - that is in fact, one of the most important patches for us
(linuxaudio folks). The FSThost developer (wraps wineVSTs, single
hosted) said it is the 'holy grail' for fixing his software to
properly handle windows VSTs and it does so very well :)  ~ windows
VSTs are highly performant, synchronized and run like normal
Jack_cleints without wineserver getting in the way.


Same as above, moving sync calls out of the wineserver is the only way 
to use Wine for realtime audio applications. Especially with more 
complicated plugins like Kontakt.



0061-fix-broken-cross-compiled-winegcc.patch


This fixed a compiler problem when cross compiling a 32bit winelib 
application on a 64bit system. The messages were:



/usr/include/wine/windows/rpcndr.h:176:16: error: ‘_MIDL_STUB_MESSAGE’ has a
field ‘_MIDL_STUB_MESSAGE::SavedContextHandles’ whose type uses the anonymous
namespace [-Werror]
/usr/include/wine/windows/rpcndr.h:479:16: error: ‘_SCONTEXT_QUEUE’ has a field
‘_SCONTEXT_QUEUE::ArrayOfObjects’ whose type uses the anonymous namespace

Re: Patchsets that need review by experienced Wine Developers

2013-01-04 Thread jordan
 We at Muse Research are happy help move our patches from custom one-offs to
 the main fork. Background info below...

 -- Michael Ost
 Muse Research and Development

Hi Michael, I recognize your name from years ago on various
(linux-related) lists.

I hope you don't mind that i took the initiative here. :) This
benefits us all ~ less of a delta for you, less for me and improved
Wine support for everybody ~ it's a win win situation. In reality, the
strength of your product line is not secret sauce to wine, when you
really think about it... the benefit is the amazing software + H/W
that you guys have designed.  ~ i've used them, but can't _justify_
the expense, at this point ~ although i would love a Receptor :) (and
_would_ own one if i was a touring professional, since it is simply
the best option available)

Anyway, Michael - i hope you didn't take any of this as 'stepping on
your toes'. I also hope it isn't a problem that within my project;
L_ProAudio that i have _renamed_ all of the MUSE stuff ~ being as that
is your trademark.

also, if you are interested later down the line (once, the project is
slightly more mature), we could share some tips on taming linux-rt,
but that is entirely upto you guys.

lastly, thank you very much for publishing your GPL'd code. It fixes a
lot of hassles for me.

cheerz

Jordan




Re: [1/4] windowscodecs: Introduce 24bppRGB PixelFormat

2013-01-04 Thread Vincent Povirk
The series looks good to me. Of course, we can already read 8-bit
tiffs just fine, but I guess your app makes use of the 8bpp RGB
format.

We could probably avoid a double conversion between rgb and bgr when
reading an 8-bit tiff as rgb, by implementing and using the
IWICBitmapSourceTransform interface, but MSDN seems to claim that the
native TIFF decoder doesn't do this.




Re: Patchsets that need review by experienced Wine Developers

2013-01-04 Thread Louis Gorenfeld
Hi!
  I'm really happy that some of our patches are making it into WINE! If I could 
chime in...

 0005-Expand-dos-has-entropy-in-order-to-make-collision-le.patch
 Not sure why this is needed?
 
 I'm not sure why either, but i am guessing it improves things in a
 linux-rt/VST setting (in fact, removing it causes regressions on my
 L_pa systems - so i am keeping it.
 
 This is a really old patch. IIRC there were different long filenames that 
 were being converted to the same 8.3 filename. I don't have more details.

That was because of a name collision that'd happen when running the installer 
for NI's Akoustik Piano plugin. It creates hundreds (or thousands?) of files 
with similar names in one directory, and the installer would name the file one 
thing but in the file would be another file's contents. IIRC, it was a pretty 
unusual case.

 0012-ntdll-Use-pipes-for-synchronization-objects.patch
 0050-pipe-check-and-thread-safe-read.patch
 
 A new synchronization method using UNIX pipe(2)s.
 This is definitely not going in as is...
 
 Figured as much :)  (that was pretty obvious lol.)
 
 It would be interesting to know what deficit in regular Wine is
 fixed by it. wineserver overhead?
 
 Yeah, Wineserver is probably the number one thing that slows down
 when, when you are looking for low-latency / high-performance. (ext4
 is also terrible on stock settings).
 
 This removes key synchronization calls from the wineserver and keeps them on 
 the app side. Without it realtime performance is impossible. We developed 
 this with Codeweavers, and they were pretty sure it wasn't general enough for 
 the main fork.

This might also end up being generally useful for programs that are realtime 
and make a lot of wineserver calls. I believe the mutexes were taking too long 
to access because they were going through wineserver, which was already 
handling a lot of other calls in serial. Basically, it was a traffic jam. 
That's my understanding and recollection, at least (I wasn't the original 
author of the patch but I did do some work on it later).

Louis Gorenfeld
Muse Research





Re: Patchsets that need review by experienced Wine Developers

2013-01-04 Thread André Hentschel
On 04.01.2013 22:33, Louis Gorenfeld wrote:
 Hi!
   I'm really happy that some of our patches are making it into WINE! If I 
 could chime in...
 
 0005-Expand-dos-has-entropy-in-order-to-make-collision-le.patch
 Not sure why this is needed?

 I'm not sure why either, but i am guessing it improves things in a
 linux-rt/VST setting (in fact, removing it causes regressions on my
 L_pa systems - so i am keeping it.

 This is a really old patch. IIRC there were different long filenames that 
 were being converted to the same 8.3 filename. I don't have more details.
 
 That was because of a name collision that'd happen when running the installer 
 for NI's Akoustik Piano plugin. It creates hundreds (or thousands?) of files 
 with similar names in one directory, and the installer would name the file 
 one thing but in the file would be another file's contents. IIRC, it was a 
 pretty unusual case.
 

We should decide soon if we want to accept that patch, because it breaks DOSBox 
compatiblity. So in case we commit it we should change it in dosbox before they 
release 0.75
AJ?




Re: Patchsets that need review by experienced Wine Developers

2013-01-04 Thread jordan
 This might also end up being generally useful for programs that are realtime 
 and make a lot of wineserver calls. I believe  the mutexes were taking too 
 long to access because they were going through wineserver, which was already 
 handling a  lot of other calls in serial. Basically, it was a traffic jam. 
 That's my understanding and recollection, at least (I wasn't the   original 
 author of the patch but I did do some work on it later).

+1

That matches my experiences, as well, Louis.

ext4 likes to jam up things to, so ideally if these problems are going
to be solved upstream ~ wine-devs also will likely want to look at
problems with ext4 (possibly, btrfs down the line ~ since i think i
remember noticing a kernel hack for btrfs(?).

anyway, that is another issue all together.

Jordan