Spare change for MS ($125M) bought 25% of Corel.(you can read the whole story) A few remarks went out, especially around the impact on Corel's involvement in Wine (EdNote: Corel's folks have been silent for a couple of days; last mail from Corel's is 4 weeks old), but also around Microsoft intends. The most expressed opinion was, as Microsoft already did for Apple and Borland/Inprise, either to keep a few competitors around (Microsoft can so claim to DoJ is not a monopoly), or to squash existing competitors. Anyway, this hadn't disturb much the Wine developers, but we'll keep you posted on the next events.
However, the fix provided by Ove requires a proper implementation of SendNotifyMessage (which is not done yet). Andreas Mohr explained he had started some hacking around message handling which could help, but no one answered his proposal.Marcus' patch makes the app's timing loop no longer rely on the blocked service thread. My patch keeps the service thread from being blocked at all.
APP THREAD SERVICE THREAD start up, maps X windows, etc idle still in startup receives mapping notifications " receives Expose, invalidates window, " sends WM_SYNCPAINT to app window " SendMessage blocks waiting for app enters timing calibration loop -blocked- ... " main message loop " -handles the WM_SYNCPAINT " ... SendMessage returns handle asynchronous timers
First I have a good news to announce: the latest gcc version supports anonymous unions and structs in C++ _and_ C. This is a big step forward compared to gcc 2.95.2 which only supported anonymous unions and only in C++. Unfortunately our current NONAMELESSxxx / _FORCENAMELESSxxx system has a few problems:Uwe Bonnes asked why configure (and autoconf) couldn't be used to check for anonymous union / struct support in the compiler. Patrik Stridval answered:So I propose the following:
- a '!defined(__cplusplus)' test in windef.h will prevent Winelib users from using anonymous structs in C.
- I did not find a use for NONAMELESSxxx. AFAICS either _FORCENAMELESSxxx is undefined and then you don't use anonymous xxx or it is defined and then you use it. Why would someone define it and NONAMELESSxxx at the same time?
- we keep only NONAMELESSxxx
- if __WINE__ is defined and then we also defined both NONAMELESSxxx macros (for obvious portability reasons we don't want to use anonymous stuff in the WINE code)
- if we know the compiler does not support anonymous structs/unions we define the appropriate NONAMELESSxxx macro. This would more or less apply to all gcc/g++ <= 2.95
- if after all the above NONAMELESSxxx is not defined then we use anonymous xxx
It can't, since the files are used by WineLib applications that don't use Wine's configure. And no you can't have a system wide configure since you might use different version of GNU C with the same include files or indeed even a different C compiler. There was a quite long thread (flamewar) a while ago, where I tried explain to people that simply didn't want to understand that. Some people seemed to entertain the idea that you should compile you own version of WineLib as Corel currently does, for each application. This is totally insane in the long run. IMVHO best illustrated with the counter argument "So you compile your own version of libc for every application you write". WineLib is (or should be) a library just like any other. It should not require any special treatment to use.Francois went further:
Even more so for this particular case. I even contend that choosing whether to use anonymous structs/unions or not does not even depend on the compiler! Either your code is written with s./u. everywhere and then you do not want to use anonymous structs/unions, no matter what the compiler can do. Or your code relies on anonymous struct/unions and your compiler does not, your best move is probably to switch to another compiler. Well, ok, in some cases you will still have to add s./u. everywhere in your code. But this is not going to be accomplished magically by a configure script or a system-wide static header file anyway.The thread then evolved with Patrik and Francois arguing on the tidy bits of the implementation so it's as close as possible to Microsoft's one.
Here is my first attempt on implementing support for keyboard input translation according to the current locale. Some problems that I tried to solve:Ove Kåven commented a bit Dmitry's patch, mainly because the keyboard layout which Dmitry found equal between English and Russian shouldn't be the case for a DVORAK layout, or a German QWERTZ (not to speak of French QWERTY's). Ove proposed a few evolutions to Dmitry's patch. Dmitry reworked his patch accordingly, and got it submitted to wine-patches.Now keyboard input works for me as for english US layout, as for russian one.
- I didn't find way to make to work XLookupString with setlocale(LC_CTYPE,"").
- I modified keyboard detection code to assign virtual key codes along with the found scan codes because virtual key codes are always the same for english keyboard layout and other (russian for me) keyboard layout in windows.
I managed to get Winbench 4.0 working (a very old win16 benchmark from 1993), so I decided to do some benchmarks. I wish I hadn't done them... No, I won't comment on them. It'd hurt even more ;-) Test run on an Athlon 800 w/ 256MB, Matrox G400 DH, X3.3.6, 2.2.18pre10. Only graphics tests were executed. Disk benchmarks don't work due to broken Wine FindNext behaviour when deleting directories in between (I'm planning to fix this at some point). Here they are:Even if Andreas felt disapointed by the results, Francois Jacques tries to have a bright sight on the results
Wine Win98SE Wine better Graph WinMark 37.8 MPs 407 Arc Circular Complete 1.61 5.29 Partial 1.58 3.48 Arc Ell Complete 1.26 6.02 Partial 0.867 3.88 BitBltMS Otrer Aligned 5.27 7.56 Unal 5.61 7.41 PATPAINT, Al 11.5 0.681 * Unal 3.07 0.681 * SRCCOPY Al 8.58 342 Unal 9.64 316 SRCINVERT Al 3.03 159 Unal 3.22 149 BitBltMonoMS Otrer Al 3.43 23.2 Unal 3.57 22.5 PATPAINT Al 1.9 1.8 * Unal 1.96 1.79 * SRCCOPY Al 93.4 396 Unal 92.5 396 SRCINVERT Al 1.96 257 Unal 2.05 236 BitBltMonoSM Otrer Al 3.06 4.68 Unal 3.09 4.08 PATPAINT Al 2.11 2.79 Unal 2.13 2.76 SRCCOPY Al 2.13 7.98 Unal 2.15 3.06 SRCINVERT Al 2.12 2.79 SRCINVERT Unal 2.14 2.76 BitBltSM Otrer Al 6.37 7.6 Unal 6.53 7.44 PATPAINT Al 4.27 0.682 * Unal 4.42 0.682 * SRCCOPY Al 5.43 349 Unal 5.63 316 SRCINVERT Al 4.38 175 Unal 4.52 160 BitBltSS Otrer Al 3.5 7.78 Unal 21.9 7.8 * PATPAINT Al 1.88 0.681 * Unal 1.98 0.681 * SRCCOPY Al 103 232 Unal 104 212 SRCINVERT Al 1.93 122 Unal 2.05 114 BltDIBits 1bpp SRCCOPY Unal 1.08 29.9 24bpp 0.511 101 4bpp 0.505 105 8bpp 1.16 104 Chord Circular 9.38 27.9 Chord Elliptical 5.62 27.6 Circle 17.62 50.3 Combined GWM1 35.4 398 GWM2 3.6 149 3 11.5 75 4 45.9 178 5 43 252 6 45.6 520 7 32.4 445 DrawFocusRect 4.67 21.4 DrawIcon 0.667 27.8 DrawText, MS Sans Serif 11 8.05 66.5 13 11.1 104 Bold 11 8.66 42.2 System 7.59 111 Times New Roman 11 9.87 53.5 13 7.3 65.7 16 18.9 93.2 Ellipse 9.52 49.3 ExtFloodFill, Border 0.178 1.8 EFF, Surface 0.177 1.7 FastWindowFrame 57.7 Failed (!!!) * FillRect 114 442 FillRect, Square 6.45 35.4 FillRgn, Few-Sides, HV 65.2 292 FloodFill 0.177 1.8 FrameRect 19.4 89.8 FrameRect, Square 7.82 39.4 FrameRgn, Few-Sides, HV 8.24 7.78 * GWM/BitBltMS, Otrer, Al 2.86 260 Unal 1.39 64.8 SRCCOPY, Al 10.7 395 Unal 8.3 389 GWM/BitBltMonoMS, Otrer, Unal 1.24 48.6 SRCAND, Al 1.65 158 SRCCOPY Al 77.3 336 Unal 130 515 GWM/BitBltMonoSM, SRCCOPY, Al 4.72 8.09 Unal 1.32 2.96 BitBltSM, SRCCOPY, Al 6.1 395 Unal 60.4 389 BitBltSS, SRCCOPY, Al 108 197 Unal 109 193 GWM/Ellipse 62.3 133 GWM/ExtTextOut, MS SSerif 11 20.3 132 13 27 178 SSerif Bold 21.5 74.3 GWM/ExtTextOut, Rectangle 49.8 445 Square 14.7 130 GWM/ExtTextOut, System 19.2 196 Times New Roman 11 24.5 150 13 9.31 168 16 43.2 212 GWM/FillRgn, Rectangular 36.1 607 Polygonal 92.7 207 GWM/InvertRgn, Rectangular 137 213 GWM/Line, Diagonal 1.49 6.05 Horizontal 11.3 46.9 Vertical 4.54 20.1 PaintRgn, Polygonal 249 1940 Rectangular 847 1490 GWM/PatBlt, BLACKNESS, Unal 24.7 230 GWM/PatBlt, DSTINVERT, Al 223 338 Unal 142 472 Otrer, Unal 1.21 40.4 PATCOPY Al 779 2600 Unal 103 1350 PATINVERT Al 2.82 51.4 Unal 3.01 55.3 ROP(0A), Unal 3.62 210 ROP(A0), Unal 1.04 25 ROP(A5), Unal 3.93 72.7 WHITENESS, Al 1070 7180 Unal 896 7180 GWM/Pie, Elliptical 6.42 25.8 GWM/PolyLine 0.852 98.2 PolyPolygon 12.1 43.5 Polygon, Few-Sides 22.1 98.2 Many-Sides 15.8 75.2 GWM/Rectangle 348 1260 Rectangle, Rounded 5.11 44.2 GWM/SetDIBitsToDev, 4bpp, Unal 3.46 92.9 GWM/Square 3.53 35.8 Square, Rounded 1.49 14.8 GWM/StretchBltMS, SRCCOPY Unal 0.849 2.4 StretchBltMonoMS SRCAND Unal 0.931 17.2 SRCPAINT, ... 0.939 17.2 StretchDIBits, 4bpp, SRCCOPY.. 1.07 16.5 TextOut, MS SSerif 11 10.2 136 13 14.6 184 Bold 11 11 69.6 System 9.62 195 Times New Roman 11 12.5 193 TNR 13 8.46 205 16 24.2 252 GetNearestColor 220000 Ops/sec. 5240000 GrayString, MS SSerif 11 0.669 16.7 13 0.857 24.7 Bold 11 0.705 15.4 System 0.633 26.8 TNR 11 0.763 17.1 13 0.865 19.9 16 1.14 27.5 InvertRect 270 215 * InvertRect, Square 8.26 47.4 InvertRgn, Few-Sides, HV 67.8 185 Line, Diagonal 8.34 37.9 Horizontal 9.97 43.8 Vertical 8.22 36 MoveTo 706000 ops/sec. 7810000 MoveToEx 716000 6290000 PaintRgn, Few-Sides, HV 71.8 374 HVD 47 108 PaintRgn, Rectangular 103 2700 PatBlt, BLACKNESS, Al 355 3520 Unal 353 3450 DSTINVERT, Al 213 288 Unal 216 264 PATCOPY, Al 214 3080 Unal 215 3010 PATINVERT Al 161 287 Unal 161 263 WHITENESS Al 341 3230 Unal 341 3310 Pie, Circular 8.65 17.6 Pie, Elliptical 5.36 17.1 Pixel, Get 0.006 MPs/sec. 0.368 Pixel, Set 0.219 MPs/sec. 0.831 PolyLine 1.12 24.1 PolyPolygon 25.4 106 Polygon, Few-Sides 71.1 329 , Many-Sides 28.7 115 , Trapezoid 140 519 , Triangle 129 344 Rectangle 206 721 , Rounded 22.3 231 ScrollDC 155 211 SetDIBitsBlt 1bpp Unal 5.08 114 24bpp 6.19 65.5 4bpp 4.78 68 8bpp 6.64 65.5 SetDIBitsToDevice 1bpp Unal 3.09 30.7 24 2.54 84.3 4 2.34 91.6 8 4 89.4 Square 237 1730 , Rounded 34.3 236 StretchBltMS, Otrer, Al 2.86 2.32 * , Unal 2.77 2.09 * StretchBltMonoMS, Otrer, Al 2.85 13.9 , Unal 2.89 12.9 StretchBltMonoSM, Otrer, Al 3.53 7.12 , Unal 3.57 6.87 StretchBltSM, Otrer, Al 3.36 2.32 * , Unal 3.12 2.09 * StretchBltSS, Otrer, Al 2.27 2.34 , Unal 2.24 2.1 * StretchDIBits, 1bpp, SRCCOPY,.. 0.749 14.8 24 0.408 7.25 4 0.416 12.5 8 0.823 11.1 TabbedTextOut, MS SSerif 11 7.81 67.6 , 13 10.6 104 , Bold... 8.32 40.8 , System 7.48 113 , TNR 11 9.56 48.2 13 7.1 59 16 18.2 84.9 TextOut, Arial 10 10.1 169 , Arial 10, 45 5.46 3.08 * , Arial 10, 90 5.68 4.29 *
Well, even if it looks sad... at least now we have a better view of where are the performance bottlenecks in graphics. Do you guys remember when Java 1.0 came out? People were doing benchmarks between Java vs. C/C++ - most of the time to demonstrate how Java was awfully slow compared to C/C++. Well, over time, Java picked up and while not being able to match C/C++ performance, the VM got optimized and with the help of JIT compilers, they improved it until it became usable for serious applications. The benchmarks helped the VM folks to figure out where the bottlenecks could possibly be. WINE is still not 1.0 ... Windows 3.0+ is now 10 years old - they had time to optimize their code - let's run the benchmarks in a few months. I know I'm not writing anything new by "it will improve over time" but it's the truth. Those benchmarks should only boost ourselves to tweak the thing. Also as more developers get interested by WINE as a development platform for porting their Windows software, we should see major performance enhancements. Especially, games developers and graphic intensive applications. I would also be curious to see the results of graphic benchmarks under XFree86 4.0 which is supposedly - I haven't tried it yet - faster.