[PATCH 2/6] wined3d: Keep track of FBOs through the GL names (v2).

[Stefan Dösinger]

> Am 02.11.2015 um 11:48 schrieb Henri Verbeet <hverbeet at gmail.com>:
> I think I'll hold off on this until the regression from
> 1ca9dfc8ee25f4ae188fdacd4d3d56046cef8003 is resolved, but you can
> probably split the logging changes into their own patch.
Fair enough.

> 
>> +            char name[32];
>> +            sprintf(name, "Color attachment %u", i);
>> +            context_dump_fbo_attachment(gl_info, target, GL_COLOR_ATTACHMENT0 + i, name);
> sprintf() is one of those things that's usually best avoided. In this
> case the string is mostly redundant as well, since you have the
> attachment enum.
I prefer "GL_COLOR_ATTACHMENT0" over "0x8CE0", but I guess wine_dbg_sprintf would also do the job without requring my own sprintf.

>> +    entry = HeapAlloc(GetProcessHeap(), HEAP_ZERO_MEMORY,
>> +            FIELD_OFFSET(struct fbo_entry, key.objects[object_count]));
>> +    entry->d3d_render_targets = HeapAlloc(GetProcessHeap(), 0,
>> +            gl_info->limits.buffers * sizeof(*entry->d3d_render_targets));
>> +    context_create_fbo_key(&entry->key, render_targets, depth_stencil, color_location, ds_location,
>> +            gl_info->limits.buffers);
>> +    memcpy(entry->d3d_render_targets, render_targets, sizeof(*entry->d3d_render_targets) * gl_info->limits.buffers);
>> +    entry->d3d_depth_stencil = depth_stencil;
> Why HEAP_ZERO_MEMORY? Do we no longer initialize all fields?
I don't trust the padding of the structure array after the 4 byte DWORD on 64 bit architectures.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.winehq.org/pipermail/wine-devel/attachments/20151102/ff7022f3/attachment.sig>