June 2009 - Wine-Devel - list.winehq.org

Re: Implications for Wine from the Ubuntu Developer Summit

by Roderick Colenbrander

On Tue, Jun 2, 2009 at 10:08 AM, Francois Gouget <fgouget(a)free.fr> wrote: > On Tue, 2 Jun 2009, Ben Klein wrote: > >> 2009/6/2 Scott Ritchie <scott(a)open-vote.org>: > [...] >> > First, I talked with a Pulseaudio expert about what we can do to make >> > things work better. He said that if we want good compatibility we will >> > need our ALSA stack to use the Pulseaudio safe subset: >> > http://0pointer.de/blog/projects/guide-to-sound-apis.html. I've filed a >> > metabug tracking this here: >> > http://bugs.winehq.org/show_bug.cgi?id=18740. Use of this unsafe subset >> > can cause most problems with stuttering or even complete dropoff. >> >> As far as I know, this is not possible for Wine (without massive >> latency issues caused by overbuffering in Wine itself) due to the fact >> that Wine has to make DirectSound apps happy. > > Which of the DONTs are causing problems for Wine? (And why?) > It would be nice to identify them to be able to send argumented feedback > to the PulseAudio developers. > > > -- > Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ > tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY > > > I have quickly checked the code and this are I think some of the 'easy' DONTs we violate: - we use snd_config_xxx(), this is replaceable by snd_device_name_hint() - we use snd_card_xxx(), this can be replaced by snd_device_name_hint() - we hard code device strings (e.g. plughw0) - we use snd_pcm_avail_update and snd_pcm_delay (there might be some more but those are less trivial to check) The most critical are the following: - Do not assume that all devices support MMAP style buffer access. - Do not assume that the hardware pointer inside the (possibly mmaped) playback buffer is the actual position of the sample in the DAC. There might be an extra latency involved. - Do not try to recover with your own code from ALSA error conditions such as buffer under-runs. Use snd_pcm_recover() instead. - Do not touch buffering/period metrics unless you have specific latency needs. Develop defensively, handling correctly the case when the backend cannot fulfill your buffering metrics requests. Be aware that the buffering metrics of the playback buffer only indirectly influence the overall latency in many cases. i.e. setting the buffer size to a fixed value might actually result in practical latencies that are much higher. Especially the first one direct sound is all about direct card access and hence mmap .. Roderick

June 2, 2009

Re: Implications for Wine from the Ubuntu Developer Summit

by Francois Gouget

On Tue, 2 Jun 2009, Ben Klein wrote: > 2009/6/2 Scott Ritchie <scott(a)open-vote.org>: [...] > > First, I talked with a Pulseaudio expert about what we can do to make > > things work better. He said that if we want good compatibility we will > > need our ALSA stack to use the Pulseaudio safe subset: > > http://0pointer.de/blog/projects/guide-to-sound-apis.html. I've filed a > > metabug tracking this here: > > http://bugs.winehq.org/show_bug.cgi?id=18740. Use of this unsafe subset > > can cause most problems with stuttering or even complete dropoff. > > As far as I know, this is not possible for Wine (without massive > latency issues caused by overbuffering in Wine itself) due to the fact > that Wine has to make DirectSound apps happy. Which of the DONTs are causing problems for Wine? (And why?) It would be nice to identify them to be able to send argumented feedback to the PulseAudio developers. -- Francois Gouget <fgouget(a)free.fr> http://fgouget.free.fr/ tcA thgirypoC muinelliM latigiD eht detaloiv tsuj evah uoY

June 2, 2009

Re: Fw: Need a temporary list moderator

by Daniel Devine

On Tuesday 02 June 2009 00:42:13 Stefan Leichter wrote: > Am Monday 01 June 2009 16:13:43 schrieb Luke Bratch: > > --- On Thu, 28/5/09, Luke Bratch <l_bratch(a)yahoo.co.uk> wrote: > > > In a couple of weeks I'm going to be travelling around > > > India for about a month, from 14th June - 17th July, so I'll > > > need somebody to cover list moderation during that period. > > > > > > It's a simple task; you just need to bring up a web page > > > for each list a couple of times per day, and single out any > > > genuine messages that are awaiting approval, discarding the > > > rest. > > > > > > You'll need to do it almost every day for the whole month, > > > otherwise people will start to wonder where their mail is > > > getting to.... :) > > > > > > If you are interested, please email me directly. > > > > No responses so far - anybody? > > > > Luke > > Hi Luke, > > i can do parts of the job but not all. I can't do it before the 16th June, > and i know for sure that i have at least one business trip (two days) > during the rest of the time, but i can't say now when it will be. > > Stefan I'm not sure I could commit to it for a whole month, though I could definitely commit to two or more days while Stefan is on business trips. If a bit of help is needed I can do it. I have no experience at all in list moderation and this is the reason I would not do a whole month on my own. There is documentation for MailMan on the MailMan website, so any questions should be fairly easy to answer :)

