wine-devel July 2005

wine-devel@winehq.org

152 participants
298 discussions

Theming & code duplication
by Frank Richter 29 Jul '05

29 Jul '05

Hi, somewhat recently I sent some code to wine-patches to add button theming; if you have glanced at it, despite utilizing subclassing, code was duplicated from the button code in user. In particular, the themed button does its own state management. The reason is that upon state changes, the user32 button control does some repaints internally, ie calling the paint function directly - those can't obviously be hooked by subclassing alone. In early versions I had the themed button painted over after state-changing messages, but that causes visible flickering (since the button is first painted in "classic" style and the themed style is painted above that). The basic problem - painting that is hard to hook into - will probably also arise on other controls. There are some ideas and approaches to deal with the problem that came up (and the results from discussion with Kevin): - Ignore. Have ugly flickering. - Change the classic controls to use InvalidateRect() instead when internal painting functions are called, so painting messages can be hooked. That would deviate from native behaviour, though (and also occasionally less efficient when the control just paints some change). - Use some magic message the control sends to itself to do some painting which is then hooked. Makes things more complex, could cause compatibility issues with apps that may not handle this message and is incompatible with native. - Code duplication - e.g. in the case of buttons, do state management in the themed class as well. - Static libraries - implement the standard controls in a static library and allow for hooks to override painting (in C++ you'd use virtual methods). Both user32 and comctl32 would link against that lib, and the latter would provide alternative painting functions. Binarily equivalent to code duplication, but not that bad in the source code. For me it looks like a good compromise, though, Kevin noted that "Historically static libs have not gone over very well". I don't like the current code duplication for theming that much, but I'm a bit unsure what else could be done. Perhaps you have some comments or suggestions, and hopefully there will be some consent of what approach would be best for Wine. Thanks for reading, -f.r.

2 4

