February 2009 - Wine-Devel - list.winehq.org

Re: Simple but awesome demos of Wine?

by Ben Klein

2009/2/2 Dan Kegel <dank(a)kegel.com>: > On Sun, Feb 1, 2009 at 9:48 AM, Dan Kegel <dank(a)kegel.com> wrote: >> I'm going to be giving a Wine presentation at >> Cebit next month. You can see a draft of the >> presentation at >> http://kegel.com/wine/cebit2009/talk.html > > I've updated the presentation. Mostly I just > added hyperlinks (some even useful) to all the images, > and added screenshots of winehq. I still have a lot to add. > > If anyone knows how to get rid of the highlighting around > image links via css, please let me know. 1) Most simple way: img { border: none } 2) More advanced: img:link, img:visited { border: none } Method 1 removes borders on all images as the default. Method 2 restricts removing the borders to hyperlinks. > Thanks for the suggestions, I'll try the apps everybody > suggested (and the autohotkey script) soon, I hope. > And yes, the laptop will have a good nvidia chip, > and I will make darn sure it can talk to video projectors > well before I leave...

Feb. 2, 2009

Re: Simple but awesome demos of Wine?

by Dan Kegel

On Sun, Feb 1, 2009 at 9:48 AM, Dan Kegel <dank(a)kegel.com> wrote: > I'm going to be giving a Wine presentation at > Cebit next month. You can see a draft of the > presentation at > http://kegel.com/wine/cebit2009/talk.html I've updated the presentation. Mostly I just added hyperlinks (some even useful) to all the images, and added screenshots of winehq. I still have a lot to add. If anyone knows how to get rid of the highlighting around image links via css, please let me know. Thanks for the suggestions, I'll try the apps everybody suggested (and the autohotkey script) soon, I hope. And yes, the laptop will have a good nvidia chip, and I will make darn sure it can talk to video projectors well before I leave...

Feb. 2, 2009

Re: wined3d and winex11 hand in hand...

by Dmitry Timoshkov

"Jérôme Gardou" <jerome.gardou(a)gmail.com> wrote: > Quite oddly enough, wined3d and winex11 don't communicate with each > other at all (well, wined3d uses WGL in gdi32, and gdi32 is based on > winex11), and this leads to problems which are tricky to resolve... For > instance, when a d3d application wants to disable screensavers, And how exactly does it "want" to do that? > there is > no way to do this through the windows api, but xlib provides > XSetScreenSaver which is axactly what we need there. http://www.google.com/search?q=how+to+disable+screen+saver+under+windows+pr… http://support.microsoft.com/kb/126627 > Would it be a good way to do this, as in user32 and gdi32, to create a > driver structure holding each function pointer we would need, and > forward them to stub if unavailable? Have you looked how it's currently implemented? -- Dmitry.

Feb. 2, 2009

Re: deb packages archive down?

by James McKenzie

Tom Wickline wrote: > Hello, > > I have been trying to access the Wine deb archives for about > six hours now and Ive been receiving a "connection to the server was reset" > error. I'm not sure how long this has been the case but can the maintainer > of the archive please look into this failure? > > http://wine.budgetdedicated.com/archive/index.html > > Cheers, > > Tom > > I just checked that URL at 1917 Mountain Standard Time (US) which is 217 UTC and it was up. James McKenzie

Feb. 2, 2009

Re: wine.budgetdedicated.com down?

by Jeremy White

> Would it be possible to host the Wine packages somewhere with higher > availability? My sense is that budgetdedicated has largely had a stellar track record, and that we should, in addition to our great thanks and praise, give them the benefit of the doubt. Scott, I looped you directly in the hope that you'd chime in as well. Cheers, Jeremy

Feb. 2, 2009

Re: performance issue when OffscreenRenderingMode = "pbuffer"

by Ben Klein

2009/2/2 Stefan Dösinger <stefan(a)codeweavers.com>: > Am Sonntag, 1. Februar 2009 22:02:15 schrieb Jérôme Gardou: >> The patch was sent, but not accepted. Does anyone have a clue about it? >> >> http://www.winehq.org/pipermail/wine-patches/2009-January/068339.html > The vidmem counting is faked, and only counts the size of the D3D objects, not > the size the GL objects have. > > Does this patch fix any bug? (I have missed the beginning of the thread) Original post indicates it fixes a performance issue in Supreme Commander, where it drops to < 10FPS after a while, presumably due to graphics memory being exhausted and system memory being used instead. Also in the original post is: 2009/1/25 Jérôme Gardou <jerome.gardou(a)gmail.com>: > For those who are curious, try setting VideoMemorySize to 200 instead of > 256. It works just like a charm. I'm not sure, because I don't have Supreme Commander, but I assume this is a current work-around for the performance issue (setting VideoMemorySize to about 50MB less than what your card actually has).

Feb. 2, 2009

Re: performance issue when OffscreenRenderingMode = "pbuffer"

by Stefan Dösinger

Am Sonntag, 1. Februar 2009 22:02:15 schrieb Jérôme Gardou: > The patch was sent, but not accepted. Does anyone have a clue about it? > > http://www.winehq.org/pipermail/wine-patches/2009-January/068339.html The vidmem counting is faked, and only counts the size of the D3D objects, not the size the GL objects have. Does this patch fix any bug? (I have missed the beginning of the thread)

