Austin English <austinenglish(a)gmail.com> wrote:
> @@ -2554,7 +2554,7 @@ INT WINAPI WS_getsockopt(SOCKET s, INT level,
> }
> *(DWORD*)optval = pretendtime++;
> *optlen = sizeof(DWORD);
> - return ret;
> + return SOCKET_ERROR;
> }
Filling out optval and optlen but returning SOCKET_ERROR doesn't make
sense. Probably Eye-Fi doesn't change the return value. What kind of
socket both of the applications do pass?
--
Dmitry.
Hi,
what's the state of CD-ROM support on the Mac?
ntdll/cdrom.c contains quite a few #ifdef apple.
I'm asking because the mcicda currently uses these ioctl:
1. READ_RAW
2. READ_TOC
3. READ_Q -> POSITION
MCICDA could be changed to avoid the third one entirely
-- when using the dsound output. Would that
be enough to use mcicda on MacOS to play music?
Thanks for your help,
Jörg Höhle
I believe
commit be332326ba8fc3def406c5f29adf04fbe9a83976
Author: Andrew Eikum <aeikum(a)codeweavers.com>
Date: Wed Apr 27 09:12:36 2011 -0500
is causing the following build failures on my nightly FreeBSD testers:
mmdevdrv.c:463:20: error: 'AFMT_S24_PACKED' undeclared (first use in this function)
mmdevdrv.c:476:16: error: 'AFMT_FLOAT' undeclared (first use in this function)
mmdevdrv.c:854:24: error: 'AFMT_FLOAT' undeclared (first use in this function)
mmdevdrv.c:863:24: error: 'AFMT_S24_PACKED' undeclared (first use in this function)
mmdevdrv.c:1084:24: error: 'SNDCTL_DSP_HALT' undeclared (first use in this function)
Looks like some autoconfigury is not working or incomplete?
Gerald
Gerald Pfeifer <gerald(a)pfeifer.com> writes:
> This is the first hunk of a patch a few days ago; testbot.winehq.org
> thinks it's fine: https://testbot.winehq.org/JobDetails.pl?Key=9291
You don't need casts. If the variable has the wrong type you can change
that.
--
Alexandre Julliard
julliard(a)winehq.org
Hi guys,
I've put together the following doc for the introduction of message
contexts. It's still a bit raw but I'd improve it for the wiki
version.
Could you please have a look and help proofread it?
I'd like to ensure I didn't miss an important step.
Thanks in advance.
Frédéric Delanoy
PS: BTW what is the reference version? en_US.po or en.po?
*********
Adding one/more message contexts (ADD LINK TO EXTERNAL DOC) (QUICK MC
EXPLANATION)
Prerequisite: enable maintainer mode using ./configure --enable-maintainer-mode
(you might have to add some development packages; check with your distribution
for infos).
1. Locate strings to be "altered"
Say you have in your localized po file:
#: file1.rc:123 file2.rc:456
msgid "ambiguous word"
msgstr "translation"
and you want to disambiguate, you'd do the following
2. Find appropriate translations
- check the respective rc entries
(in file1.rc line 123)
FOO "ambiguous word"
(in file2.rc line 456)
BAR "ambiguous word"
and find their meaning/context (e.g. using some code browsing
tools, like cscope to find references; running the program is
recommanded, ...)
3. Add the messages contexts
- The following syntax is used: "translation" -> "#msgctxt#your
context#translation"
- You end up with sthg like
FOO "#msgctxt#context #ambiguous word#"
Similarly
BAR "#msgctxt#context 2#ambiguous word#"
3. Run 'make depend && make'
4. Edit your po file to add the new translations
5. Ideally, remove the "#, fuzzy" automatically inserted in the
En_US.po reference
file (and En.rc ).
6. Run 'make' again and test your changes.
Hi,
I spent a few hours debugging wined3d performance today. No, I found no magic
fix for the slowness, just some semi-usable data.
First I wrote a hacky patch to avoid redundant FBO applications. This gave a
tiny, tiny performance increase, see http://www.winehq.org/pipermail/wine-
devel/2011-April/089832.html.
The main investigation concerned redundant shader applications. The aim was to
find out how many of our glBindProgramARB calls are re-binding the same
program, and how much this costs. Depending on the game between 20% to 90% of
all BindProgram calls are redundant. I'll attach my debug hack so others can
test their own apps. I used ARB shaders for testing because they can apply
vertex and fragment programs separately.
This brings up two questions:
(a) How much does this cost
(b) Why does this happen
The costs: In my draw overhead tester hacking out the redundant apply calls
improved performance a lot, from about 101 fps to 157 fps. The biggest part of
that are the GL calls. Without them but the remaining shader logic I get 144
fps.
Unfortunately this does not translate to any performance gains in real apps. I
tried to filter out the redundant apply calls in the simplest way possible:
Track the current value per wined3d_context and check before calling
glBindProgramARB. This gave the 144 fps in the draw overhead tester, but no
measurable increase in any other apps(I tested StarCraft 2, HL2, Team Fortress
2, World in Conflict and a few others)
Given the amount of redundant apply calls and the cost of them in the draw
overlay tester I have expected at least some improvement. Certainly not a 50%
performance increase(the draw overlay tester performs no shader changes at all
in the draw loop), but at least a 2-3% gain. So far I have no explanation why
I didn't see that.
But why do those redundant apply calls happen? It seems like the state
dirtification comes all the way from the stream sources and/or vertex
declaration. STREAMSRC is linked to VDECL, which is linked to VERTEXSHADER,
which in turn reapplies the pixel shader. This means redundant vertex and
pixel shader applications. Separating those states will be a major challenge.
The vdecl<->vshader link shouldn't be needed any more, except in rare cases
where GL_ARB_vertex_array_bgra is not supported and the application switches
one attribute from D3DDECL_D3DCOLOR to a non-d3dcolor attribute. If the vertex
shader changes we still have to reparse the vertex declaraion and reapply the
stream sources because the vshader determines the stream numbers. Maybe we can
reduce the number of times this happens by ordering stream usages and indices
to make sure shaders with compatible input get the same stream ordering.
vdecl and streamsrc are pretty related. If the vdecl is changed we have to
reapply the stream sources. The other way around shouldn't cause problems
though. There's no need to reapply every stream except the changed ones and
there's no need to reapply the vertex shader.
The vertex and pixel shader are linked for a few reasons: The shader backend
API offers only a function to set both. Basic GLSL only offers a function to set
both at once(GL_ARB_separate_shader_objects changes that). And even in ARB the
pixel shader input may require some changes in the vertex shader output to get
Shader Model 3.0 varyings right.
The shader backend API can be changed, but it has to be done in a way that
doesn't hurt GLSL without ARB_separate_shader_objects. If we have classic GLSL
we have to keep the link. With ARB we can conditionally reapply the vertex
shader if the ps_input_signature is changed.
To complicate matters there are additional states that affect the shaders, like
fog, textures, clipping. We don't keep track of those dependencies.
So it's a lot of work to clean up these state dependencies and we don't know
how much it'll gain us :-(
Stefan
Alexey wrote:
> i currently digg in comctl32 to find why my app fails. I found that
> string conversation AtoW in some places silently fails. The problem is
> that the destination for string is just a fresh pointer (not NULL).
> Str_SetPtrAtoW check if it is NULL pointer and if not it trys to
> ReAlloc. There was no Alloc before so ReAlloc returns NULL
The code looks like it assumes that pointer is always
managed by Alloc/ReAlloc/Free. In what context is
the destination a fresh, non-Alloc'd pointer?
Perhaps that's where the bug lies.
Your proposed solution would pass a non-Alloc'd
pointer to Free, which doesn't seem good.
- Dan
Hi,
While running your changed tests on Windows, I think I found new failures.
Being a bot and all I'm not very good at pattern recognition, so I might be
wrong, but could you please double-check?
Full results can be found at
http://testbot.winehq.org/JobDetails.pl?Key=10648
Your paranoid android.
=== WNT4WSSP6 (32 bit ddrawmodes) ===
ddrawmodes.c:520: Test failed: EnumDisplayModes returned: 80070057
=== W7PROX64 (64 bit ddrawmodes) ===
Timeout