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.
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
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
* 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;
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!
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
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
"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
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/