June 2, 2009

Re: gdiplus: add support for string alignment to GdipDrawString

by Paul Vriens

Stephan Rose wrote: > Adds support for aligning a string inside the given bounding rectangle > for GdipDrawString. Both vertical and horizontal alignments implemented. > > > ------------------------------------------------------------------------ > > Hi Stephan, No remarks about the real contents of the patch (not my area of expertise). You are mixing tabs and spaces in this patch. This file uses 4 space indentation, please stick to that. The use of curly brackets is also not consistent. Looks like the rest of the file puts the opening curly bracket right after the closing round bracket (not even a space in between), like you do here: + if(format){ but a bit further you do: + if(format->vertalign != StringAlignmentNear) + { Usually when patches are created, one should try to adhere to the style of the file touched. -- Cheers, Paul.

June 2, 2009

Re: Implications for Wine from the Ubuntu Developer Summit

by Daniel Devine

On Tuesday 02 June 2009 11:26:36 Scott Ritchie wrote: > Hello everyone, > > I've just returned from the Ubuntu Developer Summit in Barcelona last > week. A lot of interesting stuff that concerns Wine happened there, and > a lot of applies to every distro. I'll give a brief summary in this email. > > Audio: > > First, I talked with a Pulseaudio expert about what we can do to make > things work better. He said that if we want good compatibility we will > need our ALSA stack to use the Pulseaudio safe subset: > http://0pointer.de/blog/projects/guide-to-sound-apis.html. I've filed a > metabug tracking this here: > http://bugs.winehq.org/show_bug.cgi?id=18740. Use of this unsafe subset > can cause most problems with stuttering or even complete dropoff. > > I'm not completely familiar with how sound works in Wine, but in the > past I remember that one complaint about PulseAudio over ALSA was > latency. Latency issues these days are mostly due to bad kernel > configurations, which Lennart wrote about here: > https://tango.0pointer.de/pipermail/pulseaudio-discuss/2009- February/003150 >.html. > > In the meantime we should develop for the future using kernels with > preempt enabled at 1000 HZ. Currently neither Open SuSE nor Ubuntu are > configured this way, however I know in the case of Ubuntu that this is > being fixed for next release. In particular, if you develop on Ubuntu, > you should either upgrade to Karmic Alphas or install a custom kernel. > The -rt flavor of the kernel is known to have problems as well. > > Printing: > > A printing expert from http://openprinting.org says we should output > .pdf files to cups rather than postscript. .pdf are becoming the > standard for printers, and apparently they allow some good things that > postscript does not. I've filed a bug on this here: > http://bugs.winehq.org/show_bug.cgi?id=18741 > > Security and Usability: > > The security team thinks we should finally start respecting the execute > bit - this means removing all MIME handlers for executable code from the > desktop and replacing them with a single front end for programs lacking > the execute bit. This front end would notify the user of the problem, > scan the file for viruses, and then present some information about the > path towards execution. It is still undecided whether the program > should allow execution outright, however from a UI perspective this > would clearly be more efficient. > > This creates a design challenge. In brief, we have to simultaneously > manage expectations about Wine, inform the user that there are other > (preferred) methods for installing software, not patronize them for > installing a Windows program, tell them we scanned a file for viruses > but that it may still be unsafe, make it easy to use, and make it hard > to use accidentally. > > After input from the community and discussion with other designers, I > believe I have some good ideas for how to handle these challenges. The > Canonical design team has agreed to integrate the UI extensions I've > gathered into their weekly user testing, so over the next few months we > should be getting some real feedback on the merits of various approaches > to this problem. I'll be working more on this personally, and already > have a good chunk of the specifications and front end code done (thanks > to some great community help). I will, of course, share it here when > it's in a usable state. > > As far as we, as an upstream, are concerned, there's not much to change > in Wine itself other than to keep making it work better and fix bugs. > If I had to name one in particular, I'd have to say the "unclean removal > of applications menu" entries is a particularly confusing issue for users. > > What I'm doing: > > Over the next few months I'm going to be working rather hard on the > Karmic Wine Integration spec that I lead at the Summit: > https://wiki.ubuntu.com/karmic-wine-integration. I'm still drafting the > spec based on my notes and discussion, but at this point I have a very > good idea of what I want to do. > > Most of the code involved is directly relevant to the Wine user, however > almost none of it needs to go into Wine itself other than some icons. > At this point it's mostly python scripts, modifications of other python > programs, and Glade dialogs. I may set up a BZR/Git repository of the > various bits once they start turning into actual packages (which I'll > also be doing). > > Anyway, keep your eyes peeled, the next wave of distro releases are > going to be very slick. > > Thanks, > Scott Ritchie Great work so far Scott. In regards to respecting the execute bit, I think that there really has to be a lot of thought put into the UI design so that the users respect the security. We don't want a Windows Vista/7 UAC type complete and utter failure. A dialog reminiscent of UAC will trigger the mindless "I wish this damn thing would stop popping up" *click* *click* *click* Encouraging this type of behavior could be disastrous because it offers a way for malicious people to EASILY engineer an attack on Linux. No doubt you have heard the jokes before about getting viruses to run on Linux and how the virus would need to come with instructions to launch the script/executable... though if the user wants to run CutePuppyPictures.exe you can't really stop them. Users really like to see cute puppies, and if that means installing something then they will. Hopefully we can find a way to make them stop for just a second and think. --Daniel Devine

June 2, 2009

Re: gdiplus: GdipDrawString

by Austin English

On Mon, Jun 1, 2009 at 11:23 PM, Stephan Rose <kermos(a)somrek.net> wrote: > On Mon, 2009-06-01 at 13:03 -0400, Stephan Rose wrote: >> >I don't know why gdiplus does its own linebreaks. I haven't really >> >done any work in that area. >> > >> >If I had to guess, I'd say it's because StringFormatFlagsNoWrap has no >> >equivalent flag for DrawText. That probably means you can't pass it >> >off to DrawText. >> > >> >Since they'll probably have to be done differently, it's best to >> >implement one direction at a time. When you're happy with horizontal >> >alignment, you can send a patch for that regardless of the status of >> >vertical alignment. >> > >> >You should be able to use GdipMeasureString to get the size of the >> >text. In fact, the alignments will need to be implemented there too, >> >and it may be better to start there. >> >> Hmm the only way I can see alignments having any influence on MeasureString would be if the boundingBox of the text is to be aligned to the layoutRect based on the alignment flags. Should just be able to then take the calculated bounding rect and align that to the layout based on the flags. >> >> And you're right, if I use MeasureString I solve my issue where I don't know the height of the text ahead of time. Perfect.] > > > My initial implementation for the string alignment stuff seems to be > working. Haven't done anything inside MeasureString yet (that'll be next > though). > > Here's a screenshot comparing the windows version from the bug report > against my implementation. > > http://www.somrek.net/stringformat.png > > Now how do I go about creating the patch and trying to get this > committed? =) http://wiki.winehq.org/SubmittingPatches -- -Austin

