ddraw cleanup

Henri Verbeet hverbeet at gmail.com
Tue Oct 13 11:19:09 CDT 2015


On 13 October 2015 at 17:45, Riccardo Bortolato <rikyz619 at gmail.com> wrote:
> While sending the other cleanup patches I worked towards
> wined3d_surface freedom in ddraw and reached a critical point (aka
> it's the last thing I need to do and it's something that needs a
> strong decision):
> in order to get rid of wined3d_surface_get_resource() I need to
> accomodate the wined3d_resource_get_desc() call inside
> ddraw_surface_init() (ddraw/surface.c).
>
> Since the callback is executed when the wined3d_texture->sub_resources
> list isn't ready yet, I cannot use wined3d_texture_get_sub_resource().
>
> So here are the ideas so far:
> - keep wined3d surface in the callback only (really ugly)
> - move the wined3d_resource_get_desc() calls in a loop after
> wined3d_texture_create() (kind of ugly)
> - do magic in wined3d (really unlikely?)
>
> Any ideas?
>
Long term we probably don't need the callbacks at all. These days
their main usage seems to be to set the surface parents, but in the
end those will go away as well.

It may be possible to just move the "desc" fixup code from
ddraw_surface_init() to ddraw_surface_create(), together with the code
that sets up the attachments and cubemap flags. The tricky part may be
the wined3d_texture_create() calls for front and back buffers. I think
it may be safe for those as well, but it would be good to carefully
verify that.



More information about the wine-devel mailing list