January 2013 - Wine-Devel - list.winehq.org

Re: [PATCH 3/5] wined3d: state->user_stream is always FALSE in device_stream_info_from_declaration().

by Stefan Dösinger

Am 04.01.2013 um 12:02 schrieb Henri Verbeet <hverbeet(a)codeweavers.com>: > Since user pointer draws were removed, state->user_stream will only ever be > set for "strided" draws, and device_stream_info_from_declaration() is never > called for those. I have some patches in my tree that remove draw_primitive_strided and user_stream entirely but didn't get around to sending them yet due to reasons unrelated to the patches. I think I should have time to rebase and send them on monday.

Jan. 5, 2013

Re: [2/2] gdi32/tests: Added tests for GetFontResourceInfoW (try 2)

by Dmitry Timoshkov

Stefan Leichter <Stefan.Leichter(a)camline.com> wrote: > > > First of all: The issues your are pointing out have been in the previous > > > version of the patch too. Why didn't you complain in your first review. > > > To my understanding this is a wast of my time complaining about two > > > issues and keeping the rest secret for the next version of the patch. > > > > It's often happens with subsequent reviews, and there is nothing magic or > > secret about it: first review was about the whole approach while next one > > is more about the actual details. > > But the "subsequent review" is burning my time without need. I certainly can stop burning my time with reviewing your patches, but somehow I doubt that it will help with improving and accepting then. Besides I don't see that much of reviewers of font related patches. > > > - the tests are written for a font in %windor%\fonts. This directory is > > > empty after a clean .wine directory was created. Changing the font does > > > not help at all. > > > > But it will once Wine starts to copy its own fonts there at some point. > > To me this sounds more like an excuse than an argument. Maybe we will have an > Arial font before this happens! Consider what is easier: 'cp ~/wine/fonts/sserife.fon ~/.wine/drive_c/windows/fonts' or find an installer for Arial, download and install it before running 'make test'. Even worse, installing Arial or any other external font may actually break the tests. > I will drop the patch with the tests an see what happens first. You may know > the old idiom "A bird in the hand is worth two in the bush." There always is a hope to get a real thing somewhere in the future instead of a broken thing right now. -- Dmitry.

Jan. 5, 2013

Re: [2/2] gdi32/tests: Added tests for GetFontResourceInfoW (try 2)

by Stefan Leichter

Saturday 29 December 2012 Dmitry Timoshkov <dmitry(a)baikal.ru> > Stefan Leichter <Stefan.Leichter(a)camline.com> wrote: > > First of all: The issues your are pointing out have been in the previous > > version of the patch too. Why didn't you complain in your first review. > > To my understanding this is a wast of my time complaining about two > > issues and keeping the rest secret for the next version of the patch. > > It's often happens with subsequent reviews, and there is nothing magic or > secret about it: first review was about the whole approach while next one > is more about the actual details. But the "subsequent review" is burning my time without need. > > - the tests are written for a font in %windor%\fonts. This directory is > > empty after a clean .wine directory was created. Changing the font does > > not help at all. > > But it will once Wine starts to copy its own fonts there at some point. To me this sounds more like an excuse than an argument. Maybe we will have an Arial font before this happens! I will drop the patch with the tests an see what happens first. You may know the old idiom "A bird in the hand is worth two in the bush." -- Stefan

Jan. 5, 2013

Re: Patchsets that need review by experienced Wine Developers

by Alexandre Julliard

André Hentschel <nerv(a)dawncrow.de> writes: > 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? No, that would also break compatibility with existing prefixes. -- Alexandre Julliard julliard(a)winehq.org

Jan. 5, 2013

Re: [website] Wine 1.5.21 freigegeben

by Frédéric Delanoy

On Fri, Jan 4, 2013 at 10:33 PM, André Hentschel <nerv(a)dawncrow.de> wrote: > --- > news/de/2012122101.xml~ | 17 +++++++++++++++++ Not sure checking in your editor backup file is a good idea ;) Frédéric

Jan. 5, 2013

Re: Patchsets that need review by experienced Wine Developers

by 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

Jan. 4, 2013

Re: Patchsets that need review by experienced Wine Developers

by 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?

Jan. 4, 2013

Re: Patchsets that need review by experienced Wine Developers

by 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

Jan. 4, 2013

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

by 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.

Jan. 4, 2013

Re: Patchsets that need review by experienced Wine Developers

by 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

Jan. 4, 2013