Re: DINPUT: Detect force feedback joysticks (FF #1)
by Alexandre Julliard 29 Jul '05

29 Jul '05

Daniel Remenak <dtremenak(a)gmail.com> writes: > 1. Configure checks for the availability of a new enough linux/input.h > to support force feedback. This pretty much means any kernel 2.6 or > kernel 2.4.x with the ff patchset found at > http://sourceforge.net/projects/libff/. Some of the structures were > changed without changing the version define, so this check is > necessary. Why do you need to check the structure since you are not using it? Shouldn't you simply do a #ifdef on the ioctl code or whatever else that you use and may not be defined? -- Alexandre Julliard julliard(a)winehq.org

3 4

Another AppDB screenshot problem...
by James Liggett 28 Jul '05

28 Jul '05

Hi, Tonight I tried to submit a shot for Palm Desktop 4.1 and it gave me this error: Unable to move screenshot from to data/screenshots/originals/781 What's going on? Thanks a lot, James Liggett

3 5

Re: KERNEL32: Re: Fix thread tests on WinME
by Saulius Krasuckas 28 Jul '05

28 Jul '05

* On Fri, 22 Jul 2005, Saulius Krasuckas wrote: > * Felix Nawothnig wrote: > > > > Tested on Wine and WinXP. I couldn't verify it on WinME since I don't > > have it but since this is quite trivial... *crosses fingers* > > Though three tests are still failing: > > | thread.c:293:not restricted, assuming consistent behaviour > | thread.c:412: Test failed: access restrictions obeyed > | thread.c:414: Test failed: access restrictions obeyed > | thread.c:488: Test failed: access restrictions obeyed Felix, I have reverted part of your patch and tested this. Reversion is doing fine on WinME -- zero failed tests. Didn't tested on XP or so. Is this acceptable? If so, feel free to submit it under own name. Or correct the code. :-) Index: dlls/kernel/tests/thread.c =================================================================== RCS file: /home/wine/wine/dlls/kernel/tests/thread.c,v retrieving revision 1.22 diff -p -u -r1.22 thread.c --- dlls/kernel/tests/thread.c 25 Jul 2005 11:07:54 -0000 1.22 +++ dlls/kernel/tests/thread.c 28 Jul 2005 21:55:41 -0000 @@ -409,9 +409,11 @@ static VOID test_thread_priority(void) obey_ar(SetThreadPriority(access_thread,1)==0); obey_ar(GetThreadPriority(access_thread)==THREAD_PRIORITY_ERROR_RETURN); if (pSetThreadPriorityBoost) - obey_ar(pSetThreadPriorityBoost(access_thread,1)==0); + ok(pSetThreadPriorityBoost(access_thread,1)==0, + "SetThreadPriorityBoost did not obey access restrictions\n"); if (pGetThreadPriorityBoost) - obey_ar(pGetThreadPriorityBoost(access_thread,&disabled)==0); + ok(pGetThreadPriorityBoost(access_thread,&disabled)==0, + "GetThreadPriorityBoost did not obey access restrictions\n"); obey_ar(GetExitCodeThread(access_thread,&exitCode)==0); ok(CloseHandle(access_thread),"Error Closing thread handle\n"); } @@ -485,7 +487,7 @@ static VOID test_GetThreadTimes(void) if(access_thread!=NULL) { error=GetThreadTimes(access_thread,&creationTime,&exitTime, &kernelTime,&userTime); - obey_ar(error==0); + ok(error==0, "GetThreadTimes did not obey access restrictions\n"); ok(CloseHandle(access_thread)!=0,"CloseHandle Failed\n"); } creationTime.dwLowDateTime=99; creationTime.dwHighDateTime=99;

2 1

Const Function Parameters?
by Michael Carlson 28 Jul '05

28 Jul '05

I've been doing some oprofille tests with wine running fce ultra, the 8-bit Nintendo emulator. I found that when running a rom for 60 seconds, more than 99% of the CPU utilization for winex11drv (which uses the most of all components of wine in this case) is in the same function : convert_888_to_0888_asis (in dlls/x11drv/dib_convert.c). I've also found that marking a couple of parameters of that function const (that I believe should be marked const anyways), CPU usage in that function drops measurably with oprofile. As far as I know, parameters that aren't modified in a function should be marked const anyways, to send the right hint to the compiler. Since it actually turns out to be faster too, it seems worth it to me. Here are the results from oprofile before the change: 21982 99.2012 convert_888_to_0888_asis 22078 99.1735 convert_888_to_0888_asis 22207 99.1605 convert_888_to_0888_asis 22161 99.1544 convert_888_to_0888_asis 22158 99.2253 convert_888_to_0888_asis and after: 21828 99.1731 convert_888_to_0888_asis 21769 99.2296 convert_888_to_0888_asis 21835 99.3313 convert_888_to_0888_asis 21868 99.1027 convert_888_to_0888_asis 21601 99.1508 convert_888_to_0888_asis On average, it went from 22117 (context switches I believe?) to 21780, about a 1.5% improvement. The same test was run with a script each time (run fceu with the same rom, kill it after 60 seconds). I'm assuming the percentages (the second column in this chart) don't matter much, because this function we're examining takes up an overwhelming amount of the function's CPU (> 99%), so its percentage depends largely on how many context switches other functions took up. I've taken the liberty of providing a diff that patches all the functions in this file to use const parameters where appropriate. I don't get any compiler warnings with this compiling with gcc 4.0.1. Should I submit this to wine-patches? This would be my first patch to wine (or any open-source project, period). I'd appreciate some feedback before I try for it. Thanks in advance!

5 6

More insatllers
by Oliver Stieber 28 Jul '05

28 Jul '05

Hi, The axis and allies 2 demo installer requires native ole to install. (http://www.atari.com.au/games/downloads.do?id=24) On the up side, The bards Tale and Juiced demos now install more-or-less correctly. The Bards Tale uses a WISE + MSI installer and has some problems with labels being prefixes with things like {Arial_80} which is a little annoying.(http://www.download.com/The-Bard-s-Tale-updated-demo/3000-8024_4-… Juiced has some problems with bitmaps in the installer. (http://www.download.com/Juiced-final-demo/3000-7534_4-10302658.html?tag=lst…) ___________________________________________________________ How much free photo storage do you get? Store your holiday snaps for FREE with Yahoo! Photos http://uk.photos.yahoo.com

1 0

Use Gecko to render HTML
by Jacek Caban 28 Jul '05

28 Jul '05

Hello. I've sent a patch that makes MSHTML use Gecko to render HTML. Unfortunately, it uses Windows Gecko, not Linux one. Alexandre wrote me that it's impossible to get perfect support for XEmbed container, so, although my implementation was enough for Gecko, it can't go to CVS and I should use Windows one. So, as of now, support for the Linux version went into trash and I've sent this patch. Well, I don't give up with Linux version, I have an other idea, but that's not for the nearest future. One plus is that the Windows version is much simpler... Now it's time to write about this patch. For now it can use Gecko installed with Mozilla Suite or Mozilla ActiveX Control - it could use any Gecko-based product, but we have to be able to search for it (every Gecko-based product has its own registry settings for Gecko path). I'm planning to add Firefox support, but it doesn't work yet and I have to find why. If you think there should be support for any other application, please let me know. As our shdocvw still uses Mozilla ActiveX Control, I think it should be preferred (it's the first one on the search list and it's smallest). In future, when we'll implement shdocvw on top on MSHTML and get rid of Mozilla ActiveX Control dependency, I think it will be better to have a package like wine-gecko with an installer, downloaded automatically when needed (well, not automatically in MS sens, user will be informed about it ;-) ). We need a very limited version of Gecko, so it will be just small package. What does this patch change? You may see IE working on Gecko engine! Not much of its functionality is implemented yet, but a HTML document is displayed. Soon there will be more! To see how it works for your program, probably you will have to set shdocvw to native (and usually urlmon, maybe wininet) and mshtml as builtin. Thanks, Jacek

1 0

[WINEHQ] Lots of buggy < and >
by Francois Gouget 28 Jul '05

28 Jul '05

Reading WWN 284 I noticed the following line: > stabilizing for release &. And sure enough the source XML is buggy: > stabilizing for release &<g&>. I believe the intent was the following to deal with the double parsing: > stabilizing for release &lt;g&gt;. But really this double parsing is a major pain. Can't we get rid of it? Because it's causing a lot of bugs: $ egrep "<.*>" wwn/*.sgml | grep -v "who=" | wc -l 190 And it's not just missing grins either. For instance in WWN 125: > gdb <gdb remote protocol> winedbg <Win32 debug API> wineserver and all the reader sees is: > gdb winedbg wineserver which is totally wrong of course. And in WWN 149: > #include <comcat.h> <br /> > #include <oaidl.h><br /> > #include <objbase.h><br /> > #include <objidl.h><br /> ... all the reader sees is: > #include > #include > #include > #include ... Not very informative! -- Francois Gouget fgouget(a)free.fr http://fgouget.free.fr/ Hiroshima '45 - Czernobyl '86 - Windows '95

2 1

Re: patch for libs/wine/mmap.c making wine running on FreeBSD 5.x
by Alexandre Julliard 28 Jul '05

28 Jul '05

"jean-marc DETREZ" <jm.detrez(a)cegetel.net> writes: > I made a little correction of "try_mmap_fixed" because it's seems to me > that the function didn't really test the result (vec). That's the way it should be, we don't care if the page is in core or not, we only want to know if something is mapped there. -- Alexandre Julliard julliard(a)winehq.org

2 1

Re: [wined3d] repack nonpower2 textures
by Lionel Ulmer 28 Jul '05

28 Jul '05

On Thu, Jul 28, 2005 at 01:13:02PM +0100, Oliver Stieber wrote: > repacking can be quite CPU intensive and warhammer 40k is the only game so far > that needs nonpower2 texture repacking so it's turned off by default but can be turned > on via the following registry key: > HKEY_CURRENT_USER/Software/Wine/Direct3D Nonpower2Mode [repack] Is there a way to automagically detect the need for this feature ? If not, how are we going to maintain the list of 'game-specific' WineD3D configurations ? Should we ship this as part of 'wine.inf' or create a new .inf that would install automatically the correct keys ? Lionel -- Lionel Ulmer - http://www.bbrox.org/

1 0

← Newer
1
2
3
4
5
6
7
...
30
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 2005