June 2, 2009

Re: gdiplus: GdipDrawString

by Stephan Rose

On Mon, 2009-06-01 at 13:03 -0400, Stephan Rose wrote: > >I don't know why gdiplus does its own linebreaks. I haven't really > >done any work in that area. > > > >If I had to guess, I'd say it's because StringFormatFlagsNoWrap has no > >equivalent flag for DrawText. That probably means you can't pass it > >off to DrawText. > > > >Since they'll probably have to be done differently, it's best to > >implement one direction at a time. When you're happy with horizontal > >alignment, you can send a patch for that regardless of the status of > >vertical alignment. > > > >You should be able to use GdipMeasureString to get the size of the > >text. In fact, the alignments will need to be implemented there too, > >and it may be better to start there. > > Hmm the only way I can see alignments having any influence on MeasureString would be if the boundingBox of the text is to be aligned to the layoutRect based on the alignment flags. Should just be able to then take the calculated bounding rect and align that to the layout based on the flags. > > And you're right, if I use MeasureString I solve my issue where I don't know the height of the text ahead of time. Perfect.] My initial implementation for the string alignment stuff seems to be working. Haven't done anything inside MeasureString yet (that'll be next though). Here's a screenshot comparing the windows version from the bug report against my implementation. http://www.somrek.net/stringformat.png Now how do I go about creating the patch and trying to get this committed? =) Thanks, Stephan

June 2, 2009

Re: Implications for Wine from the Ubuntu Developer Summit

by Scott Ritchie

