Re: [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 :
> 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.