[prev in list] [next in list] [prev in thread] [next in thread] 

List:       wine-devel
Subject:    Re: [PATCH 3/5] wined3d: Get rid of wined3d_device_color_fill().
From:       Henri Verbeet <hverbeet () gmail ! com>
Date:       2014-08-22 12:39:34
Message-ID: CAOsNvwwa+HMjWWuS7jwwMc5TYtN7iiwPBsoRvyQ_6D6SRs2-XA () mail ! gmail ! com
[Download RAW message or body]

On 22 August 2014 13:14, Stefan Dösinger <stefandoesinger@gmail.com> wrote:
> Am 2014-08-22 12:32, schrieb Henri Verbeet:
> > +    if (desc.pool != WINED3D_POOL_DEFAULT && desc.pool != \
> > WINED3D_POOL_SYSTEM_MEM) +    {
> > +        WARN("Color-fill not allowed on surfaces in pool %#x.\n", desc.pool);
> > +        return D3DERR_INVALIDCALL;
> > +    }
> I realize that this just keeps existing code in place, but as far as I can see this \
> check is redundant. There's already a somewhat strange check right above this one \
> that tests if the surface is a render target or in WINED3D_POOL_DEFAULT. Unless I \
> missed a way to create a non-default pool render target testing only for \
> WINED3D_POOL_DEFAULT should be enough. 
It's probably a bug that we don't enforce rendertargets to be in the
default pool, but there's currently nothing to prevent you from
creating e.g. a texture with D3DUSAGE_RENDERTARGET and
D3DPOOL_MANAGED. You'll get a FIXME from surface_init(), but creation
will succeed.

> The patch also works only as long as we keep the D3DUSAGE_RENDERTARGET check in \
> wined3d_device_set_rendertarget_view and not move it to \
> wined3d_rendertarget_view_create. Is that your intention? 
Yes, at least for the time being. Moving that check wouldn't work well
for depth/stencil views, and I haven't quite decided yet if the
blitter interface should use views or just a resource + index,
although I'm leaning towards the latter.


[prev in list] [next in list] [prev in thread] [next in thread]