On 17 April 2017 at 22:44, Matteo Bruni matteo.mystral@gmail.com wrote:
2017-04-17 18:14 GMT+02:00 Stefan Dösinger stefandoesinger@gmail.com:
A standard wine list would be better IMHO.
Yeah. Have a look at include/wine/list.h, also you have many examples of its use in wined3d already.
Why not an array? Stefan already mentioned wined3d_buffer.maps, in a fashion.
I haven't really looked at the patches in detail but the general approach seems fine. Thank you for your work!
There are certainly some details to work out, like e.g. the first four patches adding dead code, but in terms of general approach, these are the things I think need resolving first: - How does this interact with the location management? (I.e., wined3d_texture_invalidate_location(), etc.) For example, in 132746, ~resource->map_binding is invalidated and dirty regions are added. How should wined3d_texture_load_location() interpret that when loading for example WINED3D_LOCATION_DRAWABLE? - Does it really make sense to track regions on the level of struct wined3d_resource instead of e.g. strut wined3d_texture? If it does, that would make wined3d_buffer.maps redundant.