[PATCH 1/5] d2d1: Implement d2d_d3d_render_target_CreateSolidColorBrush().

[Jacek Caban]

On 06/16/14 14:39, Henri Verbeet wrote:
> On 16 June 2014 14:15, Jacek Caban <jacek at codeweavers.com> wrote:
>> I don't know this how will this be used in the future, so my ideas may
>> not be best fit. For the code that you sent so far, a separated struct
> As far as the API is concerned, brushes are mostly used for drawing
> commands like e.g. ID2D1RenderTarget::FillRectangle() and the like.
> These all take ID2D1Brush pointers. The way the implementation is
> likely to work in the future is that brush types will have an
> associated fragment shader, and some constant buffer data. I.e., a
> typical drawing function implementation would do something along the
> lines of the following:
>
>     struct d2d_brush *b = unsafe_impl_from_ID2DBrush(brush);

Since you have many different vtbls for ID2DBrush implementation, you
can't use the usual vtbl trick for checking if passed pointer is really
our implementation. One way this can be solved is to abuse
QueryInterface, so that you could call:

ID2DBrush_QueryInterface(brush, &IID_brush_struct, (void**)&brush_struct);

QueryInterface could just return the struct directly for that special
IID. And yeah, returning struct instead of an interface is not pretty,
but that's probably fine here. You could even skip AddRef in this case.

> ...
>     ID3D10Device_PSSetShader(device, b->shader);
>     ID3D10Device_PSSetConstantBuffers(device, 0, 1, &b->cb);
> ...
>     ID3D10Device_DrawIndexed(device, ...);

I see, this could really use common code.

>> for all brush types would do the job. I guess that different brush types
>> will store different data in the future, so separated structs will be
>> needed anyway. If having some sort of shared struct is desired, this
>> could be introduced as separated struct:
>>
>> struct d2d1_brash {
>>   /* shared stuff, maybe even refcount */
>> };
>>
>> struct d2d1_solid_brush {
>>   ID2D1SolidColorBrush ID2D1SolidColorBrush_iface
>>   LONG refcount;
>>   struct brush base_brush;
>>   /* Stuff specific to solid brush */
>> };
>>
>> This has some drawbacks like the fact that d2d1_brush can't be easily
>> casted to ID2D1Brush. This may be avoided by design or, with some
> It's mostly the ID2D1Brush -> struct d2d_brush conversion that's the
> issue. If you do the above, you either need to do multiple
> QueryInterface() calls in each drawing function, or introduce a
> private interface to get at the embedded d2d_brush structure, and then
> implement that for every single brush.

The QI trick above makes it one QI call and no extra interface.

> I think the two casts, while not very pretty, are worth it in comparison.

This, again, depends on how this will look when the implementation is
more complete. Such casts are usually a sign of a design problem, but
the final decision is up to you. *If* such casts will be only in brush
creation code, that's not too bad. You could make them even more local
(eg. by replacing d2d_solid_color_brush_init by a function that returns
ID2D1SolidBrush interface pointer, so that caller doesn't need to do any
more cast and the problem does not spread across the code).

>> runtime overhead, d2d1_brush could store a pointer to ID2D1Brush (which
>> would be initialized to solid_brush->ID2D1SoludBrush_iface in this case)
> That would only help for getting an ID2D1Brush from struct d2d_brush,
> but even then, you'd just reintroduce the casts you were trying to
> avoid.

Not really. If you have random d2d_brush instance, you can't cast it
anyway. If it's not random, then you probably should be able to use
specialized structs like d2d1_solid_brush, which could be casted safely.

Jacek