Feb. 2, 2009

Re: [RFC] Port of Stefan Dösinger's ARB_vertex_program fixed-function vertex pipeline replacement to 1.1.14

by Stefan Dösinger

> Towards that aim, I've ported Stefan Dösinger's initial implementation > of this from October last year [1] to what turned out to be 1.1.14. I think they passed the last time I tested it. You could try to check out the old wine version and test with the original patch. I could be wrong though. > It fails two more D3D9 tests than 1.1.14: > visual.c:914: Test failed: Transformed vertex with linear vertex fog has > color 0000ff00 visual.c:986: Test failed: Transformed vertex with linear > vertex fog has color 0000ff00 > > (I don't know if these failed when it was first implemented, so I don't > know if the problem is the patch, the port, or even the test. This is on > my nVidia 8600 w/180.22 binary drivers, in case it makes a difference.) > > I haven't run it with any games yet, or profiled it. Stefan's commented > since that it was slower than the current system, albeit unoptimised, > and that was the reason he didn't undertake any further work on it. The main performance problem is I think the lighting code. It looks horrible and probably uses much more instructions than needed. One app that is hit pretty hard by drawStridedSlow is 3DMark 2000(esp. the heli test in high detail). This app actually slows down instead of gaining speed. > I don't know what games use the fixed-function pipeline, so I'm open to > suggestions and bug report references. Basically everything <= d3d7 has to. But many newer games still do. I have seen heavy ffp drawing in even very new games. The D3D SDK samples are also very good for testing. > All but the last patch in this tarball are ports of Stefan's original, > and were done using git-am so still retain his original headers. The > sorta-nasty no_d3dcolor_swizzle code in get_color and its caller in the > last patch is entirely my fault though. ^_^ There's a potential place for your fog test problems. You could disable the extension in directx.c for testing/development(just comment out the line in the ext table) and later on work on properly using it with the ffp code. > I'm not totally sure I've got all the hard parts of the port right. The > two relevant changes since these patches were applied were the > implementation of EXT_vertex_buffer_bgra and the rearrangement of the > fog code. > > For EXT_vertex_array_bgra and vertex_pipe->can_convert_d3dcolor, I'm not > sure if there are places that check one and should check the other, and > I'm not sure if the test in state.c line 4280 (streamsrc) is doing the > right thing. I think it is doing the right thing. The vertex program > recognises and handles a position_transformed vertex declaration itself. I think we should make this two different flags in the pipeline description, and only use those in the rest of the code(or functions that return TRUE and FALSE). e.g. can_convert_d3dcolor fixed func: GL_SUPPORT(EXT_vertex_array_bgra); replacement: TRUE; can_handle_rhw: fixed func: FALSE replacement: TRUE Ideally only the fixed func's can_convert_d3dcolor() function will check GL_SUPPORT(EXT_vertex_array_bgra), the rest of the code just asks the selected pipeline implementation.

Feb. 1, 2009

Re: Simple but awesome demos of Wine?

by Piotr Pawłow

Dan Kegel wrote: > It'd be nice to also have some games, but I don't > play enough to know which ones to pick. I'd suggest FlatOut 2. It's an arcade racing game with nice graphics. The only thing I couldn't get to work on Wine is online play, everything else work great - sound, videos, special effects (post processing, shadows, reflections etc). It looks stunning on a big screen... with all the spectacular crashes, car parts, scenery parts flying around. Lots of action, plus loud rock music makes it good for parties :) I'm amazed how well it works on Wine, even more so when I realize that it's a DX9 game, not OpenGL. Frame rate is very good on my GeForce 8600GT, perfectly smooth. I finished the whole game, and it never crashed while playing, even after several hours. There is a playable demo available on the net. I just checked if it still works on Wine 1.1.13. Played a few races. It crashed on exit, but otherwise was OK. Regards

Feb. 1, 2009

Re: [patch] review requested - NamedPipe Message mode (was Reliable Datagram / Stream behaviour of NT Pipes)

by Luke Kenneth Casson Leighton

> so, adding server_named_pipe_read() avoids this issue by doing locking > (like server_get_unix_fd()) does, i see) $ git commit -a -m '#17185 - server-based read_named_pipe. does blocking in client and non-blocking reads (using recv MSG_PEEK) in the server. messy as hell.' says it all, really :) bit of a marathon session that one. break-time. more in a couple of days. anyone want to take over, email me, you can have what i've got so far. blocking checks client-side (using select) are made on the unix-pipe fd to ensure that there's _actually_ data that wineserver can get at. after reading the message-length (done only once per message duh), read() is replaced by server_named_pipe_read() - still in the for (;;;) loop. alexandre, would it be reasonable to put a CriticalSection around the [optional message-length-reading and] for-loop? i really can't see any other way. what i've done is protect the server from blocking on a read(), by making sure that recv(MSG_PEEK) - actually select() might be better - checks the length. that means however that you still, in kernel32, in ReadFile(), still have to do the for() loop, but preceding each read by a blocking wait (i clear O_NONBLOCK and do an infinite/blocking select()) it all screams "CriticalSection" protection - on a per-handle basis. anyone got any better ideas? let me know, i'll come back to this in a couple of days. l.

Feb. 1, 2009