December 2006 - Wine-Devel - list.winehq.org

old benchmark #2: business winstone?
by Dan Kegel Dec. 11, 2006

Dec. 11, 2006

There's an update to business winstone online at ftp://ftp.pcmag.com/benchmarks/bwinstone, but according to http://web.archive.org/web/20041024235010/www.etestinglabs.com/benchmarks/b… the full benchmark was only available on cd-rom. Anyone have a copy of that around still? Thanks, Dan

1 0

winbench '99?
by Dan Kegel Dec. 11, 2006

Dec. 11, 2006

I noticed that, way back six years ago, there was interest in getting winbench '99 running on wine: http://www.kernel-traffic.com/wine/wn20000214_30.html#3 Winbench '99 is still available as a free download from ftp://ftp.pcmag.com/benchmarks/winbench (check out the cool Y2K bug in the directory listing there). I tried it just now with current wine, and it installs ok, but when you start it, it aborts with the error Create system info object failed and wine shows ~/.wine/drive_c/ZDBENCH/UI32$ ~/wine-git/wine ZDBUI32.exe err:ole:CoGetClassObject class {18483923-9673-11cf-ad24-149efa000000} not registered err:ole:CoGetClassObject no class object {18483923-9673-11cf-ad24-149efa000000} could be created for context 0x1 Anyone know what's up with that, or whether this worked with Wine at one time? - Dan p.s. I'd have opened up a report in Bugzilla, but bugs.google.com doesn't seem to be listening on port 80 at the moment.

1 0

Re: user32/winex11: Move CursorClip functionality from user to winex11.
by Pierre d'Herbemont Dec. 10, 2006

Dec. 10, 2006

Vitaliy, Would it be possible to keep that code in user? You could probably compute virtual_screen_rect from GetMonitorInfo() function? I am trying to get as much driver independant code from winex11.drv to user32, so that winequartz.drv won't have to duplicate too much winex11.drv code. Pierre.

1 0

How to deal with render targets in wined3d
by Stefan Dösinger Dec. 10, 2006

Dec. 10, 2006

Hi, The render target support in wined3d is a bit jerky. Basically we're dealing with 2 sorts of render targets: Offscreen textures and onscreen swapchains. Onscreen swapchains have their own drawable and glx context right now, for offscreen textures have that too, except if fbos are used. The seperate context makes a problem. Due to that the render target change has to be performed before any other opengl states are set for drawprim, and it requires keeping track of multiple sets of gl states. The question is, do we need a seperate context? Primary swapchain: essentially, no Back buffer offscreen rendering: not really PBuffer offscreen rendering: Yes? No? FBO offscreen rendering: No Secondary swapchain: Yes? No? Technically a swapchain and offscreen render target would match a glx drawable. However, can we switch the drawable, but keep the context? Can we switch the drawable that the context is used on? What is better performance-wise? Switching a context's drawable, or switching context and drawable and applying all states that changed since the last use of that context? The main thing I'm concerned about are driver bugs. I know that the dri drivers keep track of per-drawable settings per context, what might other drivers do? Another question is what do do about pbuffers. Pbuffers are pretty nasty. Are there any cards out there which have a working pbuffer support, but no fbo support? If we slightly modify the back buffer rendering we can render on auxiliary buffers instead of the pbuffer(If there are any cards out there supporting that). My new state management can handle multiple contexts per device, it has to do that for multithreading. However, if we can do the render target stuff with only one context things will get MUCH easier. Stefan

1 0

Re: WGL: pixel formats
by Tomas Carnecky Dec. 10, 2006

Dec. 10, 2006

Roderick Colenbrander wrote: > Hi, > > This patch makes the WGL code independant of the number of supported pixelformats. At the moment only a single format is supported but this will be extended with a few other 'compatible' formats to provide more opengl functionality like multisampling support. > Please don't apply this patch: DescribePixelFormat(hDC, 0, 0, NULL) should succeed and return the number of available pixel formats - WoW expects this behavior. But someone should probably write a test for that. tom

1 0

winehq.org flakiness?
by Dan Kegel Dec. 10, 2006

Dec. 10, 2006

What is up with winehq.org? Seems like it's down half the time lately. Now, for instance.

2 1