Ben Klein wrote: > 2009/6/2 Scott Ritchie <scott(a)open-vote.org>: >> First, I talked with a Pulseaudio expert about what we can do to make >> things work better. He said that if we want good compatibility we will >> need our ALSA stack to use the Pulseaudio safe subset: >> http://0pointer.de/blog/projects/guide-to-sound-apis.html. I've filed a >> metabug tracking this here: >> http://bugs.winehq.org/show_bug.cgi?id=18740. Use of this unsafe subset >> can cause most problems with stuttering or even complete dropoff. > > As far as I know, this is not possible for Wine (without massive > latency issues caused by overbuffering in Wine itself) due to the fact > that Wine has to make DirectSound apps happy. It's also not very > consoling from this Pulseaudio expert that they don't seem to see a > problem with the ALSA layer on their end - "it's the apps that need to > be fixed". Wasn't the point of Pulse that you could use libasound/OSS > apps without modification? :) > I'll admit I'm a bit over my head here, but I'd be surprised to find out if a typical DirectSound App on Windows was really as low-latency as we seem to be grabbing for. Windows doesn't generally grant applications direct control over the audio hardware either. >> I'm not completely familiar with how sound works in Wine, but in the >> past I remember that one complaint about PulseAudio over ALSA was >> latency. Latency issues these days are mostly due to bad kernel >> configurations > > PulseAudio will *always* have more latency than ALSA. This has nothing > to do with kernel configurations, just that using a > CONFIG_NO_HZ/CONFIG_HZ_1000 (or whatever it is) kernel from the -rt > tree makes the latency issue less severe. New kernel won't fix Wine + > Pulse problem. > Going from 200 to something like 50 ms latency will solve about 90% of the problem though. This is doable with kernel changes alone (some of the shipping kernels are indeed that bad). >> Printing: >> >> A printing expert from http://openprinting.org says we should output >> .pdf files to cups rather than postscript. .pdf are becoming the >> standard for printers, and apparently they allow some good things that >> postscript does not. I've filed a bug on this here: >> http://bugs.winehq.org/show_bug.cgi?id=18741 > > Something tells me this isn't going to happen soon in Wine :D > It would make a good summer of code project I bet. I agree there are probably more important things to do, though it's hard to recognize what's an important feature when talking about potential rather than current users. Potentially, Wine could be very valuable as a general office tool, where printing is much more important. >> Security and Usability: >> >> The security team thinks we should finally start respecting the execute >> bit - this means removing all MIME handlers for executable code from the >> desktop and replacing them with a single front end for programs lacking >> the execute bit. This front end would notify the user of the problem, >> scan the file for viruses, and then present some information about the >> path towards execution. It is still undecided whether the program >> should allow execution outright, however from a UI perspective this >> would clearly be more efficient. > > This has been discussed before on -devel. I believe the consensus was > "no, we don't want Wine to respect execute bit" (though I'd still like > it to respect noexec mount option if possible). > > The biggest problem with the GUI proposal for confirming execution of > non-+x files as far as I can see is how do we handle a win32 app > launching a non-+x app (as so many installers would be likely to do)? That's simple; we let it. The execute bit is an indicator of trust in an app - once you've trusted it to run then it can do whatever it wants, so we might as well let it run other apps. Wine's pretty good about marking installed apps as +x anyway; this is really mostly an issue with freshly downloaded .exes (note that .exe's on CD drives are going to be assumed +x anyway). > Should that produce a new dialog (thus irritating the user to all > kinds of heck) or should one confirmation per user-controlled app > launch be enough (thus not providing any real benefit)? I don't see how it's "not any real benefit" when the whole point is to prevent accidental launching. You see the prompt the first time, you dismiss it if you didn't mean to run something, and you let it go if you did. In the meantime it's scanned for viruses. Thanks, Scott Ritchie

June 2, 2009

[Fwd: Re: DIB engine]

by James McKenzie

