wine-devel July 2009

wine-devel@winehq.org

116 participants
249 discussions

Re: 2/2 winex11: add XRender based GetSrcAreaStretch [with patch]
by Austin English 12 Jul '09

12 Jul '09

On Sat, Jul 11, 2009 at 2:33 PM, Roderick Colenbrander<thunderbird2k(a)gmail.com> wrote: > This time with patch. > > Roderick > > On Sat, Jul 11, 2009 at 9:08 PM, Roderick > Colenbrander<thunderbird2k(a)gmail.com> wrote: >> Hi, >> >> This patch adds a XRender based GetSrcAreaStretch. A lot of work is >> offloaded to X (less round trips are needed) and it can take advantage >> of hardware acceleration. On Nvidia and AMD drivers blt performance >> has improved by 20% in CrystalMark2004 while more optimizations can be >> added later on. >> >> Regards, >> Roderick Colenbrander Dan asked me to run appinstall with it, and when I did, found that a ton of stuff breaks. Easiest to see is 'wine control'. It runs, but takes up 100% of a cpu core, and the window never appears. Notepad++ (my dogfood text editor has the same problem). I'm working on adjusting the tests to handle this type of failure better, and will try to run the full test suite on it soon. -- -Austin

2 3

AcceptEx patchset comments
by Mike Kaplinskiy 12 Jul '09

12 Jul '09

I'm looking for comments/criticism for the above patch set. It is actually not complete yet (glaring FIXME on #6), but it is relatively close. Some notes: Patch 1: - needed to handle deferred sockets. We need to destroy the actual deferred socket without closing the handle. Patch 2: - ntdll seems to keep a cache of fd's and since the accept_socket change in patch 4 switches the underlying fd object for a socket handle, we need to flush the cache (is there a better approach?). Patch 3: - needed for patch 4 so accept() can create a socket. Patch 3+4+5: - is a tools/make_requests run required before submitting this? Patch 5: - I don't like it, but can't figure out a better way to do it. Anyone have better ideas? - just realized as I was sending this that there is a problem if acceptex is called twice on the same socket (the async from before is not released). Patch 6: - is pretty much the same as the patch by Scott Lindeneau. Just expanded it and added support for data_len. data_len won't work with completion ports yet. Sorry for the continuous spam regarding AcceptEx; I just want to make sure that this isn't going nowhere. Mike.

1 0

Re: comctl32/toolbar.c: Fix Lingvo 9.0 crashes on startup [Resend 2]
by Nikolay Sivov 12 Jul '09

12 Jul '09

