On 10/22/06, Ivan Gyurdiev <[EMAIL PROTECTED]> wrote:
Constant is convenient, but if it can't meet all necessary requirements,
I wouldn't hesitate to drop the idea - never compromise on design in
favor of C optimizations. Tomorrow's hardware will make any
non-algorithmic optimizations irrelevant
and we loose the ability to
set up a constant table in the code.
The constant table is usually a bad idea, and this demonstrates why -
the texture format table is another one where somehow we've been able to
get away with staying constant, but I am sure issues will show up in the
future invol
On Friday 20 October 2006 05:52, Stefan Dösinger wrote:
> Am Donnerstag 19 Oktober 2006 02:46 schrieb Robert Lunnon:
> > I'm still trying to work this out, see below, but I have a silly
> > question, how *should* IWineGDISurfaceImpl_Blt behave if args 2 & 3 are
> > NULL IE DestRect and SrcSurface
Makes sense - reapplying the stateblock causes the states to be written
back to the same stateblock *and* GL state to be applied. What we want
is the states to be applied without being written back to the same
stateblock.
You can add if(capturing) write_to_update_stateblock(); else
apply_sta
> diff --git a/dlls/winequartz.drv/quartzdrv_carbon.c
> b/dlls/winequartz.drv/quartzdrv_carbon.c
> new file mode 100644
> index 000..082970d
> --- /dev/null
> +++ b/dlls/winequartz.drv/quartzdrv_carbon.c
...
> +#import
import is nasty. Can't you use include instead?
Huw.
message for the wined3d folks...
running the d3d tests under valgrind gives this list of calls of memcpy
with overlapping buffers, which could give bad results (depending how
the buffers overlap)
is this a side effect of the tests, a harmless warning or something to
be fixed ?
A+
==10159== So
So what commands are needed to just update it?
I understand how to set it up from what you have said.
Philip V. Neves wrote:
> I'm starting to see that unless we whine and complain in Bugzilla that
> nothing gets done on this issue. So I'm comming on to the wine
> developers group to complain. This is a bug that is long and
> contentious. Its preventing a large number of perfectly good apps to
> b
Hello wine-hackers,
I'd like to offer to purchase Episode 1 for any wine developer who is willing
to work on fixing the graphical artifacts. I'll make the same offer for
Episode 2 when it comes out (projected for the holiday season this year). All
I want is some concrete evidence that you are
The following change to dlls/advapi32/lsa.c
revision 1.16
date: 2006-10-20 13:02:57 +; author: julliard; state: Exp; lines: +40
-32
Eric Pouech <[EMAIL PROTECTED]>
advapi32: Plug a couple of memory leaks.
causes the following new warning:
lsa.c:64: warning: 'ptr' might be used
I'm starting to see that unless we whine and complain in Bugzilla that
nothing gets done on this issue. So I'm comming on to the wine
developers group to complain. This is a bug that is long and
contentious. Its preventing a large number of perfectly good apps to be
used. Wonder when if ever
Matthew Kehrer wrote:
> Is there a way I can convert a source tarball I download to a local GIT
> repository?
Not really.
> I have dial-up a home, but I know of a place where I can bring my flash
> drive and use it to get the tarball as GIT does not have resume support.
>
> Is this possible?
I
I am looking at how to track whether memory has been allocated or
freed. The SCRIPT_STRING_ANALYSIS opaque point in usp10 can be freed in
a number of places. It seems that Windows handles this by checking a
list of allocated storage as the passed value of a
SCRIPT_STRING_ANALYSIS could be inv
13 matches
Mail list logo
