Re: DIB Engine : passing all tests
On Sun, May 24, 2009 at 10:19 PM, James McKenzie wrote: > That's ugly. Did you attempt to type in something in the Document area? I've disabled all my Quartz hacks, the only thing sort of non-standard I have is my custom FreeType with patented engine enabled and support for SubPixel rendering turned on. Now that I think about it, that could be a problem. I'll try another round of testing with that disabled next. Yes, it is MUCH faster rendering and scrolling and the like but there are minor glitches with the font placement in the document area. Notice how the word support and deployment overlap with the dib engine and how the lines alternate color? The speed difference for editing is like night and day. The header and footers for the document body containing images renders fine. Installers such as ie6setup and msxml3 embedded images don't render properly, I'll try to upload images for that as well in the morning. Bugzilla seems to be running quite slow so I can't upload the images there. Comparison screenshots for Word are here http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_NO_DibEngine_OS_X.png http://steven-edwards.kicks-ass.org/~sedwards/Wine_1.1.22_Word2007_With_DibEngine_OS_X.png Since this is not likely to get merged in anytime soon, lets move the rest of the OS X related discussions back to the bug when bugzilla decides to stop munching on the pesticide. I'll try to file more detailed reports as time permits. Max this is wonderful progress, please keep up the good work! Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: DIB Engine : passing all tests
Steven Edwards wrote: > On Sun, May 24, 2009 at 9:23 PM, James McKenzie > wrote: > >> Let me know how this goes. I'm interested in improvements that will >> help all *nixes, including MacOSX. >> > > I think I am using the latest patch, its dibeng_max.zip thats got the > 1-10 patches. > > There are some major graphical glitches, though it could be related to > me having Quartz Extreme and Quartz2d enabled on unsupported hardware. > It does seem much faster though. Sorry I don't have time right now to > do a complete report. I'll try to upload information to bugzilla in > the morning after I make my environment a little more sane. > > That's ugly. Did you attempt to type in something in the Document area? I don't have the time tonight to attempt to build and run the DIB stuff to see what it does to the games and other programs that I work with. Maybe, tomorrow afternoon after my bicycle ride. James McKenzie
Re: DIB Engine : passing all tests
Steven Edwards wrote: > On Sun, May 24, 2009 at 11:06 AM, Massimo Del Fedele wrote: > >> André Hentschel ha scritto: >> No idea on what will happen with Mac or other unixes >> > > I am attempting a Mac build now. As with the rest of the discussion, > It would be nice if we could produce a PE version using something like > cygwin with X11 headers and the -mno-cygwin switch but I don't know if > this would really work. If did then it should work on everything. > Let me know how this goes. I'm interested in improvements that will help all *nixes, including MacOSX. James McKenzie
Re: DIB Engine : passing all tests
On Sun, May 24, 2009 at 11:06 AM, Massimo Del Fedele wrote: > André Hentschel ha scritto: > No idea on what will happen with Mac or other unixes I am attempting a Mac build now. As with the rest of the discussion, It would be nice if we could produce a PE version using something like cygwin with X11 headers and the -mno-cygwin switch but I don't know if this would really work. If did then it should work on everything. Thanks -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: [comctl32] Test request
Ge van Geldorp wrote: Hi Nikolay, From: Nikolay Sivov [mailto:bungleh...@gmail.com] Ge van Geldorp wrote: From: Nikolay Sivov I've just prepared some simple MRU tests and I need test them on various native platfoms - tested only on xp sp2 so this one could be skipped. Could somebody do it? Your tests pass on my W2K, XP, W2K3, Vista and W2K8 machines, but I get crashes which were not there before on NT4 Workstation and NT4 Server (both SP6). I haven't investigated further, I could probably determine the test case that crashes if needed. Thanks for testing, Ge. Yes, it will be nice if you tell me which tests crash. I'll comment them out then with some notes. Both the pEnumMRUList(NULL, 0, NULL, 0) and pEnumMRUListW(NULL, 0, NULL, 0) calls in test_EnumMRUList() cause a crash. If I comment out these 2 tests then the rest of the tests pass. Ge. Ok. Thank you.
RE: [comctl32] Test request
Hi Nikolay, >From: Nikolay Sivov [mailto:bungleh...@gmail.com] > >Ge van Geldorp wrote: >>> From: Nikolay Sivov >>> >>> I've just prepared some simple MRU tests and I need test them on various >>> native platfoms - >>> >>> tested only on xp sp2 so this one could be skipped. >>> >>> Could somebody do it? >> >> Your tests pass on my W2K, XP, W2K3, Vista and W2K8 machines, but I get >> crashes which were not there before on NT4 Workstation and NT4 Server (both >> SP6). I haven't investigated further, I could probably determine the test >> case that crashes if needed. > >Thanks for testing, Ge. > >Yes, it will be nice if you tell me which tests crash. I'll comment them >out then with some notes. Both the pEnumMRUList(NULL, 0, NULL, 0) and pEnumMRUListW(NULL, 0, NULL, 0) calls in test_EnumMRUList() cause a crash. If I comment out these 2 tests then the rest of the tests pass. Ge.
Re: [comctl32] Test request
Ge van Geldorp wrote: From: Nikolay Sivov I've just prepared some simple MRU tests and I need test them on various native platfoms - tested only on xp sp2 so this one could be skipped. Could somebody do it? Your tests pass on my W2K, XP, W2K3, Vista and W2K8 machines, but I get crashes which were not there before on NT4 Workstation and NT4 Server (both SP6). I haven't investigated further, I could probably determine the test case that crashes if needed. Ge. Thanks for testing, Ge. Yes, it will be nice if you tell me which tests crash. I'll comment them out then with some notes. Nikolay S.
RE: [comctl32] Test request
> From: Nikolay Sivov > > I've just prepared some simple MRU tests and I need test them on various native platfoms - > tested only on xp sp2 so this one could be skipped. > > Could somebody do it? Your tests pass on my W2K, XP, W2K3, Vista and W2K8 machines, but I get crashes which were not there before on NT4 Workstation and NT4 Server (both SP6). I haven't investigated further, I could probably determine the test case that crashes if needed. Ge.
Re: DXTn textures in D3DX9
I believe mesa looks for libtxc_dxtn @ http://homepage.hispeed.ch/~rscheidegger/dri_experimental/s3tc_index.html and then enables full s3tc support. The library itself is tiny and in (ugly) C, so that is already good news. But as stated on the website, you cannot use the code due to legality. Maybe there would be a way to do on-demand loading as with mesa and output a warn/fixme if the library is not found? It seems like the approach would be similar to the way the font bytecode interpreter was handled (turn on if available). On a sidenote, I may not know what I'm talking about so feel free to completely disagree. Mike. On Sat, May 23, 2009 at 4:48 PM, Henri Verbeet wrote: > 2009/5/22 Tony Wasserka : >> Hi everyone, >> I'm working on implementing D3DXLoadSurfaceFromFileInMemory right now, >> but I've got a problem. The function >> most convert a loaded surface's data to a user specified surface format >> (I did not yet find a way to do it elsehow, >> UpdateTexture and StretchRect are to limited for that task, suggestions >> welcome if I missed anything). >> Now, if the user specifies that D3DX9 needs to convert e.g. an R8G8B8 >> surface to DXT1 (or to save a surface to a >> DXTn compressed DDS file), I'm not sure wether I can implement that >> behavior; on #winehackers I was told that >> the (de)compression part is coverered by S3's patents, but the Gimp DDS >> plugin and this >> (http://mollyrocket.com/forums/viewtopic.php?t=392) seem to provide OSS >> solutions for it anways. >> So... Can anybody tell me for sure wether I may implement this code or not? >> > > What it comes down to is that I don't think we want to take that risk, > so essentially "No". > > >
Re: DIB Engine : passing all tests
2009/5/25 Massimo Del Fedele : > André Hentschel ha scritto: >> >> I dont know anything about that, but may it be possible to compile your >> code to a standalone driver for seperate download? >> It would be great to just install a DIB-Driver for wine. >> Sorry if that was a stupid idea. >> > The idea is not stupid at all :-) > I was thinking to do it, but I don't know for how many > machines a separate compile would be needed. > I'm working on ubuntu64, and I tested just migrating the > 2 DLLs on an ubuntu32 and it do work, so I guess it should > work on most linuxes. > No idea on what will happen with Mac or other unixes To make this work and be as portable as possible, you'd need to produce pure win32 DLLs (not ELF/PE hybrid .dll.so files). You would then only need to distribute win32 and win64 variants, and not need to worry about all the different kernels/libc's Wine is capable of running on. :)
Re: News on Wine 1.1.21/MacOSX/XQuartz 2.3.3
On Sun, May 24, 2009 at 2:49 AM, James McKenzie wrote: > Roderick Colenbrander wrote: >> >> Thanks, I used this to compile wine 1.1.21 for testing purposes this >> week. I had to update the scripts a bit (e.g. use newere versions of >> some libraries and tools because the old ones are offline). I can post >> a patch against the old script. Further don't ship the opengl hack >> anymore for new wine packages as you are aware it isn't needed for >> xquartz 2.3.3 anymore. Everyone should move to the latest xquartz. >> This might prevent some opengl bug reports which I have to close on >> bugzilla as well ;) >> >> > Can you provide the updates to the scripts? Since I am using Leopard, > the opengl fix is not needed anymore, but it may have to stay until > XQuartz 2.3.3 is backported for Tiger. > > James McKenzie > > Hi James, This is the script I used. It mainly consists of some new servers and updated version numbers because the original versions weren't available anymore (sure they are useally in some 'old' directory). Further I'm not building with the opengl patch. Roderick build_darwine_x86.sh.gz Description: GNU Zip compressed data
Re: annoying pkg-config problem on 64 bit Ubuntu 8.10
On Sun, May 24, 2009 at 12:25 AM, Ben Klein wrote: > 2009/5/23 Austin English : >> On Thu, May 21, 2009 at 5:24 PM, Joel Holdsworth >> wrote: >>> On Thu, 2009-05-21 at 22:18 +0200, Tijnema wrote: Haven't checked Jaunty yet to see if it's still busted. We may need to postprocess pkg-config's output to add the missing 32 in some cases. Not sure if it's worth it. >>> >>> On Jaunty I get >>> >>> $ pkg-config --libs dbus-1 >>> -L//lib -ldbus-1 >> >> I do as well, but './configure' and './configure --enable-win64' both work >> fine. > > Does it tell you you're missing dbus or HAL stuff when you're not? > No, configure shows all dependencies as satisfied, for 32 and 64 bit. -- -Austin
Re: [PATCH 01/10] msi/tests: Add tests for binary OBJECTS.
On Sun, May 24, 2009 at 11:51 AM, Hib Eris wrote: > Hi, > > I will send 10 patches for msi.dll that will add support for OBJECT > types in the Msi Database and that will allow you to merge in new > tables. > > This will make the WiX (Windows Installer XML) toolkit work a lot better. > > Please review and provide feedback on what can be improved as this is > my first substantial patch series to wine. > > Kind regards, > > Hib Eris > > > --- > dlls/msi/tests/db.c | 84 > +++ > 1 files changed, 84 insertions(+), 0 deletions(-) > > > > Great work. Thanks for helping Wine! -- -Austin
Re: DIB Engine : passing all tests
André Hentschel ha scritto: Massimo Del Fedele schrieb: André Hentschel ha scritto: I dont know anything about that, but may it be possible to compile your code to a standalone driver for seperate download? It would be great to just install a DIB-Driver for wine. Sorry if that was a stupid idea. The idea is not stupid at all :-) I was thinking to do it, but I don't know for how many machines a separate compile would be needed. I'm working on ubuntu64, and I tested just migrating the 2 DLLs on an ubuntu32 and it do work, so I guess it should work on most linuxes. No idea on what will happen with Mac or other unixes Max would you provide your builds for us? Can do on next days. But I need some place on where to put the precompiled dlls... I guess nor bug421 page nor here are good places for it. Ciao Max
Re: urlmon: Cache binding notif window.
Hi Dan, Dan Kegel wrote: Hi Jacek, why do you have tls_list in http://www.winehq.org/pipermail/wine-patches/2009-May/072833.html ? The usual idiom is to just free each thread's data in THREAD_DETACH, isn't it? THREAD_DETACH is called only if thread detaches before urlmon.dll is unloaded. When urlmon.dll is unloaded only PROCESS_DETACH is called and we have to free TLS resources of all threads to avoid leaks (I don't consider such leaks as a serious problem, but it's better to avoid them). I ran into this while chasing a crash regression in Sketchup, see Anastasius' comments in http://bugs.winehq.org/show_bug.cgi?id=18601 I've attached a patch to the bug. Thanks, Jacek
[comctl32] Test request
Hi. I've just prepared some simple MRU tests and I need test them on various native platfoms - tested only on xp sp2 so this one could be skipped. Could somebody do it? comctl32_mru_090524.patch Description: application/mbox
re: urlmon: Cache binding notif window.
Hi Jacek, why do you have tls_list in http://www.winehq.org/pipermail/wine-patches/2009-May/072833.html ? The usual idiom is to just free each thread's data in THREAD_DETACH, isn't it? I ran into this while chasing a crash regression in Sketchup, see Anastasius' comments in http://bugs.winehq.org/show_bug.cgi?id=18601 - Dan
Re: DIB Engine : passing all tests
Massimo Del Fedele schrieb: André Hentschel ha scritto: I dont know anything about that, but may it be possible to compile your code to a standalone driver for seperate download? It would be great to just install a DIB-Driver for wine. Sorry if that was a stupid idea. The idea is not stupid at all :-) I was thinking to do it, but I don't know for how many machines a separate compile would be needed. I'm working on ubuntu64, and I tested just migrating the 2 DLLs on an ubuntu32 and it do work, so I guess it should work on most linuxes. No idea on what will happen with Mac or other unixes Max would you provide your builds for us?
Re: DIB Engine : passing all tests
André Hentschel ha scritto: I dont know anything about that, but may it be possible to compile your code to a standalone driver for seperate download? It would be great to just install a DIB-Driver for wine. Sorry if that was a stupid idea. The idea is not stupid at all :-) I was thinking to do it, but I don't know for how many machines a separate compile would be needed. I'm working on ubuntu64, and I tested just migrating the 2 DLLs on an ubuntu32 and it do work, so I guess it should work on most linuxes. No idea on what will happen with Mac or other unixes Max
Re: DIB Engine : passing all tests
I dont know anything about that, but may it be possible to compile your code to a standalone driver for seperate download? It would be great to just install a DIB-Driver for wine. Sorry if that was a stupid idea. Nope, and I think they will not be solved soon. Not by me, anyways. I made my engine because I was needing it, but Alexandre don't like its architecture, so it won't be merged even if, IMHO of course, it could be done as an "alternative experimental driver" in parallel to current winex11 one, which could spread its usage and testing a lot more. But Alexandre didn't like that solution, ever. Ciao Max
Re: DIB Engine : passing all tests
2009/5/24 Massimo Del Fedele > I'm looking forward to this hitting upstream :) Have the architectural >> issues been solved yet? >> >> Nope, and I think they will not be solved soon. Not by me, anyways. > I made my engine because I was needing it, but Alexandre don't like > its architecture, so it won't be merged even if, IMHO of course, it > could be done as an "alternative experimental driver" in parallel to > current winex11 one, which could spread its usage and testing a lot > more. But Alexandre didn't like that solution, ever. > I assume all this took place on IRC because unless I missed it, Alexandre hasn't deigned to comment on here about what the right architectural solution would be. Sorry to sound like a stuck record but the Wine website still lists "write a DIB engine" as a requirement, and every time someone does, the patches dissapear down a hole because they're "not right". Someone document what "would be right", or take "write a DIB engine" off the list. I'd love to have a go at documenting it myself, but I don't have the time to reverse engineer it from a few years' worth of rejected solutions. -- Chris
Re: DIB Engine : passing all tests
Kai Blin ha scritto: On Sunday 24 May 2009 06:54:10 Ben Klein wrote: Does that mean it's time to remove these todos (and make them full tests) or are they still wanted for the case where Max's DIB engine is not installed? They are full tests, they're just marked as not passing in wine. Which they don't. At least not until wine has a DIB engine. Most but not all of them. A few of them could be fixed anyways. I'm looking forward to this hitting upstream :) Have the architectural issues been solved yet? It seems like Max and Alexandre agreed to disagree. I wouldn't hold my breath for this code to be merged to the main tree. Unfortunately, Max seems to like using Bugzilla to let people track his patches, instead of dumping them into some git tree, which would make keeping track of updates easier. His call of course. The problem here is that I've got no time to maintain an updated git tree with my engine and I'm still fixing stuffs, so I prefere to manage my patchset directly in order to avoid a 1000+ patches on my tree. Dumping my patchset on a git tree wouldn't make its usage easier and would make me loose time and bandwidth to maintain it. People able to check out a git tree and build it are also able to apply the patchset to a clean one. It makes them spare time, too, as they don't have to maintain and build 2 different trees. With stacked git it's easy to add/remove the patchset. Anyways, if somebody wont take the (again, useless imho) job of maintain an updated tree with it, feel free to do it :-) Ciao Max
Re: DIB Engine : passing all tests
Ben Klein ha scritto: 2009/5/24 Massimo Del Fedele : Austin English ha scritto: On Fri, May 22, 2009 at 6:31 PM, Massimo Del Fedele wrote: I posted on bug 421 page (as usual) latest update of my engine. It suld pass all tests in wine suite also all bitmap's todo_wines, so expect some "false positive" signaled by tests. Austin, could you please re-run it on your test machines ? Sorry for the delay. New residence has crappy wireless internet, need to find a better solution. Anywho, I've still got a failure: palette.c:105: Test failed: getColor=00302010 http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-ub904-dib/gdi32:palette.html Yep, I've seen it sorry, I checked out just the bitmap suite. It's trivial to fix, will do on next release Yep, several todo's are passing now: http://test.winehq.org/data/b175a43fb8439a33a686512935597d4c43c19733/wine_ae-ub904-dib/gdi32:bitmap.html too bad that the suite marks them as failures :-) Does that mean it's time to remove these todos (and make them full tests) or are they still wanted for the case where Max's DIB engine is not installed? I guess not, wine is not passing them, and it won't pass most of them without a proper DIB engine. Some of them are independent of dib engine, indeed, and could be fixed anyways. I'm looking forward to this hitting upstream :) Have the architectural issues been solved yet? Nope, and I think they will not be solved soon. Not by me, anyways. I made my engine because I was needing it, but Alexandre don't like its architecture, so it won't be merged even if, IMHO of course, it could be done as an "alternative experimental driver" in parallel to current winex11 one, which could spread its usage and testing a lot more. But Alexandre didn't like that solution, ever. Ciao Max
Re: DIB Engine : passing all tests
On Sunday 24 May 2009 06:54:10 Ben Klein wrote: > Does that mean it's time to remove these todos (and make them full > tests) or are they still wanted for the case where Max's DIB engine is > not installed? They are full tests, they're just marked as not passing in wine. Which they don't. At least not until wine has a DIB engine. > I'm looking forward to this hitting upstream :) Have the architectural > issues been solved yet? It seems like Max and Alexandre agreed to disagree. I wouldn't hold my breath for this code to be merged to the main tree. Unfortunately, Max seems to like using Bugzilla to let people track his patches, instead of dumping them into some git tree, which would make keeping track of updates easier. His call of course. Cheers, Kai -- Kai Blin WorldForge developer http://www.worldforge.org/ Wine developerhttp://wiki.winehq.org/KaiBlin Samba team member http://www.samba.org/samba/team/ -- Will code for cotton. signature.asc Description: This is a digitally signed message part.
