June 2010 - Wine-devel - list.winehq.org

DIBEngine and gdi32/user32 controls drawing loop performance
by Amico Amico 20 Jun '10

20 Jun '10

Hello, since I had a poor performance in drawing many buttons and text input fields at the same time into a window with wine, I applied the DIBEngine patch (http://wiki.winehq.org/DIBEngine) that is available for wine 1.1.44 (http://bugs.winehq.org/attachment.cgi?id=27879) to the 1.1.44 version of wine and started my application program that needs to draw many button and text input fields in a single window with the enviroment variable "WINEDIB=ON wine ./App.exe". Now that the DIBEngine patch is applied a little speedup in the drawing of the buttons and the text input fields is shown, but now the problem is that they are still drawn in blocks of a subset of the total number and then wine waits a little bit, then it draws another block of text input fields and buttons and then wine still waits, then it draws, and so on. The result is that my App.exe application window that is full of buttons and text input fields is drawn in subsequent times, and groups of buttons and input fields are drawn in blocks with a delay between the drawing of a group of controls and the others. The fact that not all the controls are drawn at a time but in more times is frustrating, since the CPU is a core2duo, and I think that it is powerful enough to draw all of the controls in the window at a time, specially with the DIBEngine patch applied and the DIBEngine activated. So I thought that the problem could be in the main event loop that manages the App.exe application window, and in particular the problem could be that the loop yields the drawing of the controls after a certain number of controls have been drawn in order to avoid CPU high load and then the loop starts again to draw other controls after a while and then it stops and yields and waits again, and so on. Where can I modify such a behaviour? In particular my App.exe program use many gdi32 drawing commands for drawing buttons and text input fields, so the files dlls/user32/button.c and dlls/user32/edit.c are involved. I think that the dlls/user32/winproc.c file, where the Code: LRESULT WINAPI EditWndProcA( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam ) { return wow_handlers.edit_proc( hwnd, msg, wParam, lParam, FALSE ); } function is defined is the file where I should do some changes; this function calls Code: LRESULT EditWndProc_common( HWND hwnd, UINT msg, WPARAM wParam, LPARAM lParam, BOOL unicode ) that is implemented in the dlls/user32/edit.c file, but the fact is that in the EditWndProc_common function there are many cases like this one that manages the various edit messages and window messages sent Code: switch (msg) { case EM_GETSEL: result = EDIT_EM_GetSel(es, (PUINT)wParam, (PUINT)lParam); break; .... and I don't know how to modify the fact that the main loop of the window should handle more messages in order to draw all of the controls at a time and that it should not yield for waiting and then starting drawing again after some time. What can I do? Thanks in advance, AmoxT _________________________________________________________________ Taglia i costi. Chiama e videochiama da Messenger http://www.messenger.it/videoconversazioni.aspx

2 1

[RFC] gameux.dll implementation stub [try 2]
by Mariusz Pluciński 20 Jun '10

20 Jun '10

Hi I fixed noted problems with my initial implementation of gameux.dll. The code freeze is still the fact, but I hope for some feedback. Thanks

3 2

new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs
by Dan Kegel 20 Jun '10

20 Jun '10

Another month, another Winetricks. Online as always at http://kegel.com/wine/winetricks or http://winezeug.googlecode.com (Bug reports to the issue tracker at the above URL, please.) Changes: Dan Kegel Add dxsdk_nov2006, document how to use it etc. at http://kegel.com/wine/cl-howto-win7sdk.html directx9: override dxdiag.exe, too Update divx sha1sum Andrew Nguyen Add windowscodecs Jeff Zaroyko Fix vjrun20 path in non-quiet mode Austin English Update OpenWatcom to version 1.9

6 7

gnome-exe-thumbnailer -- using embedded icons for .exe and .dll files
by Scott Ritchie 20 Jun '10

20 Jun '10

Screenshot/blog here: http://yokozar.org/blog/archives/225 A bug was fixed recently in Gnome that allows thumbnailers to not be 96x96 pixels. Combine this with a standard Wine icon, icoutils for extracting an exe/dll's embedded icon, and a bit of magic and you can get icons like those above. The version numbers come from the .exe metadata. I think it's really slick, and will try and have it installed by default with Wine 1.2. At the moment it exists as thumbnailer code for Gnome, which means other desktops won't benefit, however provided they can be told to run a script to generate an icon it should be fairly easy to port. Code is available in the gnome-exe-thumbnailer source package here: https://edge.launchpad.net/~ubuntu-wine/+archive/ppa Please note that this is an updated version of the proof of concept gnome-exe-thumbnailer package I put in Lucid (which is ugly and uses the overly large 96x96 icons, and is thus not default and has so far gone unnoticed). Thanks, Scott Ritchie

3 4

Re: [PATCH 3/3] shdocvw: Return IHTMLDocument2's IDispatch in get_Document.
by testbot＠testbot.winehq.org 19 Jun '10

19 Jun '10

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=2780 Your paranoid android. === WXPPROSP3 (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === W2K3R2SESP2 (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === WVISTAADM (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === W2K8SE (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === W7PRO (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === W7PROX64 (32 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex === W7PROX64 (64 bit htmldoc) === htmldoc.c:4524: Test failed: disp != dispex htmldoc.c:4524: Test failed: disp != dispex

1 0

Re: [PATCH 3/3] shdocvw: Return IHTMLDocument2's IDispatch in get_Document.
by testbot＠testbot.winehq.org 19 Jun '10

19 Jun '10

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=2779 Your paranoid android. === W98SE (32 bit webbrowser) === webbrowser.c:1216: Test failed: unexpected call UpdateUI webbrowser.c:295: Test failed: unexpected nsCmdID 21 webbrowser.c:239: Test failed: unexpected call QueryStatus_STOP === WNT4WSSP6 (32 bit webbrowser) === webbrowser.c:2485: Test failed: CoCreateInterface failed: 80040154 webbrowser.c:2485: Test failed: CoCreateInterface failed: 80040154 === W2K8SE (32 bit webbrowser) === webbrowser.c:1216: Test failed: unexpected call UpdateUI webbrowser.c:295: Test failed: unexpected nsCmdID 21 webbrowser.c:239: Test failed: unexpected call QueryStatus_STOP

1 0

Re: [PATCH] [Mmsystem.drv]: always map parameters for all callback kinds
by Juan Lang 19 Jun '10

19 Jun '10

Hi Eric, minor comment on this patch: + case CALLBACK_FUNCTION: + TRACE("Function (32 bit) !\n"); + /* 16 bit func, call it */ + TRACE("Function (16 bit) %x!\n", thunk->callback); The back-to-back traces look a little strange. So does the indenting here. --Juan

1 0

Apologies for the marketing message
by Jeremy White 19 Jun '10

19 Jun '10

It's not clear how it happened; it was not intended. These are direct emails James sends periodically to customers reaching the end of their support period. We speculate that someone signed up with the mailing list address as 'their' address. At any rate, by way of apology I'd like to remind everyone that all contributors to Wine are entitled to VIP status with CodeWeavers, which gets you free lifetime subscriptions to CrossOver. (This way, there is no chance James could ever sell you anything <grin>). Write to me if you'd like me to set you up. We are deeply grateful for everyones contributions to Wine, and very sorry for the off topic emails. Cheers, Jeremy

1 0

Re: new winetricks 20100618: new verbs dxsdk_nov2006, windowscodecs
by Vincent Povirk 19 Jun '10

19 Jun '10

On Sat, Jun 19, 2010 at 9:31 AM, Nikolay Sivov <nsivov(a)codeweavers.com> wrote: > On 6/19/2010 18:25, Vincent Povirk wrote: >>> >>> Is it possible to add this in existing target d3dx dll that will be using >>> new decoder? >>> >> >> Yes, but they'll have to share the decoder for the DDS format somehow. >> It doesn't make much sense for d3dx9 to load d3dx11 for this. >> > > If native d3dx11 uses d3dx9 for that it's not a problem, cause this will be > still separated and both overrides will work. > If not - it's sad, additional winetricks re-registration will be needed, > etc. And if our windowscodecs is complete enough > we should probably forget about all of that and never use its override. Well, we need to register a decoder coclass to do this most cleanly, using WIC's built-in image format detection. These classes aren't present on any native dll's. Even if we didn't use a coclass, we'd need some sort of extension to a builtin dll. Most of the extra formats are only needed by d3dx9 (it seems native d3dx10 and d3dx11 use WIC, so they mostly support the WIC formats). DDS, however, can be loaded in d3dx9, d3dx10, and d3dx11. If we put a coclass for DDS in one of these dll's, the other two will have to load it when a program needs to read a DDS file.

1 0

kernel32 translation question
by Luca Bennati 19 Jun '10

19 Jun '10

I found out why it didn't build: a numeric code in the first lines was in a wrong format. But now i need help to know what exactly i need to put there, because i don't know anymore. The lines are these (example got from french file): LanguageNames=(FRA=0x0c:winerr) CodePages=(FRA=65001:0) The problem is only the hexadecimal code in the first line: where i find the right value for ITA? The one i put (incorrectly) was from ita.nls ...

3 2