Vladimir Pankratov wrote: > Hello all. > > Fixed Lingvo 9.0 crashes on startup. > > Changed files: > > comctl32/toolbar.c > > Thanks. The very first one was better (when you fixed only division by zero). Now you're changing path earlier: --- + if(rows <= 0) rows = 1; --- There's no tests currently for that (<=0 isn't tested), could you add them (to test_setrows() I suppose)?

2 2

Re: comctl32/toolbar.c: Fix Lingvo 9.0 crashes on startup
by Nikolay Sivov 12 Jul '09

12 Jul '09

Vladimir Pankratov wrote: > Hello all. > > Fixed Lingvo 9.0 crashes on startup. > > Changed files: > > comctl32/toolbar.c > > Thanks. Maybe it's better to simplify: + idealWrap = (infoPtr->nNumButtons - hidden + (rows-1)) / ((rows == 0) ? (rows + 1) : rows); --- to something like that --- + idealWrap = (infoPtr->nNumButtons - hidden + (rows-1)) / (rows ? rows : 1);

2 1

FW: Re: winequartz.drv Mac OS X UI discontinued?
by Rolf Kalbermatter 12 Jul '09

12 Jul '09

On Thursday July 09, 2009 5:32 PM Chris Robinson wrote: >> With the same argument you could say that writing COM objects has to >> be done in C++. Yet Wine has lots and lots of COM code written all in >> standard C. > >It has to, because the class vtable layout and calling convention can >be different in Windows than how the host system's compiler will generate it. >COM objects have to interface with existing Windows code, and so need >to be setup in memory in a specific way. Not entirely sure where your "It has too" is pointed at. If it is about COM code being written in C then it is not entirly true. All the MS examples about COM nowadays are completely in C++ and some newer API headers seem to not even include the C part. But of course that code is meant to be compiled with Visual C++ and I could see trouble trying to get the exact binary layout with gcc. This is maybe not such a problem with newest gcc but was certainly a problem with older versions. >If OSX will always have Obj-C support, and the Obj-C code can be >restricted to OSX-only code, then the only sticking point, in my eyes, >would be how maintainable it is. After all, if only one or two people >can work with Obj-C code, it can bit-rot that much more quickly. I think this is in fact the major issue here. There is certainly interest in starting such a project but maintaining it is a completely different beast. Rolf Kalbermatter

3 2

winequartz.drv Mac OS X UI discontinued?
by Adam Strzelecki 11 Jul '09

11 Jul '09

Hi, I know that CodeWeavers supports quite nicely Mac builds of Wine, and CrossOver for Mac, yet all of them are X11. There was also once Darwine - an effort to provide Carbon Wine UI driver and Mac optimizations & L&F. Pretty many of those were merged back to Wine, but not winequartz.drv. Do you guys think about reviving winequartz.drv? This would greatly improve Wine on Mac as we could have native Mac fonts handling that's faster than FreeType, Dock icons for Wine applications, and few others. There's still old copy of the it hanging around, but it is abandoned, and no longer compiles with Wine. Or I think it would be cool to write new winecocoa.drv or sthing like that, as Apple officially states that Carbon is deprecated. While it is not well documented, it is pretty easy with Cocoa to make console non-bundled process to be UI foreground process and handle events and Dock: (This code is copyrighted by myself ;P) > int main(int argc, const char * argv[]) { > ProcessSerialNumber psn = {0, kCurrentProcess}; > OSStatus returnCode = TransformProcessType(&psn, > kProcessTransformToForegroundApplication); > SetFrontProcess(&psn); > > NSAutoreleasePool *pool = [[NSAutoreleasePool alloc] init]; > [NSApplication sharedApplication]; > > NSImage *icon = [NSImage imageNamed:@"NSApplicationIcon"]; > [NSApp setApplicationIconImage:icon]; > > [NSApp finishLaunching]; > > NSWindow *window = [[NSWindow alloc] > initWithContentRect:NSMakeRect(0, 0, 100, 100) > styleMask:NSTitledWindowMask| > NSClosableWindowMask|NSMiniaturizableWindowMask|NSResizableWindowMask > backing:NSBackingStoreBuffered defer:NO]; > [window center]; > [window setTitle:@"Test"]; > > NSButton *button = [[NSButton alloc] > initWithFrame:NSMakeRect(10, 10, 80, 80)]; > [button setTitle:@"What?"]; > [button setBezelStyle:1]; > [[window contentView] addSubview:button]; > [button release]; > > [window makeKeyAndOrderFront:NSApp]; > > while(1) { > NSEvent *event = [NSApp > nextEventMatchingMask:NSAnyEventMask > untilDate > :[NSDate distantFuture] > inMode:NSDefaultRunLoopMode > dequeue:YES > ]; > if(event) [NSApp sendEvent:event]; > } > [pool release]; > return 0; > } BTW. I heard that someone previously working for Wine project is now in Apple, it is true? Regards, -- Adam Strzelecki |: nanoant.com :|

20 55

Try #4: user32: Windows test request (cursors/icons)
by Daniel Santos 11 Jul '09

11 Jul '09

Thanks again for your feedback and assistance. This is my 4th revision. I've created a static inline is_win9x() as you suggested. I agree that this should be in include/wine/test.h. One minor complication is that some test files define a BOOL or int "is_win9x" local variable, but that is easy to overcome. A few months ago, I wrote an extensive windows version testing patch for wine/test.h, but I appear to have either mis-placed it or accidentally blown it away! =) I've added win_skip() messages where tests are skipped on win9x to avoid crashing the and I clarified the FIXME (I hope it makes more sense). I'm trying to say that we should add tests to make sure height & width are checked since CreateCursor currently doesn't validate the size of the cursor you want to create against the values returned by GetSystemMetrics(). Finally, by Griswold's suggestion, I renamed test_SetCursor and test_DestroyCursor, adding an underscore prefix and a macro that will fill in the __LINE__ to clean up the code slightly. If you can please run this again on a 9x platform and also an NT platform (XP or vista) I would greatly appreciate it! I just want to make sure everything is happy before submitting it and thanks again for all your help! Daniel

1 0

Re: 2/2 winex11: add XRender based GetSrcAreaStretch
by Austin English 11 Jul '09

11 Jul '09

On Sat, Jul 11, 2009 at 2:08 PM, Roderick Colenbrander<thunderbird2k(a)gmail.com> wrote: > Hi, > > This patch adds a XRender based GetSrcAreaStretch. A lot of work is > offloaded to X (less round trips are needed) and it can take advantage > of hardware acceleration. On Nvidia and AMD drivers blt performance > has improved by 20% in CrystalMark2004 while more optimizations can be > added later on. > > Regards, > Roderick Colenbrander > > > Forgot the patch. -- -Austin

1 0

Appinstall results down for a few days
by Austin English 11 Jul '09

11 Jul '09

My webhost had a security breach, so ssh/ftp is currently disabled. I've been monitoring the results locally, but in case anyone was curious why there haven't been new results in a couple days, now you know. -- -Austin

1 0

Need help testing (acceptex)
by Mike Kaplinskiy 11 Jul '09

11 Jul '09

Can someone try this test on win2000+? This tests the WSAAccept->Defer->AcceptEx scenario, and I've only verified the behavior on xp. Thanks, Mike

2 2

← Newer
1
...
12
13
14
15
16
17
18
...
25
Older →

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

2004

2003

2002

2001

wine-devel July 2009