To the list as well. -------- Original Message -------- Subject: Re: DIB engine Date: Mon, 01 Jun 2009 19:09:15 -0700 From: James McKenzie <jjmckenzie51(a)earthlink.net> To: Andrew Eikum <andrew(a)brightnightgames.com> References: <a71bd89a0905301414j5bd70f74y3441d367b49bc5f0(a)mail.gmail.com> <1243755935.4535.1.camel(a)stephan-desktop> <4A22AD55.5020306(a)brightnightgames.com> <b6bb06270905311154w2b9ccb12jee6d64ea587f9524(a)mail.gmail.com> <4A22D65A.3030205(a)brightnightgames.com> Andrew Eikum wrote: > Austin English wrote: >> On Sun, May 31, 2009 at 11:16 AM, Andrew >> <andrew(a)brightnightgames.com> wrote: >> >>> My name's Andrew Eikum, I'm an undergraduate Computer Science >>> student at the >>> University of Minnesota. I contacted a Wine dev a few weeks ago >>> asking for >>> a small project to use to get familiar with Wine. I was pointed >>> towards the >>> gdiplus section and told to begin stubbing out the missing >>> functions, to >>> facilitate debugging. After familiarizing myself with how Wine's >>> DLLs are >>> built, and with Git, I'm now making quick progress. I expect to have a >>> (huge) patchset ready in the next week or two with most of the gdiplus >>> functions stubbed. >>> >>> After that, I plan to begin work on implementing some of the >>> functions. My >>> degree's emphasis is computer graphics, so working on gdiplus will >>> give me a >>> chance to learn more about the field as well as apply what I already >>> know. >>> I'm looking forward to working with other Wine devs on gdiplus, and >>> other >>> parts of Wine in the future. >>> >> >> Welcome to Wine! >> >> Be sure when sending patches to break them into small sets, with one >> change per patch. It makes it much easier to review that way, and if >> your patch causes a regression, much easier to identify which part if >> it's in multiple patches. >> > Thanks for the welcome! > > I am definitely doing small commits and following the WineGit wiki > page. One concern I have is that the number of patches will probably > be over 50 or even 75 -- I'm not sure if it'd be better to submit them > all in one go as they're pretty much all alike (just stubbing), or > just do batches of 5-10 every couple days as I finish them (so it's > not a deluge of patches). Any suggestions? > > > I'll second what Austin said. Please send in like the following: [1/2] Test for some gdiplus Windows function with todo_wine wrapper that demonstrates default Windows function from a source other than reverse-engineering (this is an absolute no-no.) [2/2] Code that implements the default function along with code to remove todo_wine wrapper. This way if your second code breaks something, the test will be in place and the todo_wine wrapper will remain. James McKenzie

June 2, 2009

Re: Implications for Wine from the Ubuntu Developer Summit

by Ben Klein

2009/6/2 Scott Ritchie <scott(a)open-vote.org>: > First, I talked with a Pulseaudio expert about what we can do to make > things work better. He said that if we want good compatibility we will > need our ALSA stack to use the Pulseaudio safe subset: > http://0pointer.de/blog/projects/guide-to-sound-apis.html. I've filed a > metabug tracking this here: > http://bugs.winehq.org/show_bug.cgi?id=18740. Use of this unsafe subset > can cause most problems with stuttering or even complete dropoff. As far as I know, this is not possible for Wine (without massive latency issues caused by overbuffering in Wine itself) due to the fact that Wine has to make DirectSound apps happy. It's also not very consoling from this Pulseaudio expert that they don't seem to see a problem with the ALSA layer on their end - "it's the apps that need to be fixed". Wasn't the point of Pulse that you could use libasound/OSS apps without modification? :) > I'm not completely familiar with how sound works in Wine, but in the > past I remember that one complaint about PulseAudio over ALSA was > latency. Latency issues these days are mostly due to bad kernel > configurations PulseAudio will *always* have more latency than ALSA. This has nothing to do with kernel configurations, just that using a CONFIG_NO_HZ/CONFIG_HZ_1000 (or whatever it is) kernel from the -rt tree makes the latency issue less severe. New kernel won't fix Wine + Pulse problem. > Printing: > > A printing expert from http://openprinting.org says we should output > .pdf files to cups rather than postscript. .pdf are becoming the > standard for printers, and apparently they allow some good things that > postscript does not. I've filed a bug on this here: > http://bugs.winehq.org/show_bug.cgi?id=18741 Something tells me this isn't going to happen soon in Wine :D > Security and Usability: > > The security team thinks we should finally start respecting the execute > bit - this means removing all MIME handlers for executable code from the > desktop and replacing them with a single front end for programs lacking > the execute bit. This front end would notify the user of the problem, > scan the file for viruses, and then present some information about the > path towards execution. It is still undecided whether the program > should allow execution outright, however from a UI perspective this > would clearly be more efficient. This has been discussed before on -devel. I believe the consensus was "no, we don't want Wine to respect execute bit" (though I'd still like it to respect noexec mount option if possible). The biggest problem with the GUI proposal for confirming execution of non-+x files as far as I can see is how do we handle a win32 app launching a non-+x app (as so many installers would be likely to do)? Should that produce a new dialog (thus irritating the user to all kinds of heck) or should one confirmation per user-controlled app launch be enough (thus not providing any real benefit)?

June 2, 2009