[PATCH 2/6] wined3d: Keep track of FBOs through the GL names (v2).
stefandoesinger at gmail.com
Mon Nov 2 05:09:26 CST 2015
> 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.
>> + char name;
>> + 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...
Size: 842 bytes
Desc: Message signed with OpenPGP using GPGMail
More information about the wine-devel