H. Verbeet wrote:
I also suspect there might be a couple of circular references in the
form of device-stateblock-object-device, but I haven't had time to
really look into that yet. I *think* wined3d shouldn't keep references
to objects in the device's Set* methods, but I remember that when I
On 24/02/06, Robert Shearman [EMAIL PROTECTED] wrote:
I am not at all familiar with the wined3d code, but from what I've seen
discussed here it would seem that wined3d shouldn't keep references to
any objects. Instead the other objects should release the corresponding
wined3d object when they
Hi,
If you run the test on d3d9 or using oliver's full d3d8 patch, you'll
notice that not all memory is returned when quitting the program. (In
3dmark2001 this is a big issue as because of this we are out of memory
after running a few demos) The problem appears that wined3d surfaces
contain a
Hi,
From the multitexture demo:
void loadTexture( void )
{
D3DXCreateTextureFromFile( g_pd3dDevice, test.bmp, g_pTexture_0 );
D3DXCreateTextureFromFile( g_pd3dDevice, checker.bmp, g_pTexture_1 );
g_pd3dDevice-SetSamplerState(0, D3DSAMP_MINFILTER, D3DTEXF_LINEAR);
On 24/02/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
Are you sure that the Direct3DDevice9 should be released? Windows addrefs the
DirectDraw interface when a surface is created, I'd be surprised if Microsoft
changed that behavior in d3d8 or d3d9. From your description I'd say that
there are
On 24/02/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
remains open is if not unsetting the texture stages is a bug too. Can someone
check on Windows if (a) creating a surface or texture addrefs the
Direct3DDevice, and if (b) assigning a texture to a texture stage addrefs the
Texture? If (a)
Hi,
During the d3d8 - wined3d transition I noticed one huge refcounting issue
which affects both d3d8 and d3d9. The issue is illustrated by running
http://www.codesampler.com/source/dx9_multitexture.zip (the same demo is
available for dx8) and then modify wined3d's globalChangeGlRam in
O right. From the conversation on IRC I got the impression the issue
was the application calling the device's Release before calling the
surface's Release. Similar to the Surface / Texture issue. On windows
that should work, on wine it will probably fail at the moment.
Releasing the device after
On 13/02/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
I'd suggest that you send a patch taking whatever way you like, and ask AJ for
his opinion.
If nobody else has a real opinion on the subject, I'll probably just
implement your idea, and see what problems I'll run into.
I'm not sure that connection is much more complex than the way it
currently is. Right now the d3d7/8/9 wrapper objects are responsible
for cleaning up their wined3d object, while with that change the
wined3d object would become responsible for deleting the d3d7/8/9
objects.
Err, the
Hi,
Well, I agree it's not a great construction. I'm just not sure if
using the container in that way makes things much better. It would
mean having to retrieve the surface container in each call to
IDirect3D9Surface_Release.
Do you think it might be a performance problem?
You can't easily
On 13/02/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
Hi,
Well, I agree it's not a great construction. I'm just not sure if
using the container in that way makes things much better. It would
mean having to retrieve the surface container in each call to
IDirect3D9Surface_Release.
Do you
I'm not sure, probably not that much, but it depends on whether the
AddRef / Release functions are called a lot. If we use GetContainer,
it would make a call to QueryInterface. If the surface hasn't got a
container it makes a call to GetDevice and returns the wined3d device.
We'd have to
I've run into a somewhat annoying problem with d3d9/wined3d recently.
It appears that on d3d9 on Windows a surface either forwards its
AddRef / Release calls to its container if it has one, or just shares
the refcount directly. Either way, it comes down to the same thing.
Calling AddRef on the
One way to solve this would be to have wined3d handle the reference
counting for d3d7/8/9 as well, so that their AddRef/Release calls just
call AddRef/Release on the wined3d object they wrap. That would also
mean we need to pass a pointer to the d3d7/8/9 object's cleanup
function. (Releasing
On 12/02/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
Could it be that d3d9 surfaces and textures are the same objects on windows?
What happens if you QueryInterface the surface for the texture GUID?
It returns 0x80004002 (E_NOINTERFACE). Same thing for the reverse.
When the app releases the
With the solution mentioned in my previous post, d3d7/8/9 objects
would essentially not be real COM objects on their own, they would
just wrap the relevant wined3d AddRef/Release functions, and not have
refcounts of their own. Wined3d would be responsible for it's own
refcounting, and
Hi,
I've thought over this: If you want to connect the IWineD3DTexture and
IWineD3DSurface refcounts only, then there's no problem for me. If you want
to connect the Texture's and Surface's Parents refcount, then you have do the
same for the rendertargets and the swapchain(I guess that Windows
On 12/02/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
Hi,
I've thought over this: If you want to connect the IWineD3DTexture and
IWineD3DSurface refcounts only, then there's no problem for me. If you want
to connect the Texture's and Surface's Parents refcount,
Are you talking about
Hi,
Are you talking about IDirect3DSurface9 = IDirect3DTexture9 or do
you mean IDirect3DSurface9 = IWineD3DSurface?
I meant IWineD3DSurface = IWineD3DTexture and Parent(IWineD3DSurface) =
Parent(IWineD3DTexture). The first case has no consequences for ddraw, if the
secound one is forced by
Hi
IDirect3DTexure9::Release
{
ULONG ref = This-ref--;
if(ref == 0)
{
for(all surfaces in this container)
{
surfaceImpl-container = NULL;
/* Or place this call in WineD3DTexture::Releaase*/
IWineD3DTexture_Release(This-wineD3DTexture);
/*
On 12/02/06, Stefan Dösinger [EMAIL PROTECTED] wrote:
I meant IWineD3DSurface = IWineD3DTexture and Parent(IWineD3DSurface) =
Parent(IWineD3DTexture). The first case has no consequences for ddraw, if the
secound one is forced by WineD3D this would cause a connection between
IDirect3DSurface9 =
Connecting the parents' refcounts wasn't really the idea, at least not
directly. I think it's probably a good idea to have as little logic in
the wrappers as possible. However, they are of course indirectly
connected through wined3d; The connection between IDirect3DSurface9
and
23 matches
Mail list logo
