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 (
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
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_LINEA
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
> conta
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
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
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 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
wined3
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, 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
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.
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 easi
> > 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.
> Er
> 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 IDirect3DT
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
> IDirect3DS
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);
>
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 forc
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 IDire
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 d
> 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 cle
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 t
> 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. (Releas
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 sur
23 matches
Mail list logo