file/directory changes not working with openSUSE 10.2/ kernel 2.6.18?
by Marcus Meissner Dec. 10, 2006

Dec. 10, 2006

Hi, While running make check on the (64bit) kernel 2.6.18 supplied with openSUSE 10.2, I get failures in the kernel/tests/change and ntdll/tests/change tests: ../../../tools/runtest -q -P wine -M kernel32.dll -T ../../.. -p kernel32_test.exe.so change.c && touch change.ok change.c:272: Test failed: failed to create directory change.c:284: Test failed: failed to create subdir change.c:287: Test failed: should be ready change.c:290: Test failed: should be ready change.c:299: Test failed: failed to remove subdir change.c:302: Test failed: should be ready change.c:305: Test failed: should be ready change.c:317: Test failed: failed to remove dir change.c:415: Test failed: ov.Internal wrong (res 259) change.c:416: Test failed: ov.InternalHigh wrong change.c:420: Test failed: action wrong change.c:421: Test failed: len wrong change.c:422: Test failed: name wrong change.c:457: Test failed: ov.Internal wrong change.c:458: Test failed: ov.InternalHigh wrong change.c:469: Test failed: action wrong change.c:470: Test failed: len wrong change.c:471: Test failed: name wrong change.c:483: Test failed: ov.Internal wrong change.c:484: Test failed: ov.InternalHigh wrong change.c:494: Test failed: should be ready change.c:496: Test failed: ov.Internal wrong change.c:497: Test failed: ov.InternalHigh wrong change.c:501: Test failed: action wrong change.c:502: Test failed: len wrong change.c:503: Test failed: name wrong change.c:521: Test failed: action wrong change.c:522: Test failed: len wrong change.c:523: Test failed: name wrong change.c:525: Test failed: ov.Internal wrong change.c:526: Test failed: ov.InternalHigh wrong change.c:585: Test failed: should timeout change.c:593: Test failed: ov.Internal wrong change.c:612: Test failed: should be ready change.c:614: Test failed: ov.Internal wrong change.c:672: Test failed: should timeout change.c:682: Test failed: event should be ready change.c:684: Test failed: ov.Internal wrong change.c:685: Test failed: ov.InternalHigh wrong change.c:688: Test failed: offset wrong change.c:689: Test failed: action wrong change.c:690: Test failed: len wrong change.c:691: Test failed: name wrong make: *** [change.ok] Fehler 43 I tried setting a breakpoint on inotify_poll_event and inotify_get_poll_events but they do not trigger even once. My suspicion is that the new kernel don't wake the queue correctly. :/ Ciao, Marcus

2 1

Wine performance (opengl)
by nlataill Dec. 10, 2006

Dec. 10, 2006

Hi, I am using wine to play World of warcraft (this game is using opengl, and is threaded - 2/3 threads IIRC). I did recently find a reproductable performance regression on versions 0.9.24+. Under the same conditions (always difficult to get in an MMORPG game, but this is reproductible), version 0.9.23 gives me 20/25% more FPS than versions 0.9.24->0.9.26 (have not tried .27 yet). - Is this performance regression known/expected on opengl/threaded applications (new codebase) ? - Is someone using WOW here (and has found a similar preformance regression) ? - It is worth for me to start looking at it (more measures, throw oprofile at it, bissect the change...) Thanks, Norbert

2 2

Re: d3d: Fix EnumAdapterModes and add an adapter mode format test
by H. Verbeet Dec. 9, 2006

Dec. 9, 2006

On 09/12/06, Chris Robinson <chris.kcat(a)gmail.com> wrote: >+ * Copyright (C) 2006 Henri Verbeet Except for perhaps the creation of the device, there's not a lot of code I wrote in there. You should at least include your own name in there.

1 0

wine-rpm on mandriva2007_x86-64
by Daniele Bagaglini Dec. 9, 2006

Dec. 9, 2006

For installing the latest *wine-rpms* and working with it, on mandriva-2007.0_x86-64, we need to install libxxf86vm1-1.0.1-2mdv2007.0.i586.rpm downloadable on a mandriva2007_x86_32 repository, like this for example: ftp://mirror.pacific.net.au/MandrivaLinux/official/2007.0/i586/media/main/release Regards -- Daniele Bagaglini

1 0