WWN Issue 156

This is the 156th release of the Wine's kernel cousin publication. Its main goal is to subvert the dominant paradigm that PC applications must be run on a Microsoft operating system. It also serves to inform you of what's going on around Wine (the Un*x Windows emulator).

This week, 286 posts consumed 926 K. There were 78 different contributors. 42 (53%) posted more than once. 37 (47%) posted last week too.

The top 5 posters of the week were:

37 posts in 135K by Dan Kegel
27 posts in 69K by Dimitrie O. Paun
14 posts in 37K by Sylvain Petreolle
13 posts in 87K by Michael Stefaniuc
10 posts in 25K by Eric Pouech

News: Cross-compiling Windows Apps	02/01/2003	Archive
News This isn't really related to Wine, but you might find it interesting. IBM's developerWorks web site has an article on cross-compiling Windows apps on Linux, The Xmingwin/bin directory includes not just a cross-compiler, but cross-linker, cross-library-manager, and almost two dozen related tools for common developer operations. With a bit of practice, you can generate deliverables for Windows just as easily as you currently do for Linux, probably from the same Makefiles you're already using.

Threading Problems with glibc 2.3 (cont'd) 01/31/2003 Archive

Threading Problems with glibc 2.3 (cont'd)	01/31/2003	Archive
Integration Preface: we began covering this last week in issue #155 The questions about the new threading model that can be enabled in the latest glibc came up again. This time Steven Edwards was wondering about getting Wineserver to run under Cygwin, but the discussion quickly delved into using pthreads for threading. Marcus Meissner once again pointed out the problem with the new threading is going to surface soon, RedHat Phoebe is affected already (is that 8.1?). Shipping soon. Mike Hearn mentioned some other early reports, There were some rumblings on the crossover users list, so I think it's safe to assume Phoebe is a no go However, Phil Bordelon said his Gentoo distribution with glibc 2.3.1 wasn't affected. Michael Stefaniuc explained that it was a combination of a new kernel and glibc that caused the trouble, you need also an nptl enabled kernel to enable the new threading model. This would be an actual 2.5 kernel or a 2.4 kernel from Red Hat's Rawhide or Phoebe. People began questioning exactly what needed to be changed how long it would take. Dimi Paun pointed out, I know Ingo Molnar has been (one of) the main developer working on the glibc threading stuff, and I also know he used to follow the Wine project. I am sure he's not indifferent to our fate, and being so deeply involved with the glibc changes, he's probably an invaluable resource. Unfortunately, I'm not sure he's even aware of the problem -- has anyone contacted him? Anyone want to do so? (Dan? :)) Michael discovered this issue had been recognized months ago, To resolve any doubts that Ingo isn't taking care of wine read this: http://lwn.net/Articles/6972/ Michael also seems to have contacted Ingo privately and gotten the following reply: here is Ingo's answer: `could you try: export LD_ASSUME_KERNEL=2.2.5 prior starting up Wine, does this fix the problem for you?` Francois Gouget reported, According to reports on the CrossOver mailing lists this works on Phoebe 1 but does not work anymore on Phoebe 2. Also it causes Wine to fail on some platforms like SuSE 8.1 so it should not be blindly set. Michael did some testing and found that particular kernel had a problem with signals and that it had already been replaced in the latest Rawhide repository. Testing with the even newer kernel worked as expected. Chris Tooley offered another workaround involving a small library. Apparently Wine isn't the only program affected, there was a workaround on the vmware newsgroup (vmware is afflicted with a similar disease) that preloads a small .so to make it work. This might be useful for some people. I've used it with some success on my installation of wine. Marcus noted that solution wouldn't work in all cases though either. Then Marcus, Eric Pouech, and Ulrich Weigand started an exchange on the exact problems faced and how capabilities of the new threading model could be exploited. Eric started with: among the things we have to take care of: signals: signal, in current implementation, is sent to a thread. in nptl, it's sent to the process. So, lots of thread control has to be rewritten in the same type of issues, getpid() now returns the same pid for all threads in a same process. Most of Wine code relies on having a different pid for each thread (this fix is needed, IIRC, for some Solaris port) from what I've seen, the LDT/GDT with nptl should be easier: for Win32 processes, as Ulrich already wrote, we could got rid of LDT (and only rely on GDT) for %fs and TEB allocation for Win16 processes, we would still require LDT sharing across pthreads, which I don't how it's handled right now and it's likely there are quite a few other items I forgot (I'll attempt to add some explanation, but I'm pretty stupid when it comes to memory management. LDT is the "local descriptor table" in Linux for user space. Every task has one LDT. GDT is the "global descriptor table" for kernel space. TEB is more of a Windows concept - "thread environment block".) As far as thread control goes, Ulrich dug around and discovered, in the Linux / glibc 2.3.x case, there's a new gettid call that returns a 'thread ID' that used to be the pid, and a new tkill system call that can be used to send a signal to one TID, just like the old Linux kill would send a signal to a specific thread. I think using those we could carry over our old Linux-specific hacks one to one, and it still should work even if our threads are glibc 2.3.x pthreads. Notably absent from the thread was Alexandre. He jumped in to add, I've been in touch with Ingo, and I'm looking into the issue. However I'm currently moving, so things are a bit hectic around here, and I don't have good internet access. Hopefully things will settle down a bit soon so that I can get some real work done... Look for the thread to continue for a while.

Integration

Preface: we began covering this last week in issue #155

The questions about the new threading model that can be enabled in the latest glibc came up again. This time Steven Edwards was wondering about getting Wineserver to run under Cygwin, but the discussion quickly delved into using pthreads for threading. Marcus Meissner once again pointed out the problem with the new threading is going to surface soon, RedHat Phoebe is affected already (is that 8.1?). Shipping soon.

Mike Hearn mentioned some other early reports, There were some rumblings on the crossover users list, so I think it's safe to assume Phoebe is a no go

However, Phil Bordelon said his Gentoo distribution with glibc 2.3.1 wasn't affected. Michael Stefaniuc explained that it was a combination of a new kernel and glibc that caused the trouble, you need also an nptl enabled kernel to enable the new threading model. This would be an actual 2.5 kernel or a 2.4 kernel from Red Hat's Rawhide or Phoebe.

People began questioning exactly what needed to be changed how long it would take. Dimi Paun pointed out, I know Ingo Molnar has been (one of) the main developer working on the glibc threading stuff, and I also know he used to follow the Wine project. I am sure he's not indifferent to our fate, and being so deeply involved with the glibc changes, he's probably an invaluable resource. Unfortunately, I'm not sure he's even aware of the problem -- has anyone contacted him? Anyone want to do so? (Dan? :))

Michael discovered this issue had been recognized months ago, To resolve any doubts that Ingo isn't taking care of wine read this: http://lwn.net/Articles/6972/

Michael also seems to have contacted Ingo privately and gotten the following reply:

here is Ingo's answer:


could you try:

         export LD_ASSUME_KERNEL=2.2.5


 prior starting up Wine, does this fix the problem for you?

Francois Gouget reported, According to reports on the CrossOver mailing lists this works on Phoebe 1 but does not work anymore on Phoebe 2. Also it causes Wine to fail on some platforms like SuSE 8.1 so it should not be blindly set.

Michael did some testing and found that particular kernel had a problem with signals and that it had already been replaced in the latest Rawhide repository. Testing with the even newer kernel worked as expected.

Chris Tooley offered another workaround involving a small library. Apparently Wine isn't the only program affected, there was a workaround on the vmware newsgroup (vmware is afflicted with a similar disease) that preloads a small .so to make it work. This might be useful for some people. I've used it with some success on my installation of wine.

Marcus noted that solution wouldn't work in all cases though either. Then Marcus, Eric Pouech, and Ulrich Weigand started an exchange on the exact problems faced and how capabilities of the new threading model could be exploited. Eric started with:

among the things we have to take care of:

signals: signal, in current implementation, is sent to a thread. in nptl, it's sent to the process. So, lots of thread control has to be rewritten
in the same type of issues, getpid() now returns the same pid for all threads in a same process. Most of Wine code relies on having a different pid for each thread (this fix is needed, IIRC, for some Solaris port)

from what I've seen, the LDT/GDT with nptl should be easier:

for Win32 processes, as Ulrich already wrote, we could got rid of LDT (and only rely on GDT) for %fs and TEB allocation
for Win16 processes, we would still require LDT sharing across pthreads, which I don't how it's handled right now

and it's likely there are quite a few other items I forgot

(I'll attempt to add some explanation, but I'm pretty stupid when it comes to memory management. LDT is the "local descriptor table" in Linux for user space. Every task has one LDT. GDT is the "global descriptor table" for kernel space. TEB is more of a Windows concept - "thread environment block".)

As far as thread control goes, Ulrich dug around and discovered, in the Linux / glibc 2.3.x case, there's a new gettid call that returns a 'thread ID' that used to be the pid, and a new tkill system call that can be used to send a signal to one TID, just like the old Linux kill would send a signal to a specific thread. I think using those we could carry over our old Linux-specific hacks one to one, and it still should work even if our threads are glibc 2.3.x pthreads.

Notably absent from the thread was Alexandre. He jumped in to add, I've been in touch with Ingo, and I'm looking into the issue. However I'm currently moving, so things are a bit hectic around here, and I don't have good internet access. Hopefully things will settle down a bit soon so that I can get some real work done...

Look for the thread to continue for a while.

RPC Data Marshalling (cont'd)	01/30/2003	Archive
Documentation RPC / COM / OLE Last week I covered a thread where Greg Turner talked about figuring out to make remote procedure calls communicate over the wire. I left out the last paragraph of Greg's post where he mentioned, Combined with the pseudo-documentation of the format strings from MSDN, the Microsoft headers and MIDL output, the DCERPC source, tcpdump, etc., there's enough comprehensible clues out there to actually accomplish something -- it still feels pretty sparse to me, but I guess there's nothing I can do about that but forge ahead (or maybe shell out for the DCE package :) ) Following that, Dimi Paun replied with an offer: The DCE package is like $400USD. Not that bad. Maybe we can put some money togther (what about the Party Fund, that would be a good use of that money), and buy the DCE docs for the Wine project. I contribute $40USD, if other contribute to make the 400. Pretty soon others joined in to reach the goal. The following people offering to donate some of their personal cash to get the docs: Dimitrie O. Paun Michael Stefaniuc Nick Capik Tom Wickline Gregory M. Turner Sylvain Petreolle Dan Kegel John Alvord Kirk Ruff A little impasse was reached on how exactly the money could be donated though - especially for folks not in the United States. Jeremy White posted a note about formalizing it: I'm filing papers (on a personal basis ) in Minnesota to do business as 'The Wine Project', and I've opened a personal account with the name 'The Wine Project', and I'm a few days away from having a PayPal button all ready to go to accept donations. You can thank Tom for this; he's the one that harangued me into it <grin>. I think I've mostly held up in the past because we didn't have anything to spend money on. However, Tom has pointed out that we can use the money to fund travel for a WineConf 2003, and this also sounds like a worthy cause. That led into the next thread...

RPC Data Marshalling (cont'd)

01/30/2003

Archive

Documentation RPC / COM / OLE

Last week I covered a thread where Greg Turner talked about figuring out to make remote procedure calls communicate over the wire. I left out the last paragraph of Greg's post where he mentioned, Combined with the pseudo-documentation of the format strings from MSDN, the Microsoft headers and MIDL output, the DCERPC source, tcpdump, etc., there's enough comprehensible clues out there to actually accomplish something -- it still feels pretty sparse to me, but I guess there's nothing I can do about that but forge ahead (or maybe shell out for the DCE package :) )

Following that, Dimi Paun replied with an offer:

The DCE package is like $400USD. Not that bad. Maybe we can put some money togther (what about the Party Fund, that would be a good use of that money), and buy the DCE docs for the Wine project.

I contribute $40USD, if other contribute to make the 400.

Pretty soon others joined in to reach the goal. The following people offering to donate some of their personal cash to get the docs:

Dimitrie O. Paun
Michael Stefaniuc
Nick Capik
Tom Wickline
Gregory M. Turner
Sylvain Petreolle
Dan Kegel
John Alvord
Kirk Ruff

A little impasse was reached on how exactly the money could be donated though - especially for folks not in the United States. Jeremy White posted a note about formalizing it:

I'm filing papers (on a personal basis ) in Minnesota to do business as 'The Wine Project', and I've opened a personal account with the name 'The Wine Project', and I'm a few days away from having a PayPal button all ready to go to accept donations.

You can thank Tom for this; he's the one that harangued me into it <grin>.

I think I've mostly held up in the past because we didn't have anything to spend money on. However, Tom has pointed out that we can use the money to fund travel for a WineConf 2003, and this also sounds like a worthy cause.

That led into the next thread...

PayPal Link	02/03/2003	Archive
Project Management Jeremy White wrote in to announce a link he set up for donations: There is now a PayPal donations link up at www.winehq.org ; donations there go into a bank account I opened under the name "The Wine Project". I promise to only embezzle small, unnoticeable amounts of the funds <grin>. We should probably decide what we want to use this money for; I'm happy to send of for the DCE package as soon as the $400 accumulates (or to reimburse someone else). Beyond that, I think Tom is right - we should fund a periodic conference. But I'll start a new thread for that. What? A conference? Read on...

PayPal Link

02/03/2003

Archive

Project Management

Jeremy White wrote in to announce a link he set up for donations:

There is now a PayPal donations link up at www.winehq.org ; donations there go into a bank account I opened under the name "The Wine Project".

I promise to only embezzle small, unnoticeable amounts of the funds <grin>.

We should probably decide what we want to use this money for; I'm happy to send of for the DCE package as soon as the $400 accumulates (or to reimburse someone else).

Beyond that, I think Tom is right - we should fund a periodic conference. But I'll start a new thread for that.

What? A conference? Read on...

WineConf 2003?	02/03/2003	Archive
Project Management Last year's WineConf 2002 gathered 30 of Wine's most active developers together. By most accounts, it was quite successful. Jeremy decided to ask what everyone would think of having another: I think we should have another WineConf. The last one was a blast, and I think helped lead to a really great 2002 for Wine. However, I'm not wealthy enough to fly everyone around the world. Maybe next year <grin>. But just because Lindows isn't going to pay for it doesn't mean we can't get together. Assuming we have another WineConf, the main questions are where and when? For where, I would think it's time to hold it in Europe. On the other hand, if we hold it in St. Paul, I would be happy to arrange (and pay for) a conference site. It would also let a lot more of us CodeWeavers make it. Also, it would seem to make sense to hold it in conjunction with a Linux conference; that would probably make it easier for others to do the travel. Thoughts? Comments? People began tossing around ideas for European conferences. Dan Kegel: How about we hold it as a satellite conference to LinuxTag, Karlsruhe, Germany, 10-13 July 2003? LinuxTag is a very big, very cool event. See http://www.linuxtag.org/2003/en/conferences/cfp.html I suppose the Linux Summit in Finland in Febrary is another possibility: http://www.sot.com/en/sot/summit2003.shtml but it's a much smaller (and colder!) show, and there isn't really enough time before then to prepare. Uwe Bonnes: Another event is Linux Kongress. In the last years, some funding by the german government was available for special interest groups. We already had a get together with that money 1999 in Erlangen. Keith Matthews There is also the Linux Developers Conference (run by UK Unix Users Group) in Edinburgh at the beginning of August. Might be an opportunity for someone to get to see the festival cheap.

WineConf 2003?

02/03/2003

Archive

Project Management

Last year's WineConf 2002 gathered 30 of Wine's most active developers together. By most accounts, it was quite successful. Jeremy decided to ask what everyone would think of having another:

I think we should have another WineConf.

The last one was a blast, and I think helped lead to a really great 2002 for Wine.

However, I'm not wealthy enough to fly everyone around the world. Maybe next year <grin>. But just because Lindows isn't going to pay for it doesn't mean we can't get together.

Assuming we have another WineConf, the main questions are where and when?

For where, I would think it's time to hold it in Europe.

On the other hand, if we hold it in St. Paul, I would be happy to arrange (and pay for) a conference site. It would also let a lot more of us CodeWeavers make it.

Also, it would seem to make sense to hold it in conjunction with a Linux conference; that would probably make it easier for others to do the travel.

Thoughts? Comments?

People began tossing around ideas for European conferences.

Dan Kegel:

How about we hold it as a satellite conference to LinuxTag, Karlsruhe, Germany, 10-13 July 2003? LinuxTag is a very big, very cool event. See http://www.linuxtag.org/2003/en/conferences/cfp.html

I suppose the Linux Summit in Finland in Febrary is another possibility: http://www.sot.com/en/sot/summit2003.shtml but it's a much smaller (and colder!) show, and there isn't really enough time before then to prepare.

Uwe Bonnes:

Another event is Linux Kongress. In the last years, some funding by the german government was available for special interest groups. We already had a get together with that money 1999 in Erlangen.

Keith Matthews

There is also the Linux Developers Conference (run by UK Unix Users Group) in Edinburgh at the beginning of August. Might be an opportunity for someone to get to see the festival cheap.

ReactOS v0.1	02/01/2003	Archive
Ports Steven Edwards posted a message letting the Wine developers know ReactOS had its first release. ReactOS is intended to function as a drop in replacement for those operating systems from Redmond. Just wanted to let everyone know that we've hit our first major milestone with ReactOS. I don't have the changelog in front of me but to some it up here it the list that I know off the top of my head. Self-hosted builds now works CD-booting/Installing Simple Windowing (User32 Code adapted from WINE) More MS_VC applicaton/driver support Started implementing support for WINE dlls Better Networking support (TCP still broken) Once WINE hits 1.x we will again take a snapshot of your tree so we have standard debugging interfaces. Right now in or tree we don't use libwine but have our own dll that implements the debug channels. We also still need to adapt a lot of the controls from WINE for our user32. Thanks for all the help Regarding adapting the controls, he explained in more detail, ATM I think wines comctl32 and shlwapi work under WindowsNT so once ReactOS gets a little more fine tuned we should have no problems using them. There are still some issues with the commdlg32 and shell32 + everything else but we are working on it. Right now the big thing is to compleate our user32/Win32K and then we can make better use of the WINE code. I am trying to get the rest of the ReactOS people to also use the WINE regression test framework for our test suite so we can share that also. Rest assured any fixes or new features will find their way back in to the main wine tree.

ReactOS v0.1

02/01/2003

Archive

Ports

Steven Edwards posted a message letting the Wine developers know ReactOS had its first release. ReactOS is intended to function as a drop in replacement for those operating systems from Redmond.

Just wanted to let everyone know that we've hit our first major milestone with ReactOS. I don't have the changelog in front of me but to some it up here it the list that I know off the top of my head.

Self-hosted builds now works
CD-booting/Installing
Simple Windowing (User32 Code adapted from WINE)
More MS_VC applicaton/driver support
Started implementing support for WINE dlls
Better Networking support (TCP still broken)

Once WINE hits 1.x we will again take a snapshot of your tree so we have standard debugging interfaces. Right now in or tree we don't use libwine but have our own dll that implements the debug channels. We also still need to adapt a lot of the controls from WINE for our user32.

Thanks for all the help

Regarding adapting the controls, he explained in more detail, ATM I think wines comctl32 and shlwapi work under WindowsNT so once ReactOS gets a little more fine tuned we should have no problems using them. There are still some issues with the commdlg32 and shell32 + everything else but we are working on it. Right now the big thing is to compleate our user32/Win32K and then we can make better use of the WINE code. I am trying to get the rest of the ReactOS people to also use the WINE regression test framework for our test suite so we can share that also. Rest assured any fixes or new features will find their way back in to the main wine tree.

Windows API Database (cont'd)	02/03/2003	Archive
Documentation I guess this is the week of continuing threads. Dave Miller got to work on creating a "database" (or at least at this point a list) of how various Windows DLLs relate to each other. For the most part the data has been collected, now it's just a matter of putting it into a human-readable format: I've begun cross referencing the windows dlls in a 'map' format as Dan Kegel suggested. I'm not finished yet because it seems when I sort alphabetically I am sorting the entire path. Sample output is here: http://home.ptd.net/~compsol/ Be aware though this HTML is around 900K. If anyone has comments or suggestions on how to improve it or the next logical step please let me know. There's definitely a lot of useful data in there. But for now it just has what DLLs are being imported by another DLL. Several people had ideas for how to represent it. Dimi Paun suggested: Sure, here are my suggestions (in order of importance): Transform the output to a matrix (a square matrix, a DLL per row & column, the entry at row r and column c gets an X if the DLL on row r imports the DLL in column c. Get rid of the path from the DLL filenames, it's useless, and it eats up space. That is, just say userenv.dll instead of c:\windows\system32/userenv.dll. Get rid of the .dll extension for similar reasons. Remove the columns from the matrix that have no X's. Order columns by order of importance. That is, the ones with more X's come first. Shachar Shemesh had some ideas for how to go about ranking the number of imports done by a DLL in order to make the resulting matrix more organized. Dan Kegel wanted, two numbers next to each line: the number of libs imported directly and indirectly by the named file. That would give some idea of "distance from the core".

Windows API Database (cont'd)

02/03/2003

Archive

Documentation

I guess this is the week of continuing threads. Dave Miller got to work on creating a "database" (or at least at this point a list) of how various Windows DLLs relate to each other. For the most part the data has been collected, now it's just a matter of putting it into a human-readable format:

I've begun cross referencing the windows dlls in a 'map' format as Dan Kegel suggested. I'm not finished yet because it seems when I sort alphabetically I am sorting the entire path. Sample output is here:

http://home.ptd.net/~compsol/

Be aware though this HTML is around 900K. If anyone has comments or suggestions on how to improve it or the next logical step please let me know.

There's definitely a lot of useful data in there. But for now it just has what DLLs are being imported by another DLL. Several people had ideas for how to represent it. Dimi Paun suggested:

Sure, here are my suggestions (in order of importance):

Transform the output to a matrix (a square matrix, a DLL per row & column, the entry at row r and column c gets an X if the DLL on row r imports the DLL in column c.
Get rid of the path from the DLL filenames, it's useless, and it eats up space. That is, just say userenv.dll instead of c:\windows\system32/userenv.dll.
Get rid of the .dll extension for similar reasons.
Remove the columns from the matrix that have no X's.
Order columns by order of importance. That is, the ones with more X's come first.

Shachar Shemesh had some ideas for how to go about ranking the number of imports done by a DLL in order to make the resulting matrix more organized. Dan Kegel wanted, two numbers next to each line: the number of libs imported directly and indirectly by the named file. That would give some idea of "distance from the core".

GDI Performance	02/03/2003	Archive
Graphics Hetz Ben Hamo asked: I'm testing some apps installation with either the free WineHQ, WineX, CrossOver Office, and many times I see buttons and other GUI related stuff in the wrong size or place, and I understand it's a GDI related issue, so here's 3 questions.. Is the GDI implementation is so bad that it needs hacking per app to make it look ok? Is there a way to take GDI parts from native WIndows and use it in Wine? Funding - can any company (transgaming, CodeWeavers, others) can estimate the cost of rewriting a better (and faster - the speed of Wine graphics today is something in magnitude of 486 PC!) GDI? Dimi Paun thought the problem might be in the X driver or the controls. Mike Hearn felt most of the apps he ran had perfectly acceptable performance and wanted to know if this was a real world problem. Then he went on to test it himself: Well, I just tried a simple comparison of the Adobe SVG plugin under Wine and IE6 on Windows XP. Wine _is_ slower by a visible amount when doing repeated bitblts such as the plugin does on an animation I have, but it's certainly not something that'd actually affect real world usage. I don't think GDI performance is really an issue at present, most apps don't do these kind of repeated double-buffer switches (i assume flash doesn't actually use the gdi to render into its backbuffer?) so it only affects apps like photoshop and director/flash. In particular when I run the SVG plugin, I can see a FIXME talking about a potential optimization, so really the issue is just a case of elbow grease for optimizations (esp in bitblt) rather than a rewrite I'd guess. Not much more was discussed. I guess it ranks as a known area of optimization, but not exactly a high priority. Johan Gill did mention he had plans of looking at it, I'm looking at fixing up the DIBSection handling. Will probably submit something this year at least :)

GDI Performance

02/03/2003

Archive

Graphics

Hetz Ben Hamo asked:

I'm testing some apps installation with either the free WineHQ, WineX, CrossOver Office, and many times I see buttons and other GUI related stuff in the wrong size or place, and I understand it's a GDI related issue, so here's 3 questions..

Is the GDI implementation is so bad that it needs hacking per app to make it look ok?
Is there a way to take GDI parts from native WIndows and use it in Wine?
Funding - can any company (transgaming, CodeWeavers, others) can estimate the cost of rewriting a better (and faster - the speed of Wine graphics today is something in magnitude of 486 PC!) GDI?

Dimi Paun thought the problem might be in the X driver or the controls. Mike Hearn felt most of the apps he ran had perfectly acceptable performance and wanted to know if this was a real world problem. Then he went on to test it himself:

Well, I just tried a simple comparison of the Adobe SVG plugin under Wine and IE6 on Windows XP. Wine _is_ slower by a visible amount when doing repeated bitblts such as the plugin does on an animation I have, but it's certainly not something that'd actually affect real world usage. I don't think GDI performance is really an issue at present, most apps don't do these kind of repeated double-buffer switches (i assume flash doesn't actually use the gdi to render into its backbuffer?) so it only affects apps like photoshop and director/flash.

In particular when I run the SVG plugin, I can see a FIXME talking about a potential optimization, so really the issue is just a case of elbow grease for optimizations (esp in bitblt) rather than a rewrite I'd guess.

Not much more was discussed. I guess it ranks as a known area of optimization, but not exactly a high priority. Johan Gill did mention he had plans of looking at it, I'm looking at fixing up the DIBSection handling. Will probably submit something this year at least :)

World Wine News