On Sat, Jul 23, 2005 at 10:22:09AM +0200, Alexandre Julliard wrote:
Glenn Wurster [EMAIL PROTECTED] writes:
GDI is a very good example of the problem of throwing an exception
where the application never intended one to be thrown. If ESP is bad
we clobber something. GDI, however, is not
Glenn Wurster wrote:
of new engine. If someone is indeed working on a new GDI engine, than
I'd be interested in finding out more and perhaps helping out,
although I don't have a lot of time on my hands.
Maybe the ReactOS GDI engine could be used for starters.
Currently in ReactOS the
Felix Nawothnig wrote:
Dimi Paun wrote:
We need to get rid of that seperation - either the DIB should be
stored fully on X side (which would require to add some features to
X) or fully on Wine side (by implementing a GDI renderer in Wine).
You can't have it fully on the X side, since you
Glenn Wurster [EMAIL PROTECTED] writes:
GDI is a very good example of the problem of throwing an exception
where the application never intended one to be thrown. If ESP is bad
we clobber something. GDI, however, is not the only example. If we
fix it so that GDI does not throw exceptions,
I've been doing some debugging of the exception handler and have come
across a problem for which I'm not sure what the best solution is. It
involves an application using the ESP for something other than the
stack.
The current DIB code uses protection to detect when the application
modifies the
Glenn Wurster wrote:
Comments? Suggestions?
Our current DIB implementation is an ugly hack. We need a real DIB
implementation, either as a complete GDI engine in Wine or as an X11
extension.
Some work has been done on a GDI engine in Wine by Transgaming a couple
of years ago but it
Our current DIB implementation is an ugly hack. We need a real DIB
implementation, either as a complete GDI engine in Wine or as an X11
extension.
But is it the DIB implementation that is really at fault here or is it
the fact that we are adding extra exceptions and can't be sure what
the
Glenn Wurster wrote:
Our current DIB implementation is an ugly hack. We need a real DIB
implementation, either as a complete GDI engine in Wine or as an X11
extension.
But is it the DIB implementation that is really at fault here or is it
the fact that we are adding extra exceptions and can't
From: Felix Nawothnig [EMAIL PROTECTED]
We need to get rid of that seperation - either the DIB should be stored
fully on X side (which would require to add some features to X) or fully
on Wine side (by implementing a GDI renderer in Wine).
You can't have it fully on the X side, since you
Dimi Paun wrote:
We need to get rid of that seperation - either the DIB should be stored
fully on X side (which would require to add some features to X) or fully
on Wine side (by implementing a GDI renderer in Wine).
You can't have it fully on the X side, since you need direct memory access
From: Felix Nawothnig [EMAIL PROTECTED]
You can't have it fully on the X side, since you need direct memory
access
Direct memory access can be done using X11 SHM, no?
But then you lose network transparency.
(non-synchronized I might add) to the DIB data.
MSDN says:
Windows NT/2000/XP:
The real DIB, used for GDI calls, is stored on X side but the DIB
surface, used for direct access, is stored on Wine side and we need to
keep them in sync by catching reads / writes to the DIB surface.
We need to get rid of that seperation - either the DIB should be stored
fully on X side
Dimi Paun wrote:
Direct memory access can be done using X11 SHM, no?
But then you lose network transparency.
I'd think that apps directly accessing the surface memory are either
games or do some other kind of realtime graphics so network transparency
isn't worth anything there (since we'd
On Sat, 23 Jul 2005, Felix Nawothnig wrote:
Dimi Paun wrote:
Direct memory access can be done using X11 SHM, no?
But then you lose network transparency.
I'd think that apps directly accessing the surface memory are either games or
do some other kind of realtime graphics so network
14 matches
Mail list logo
