[Mono-devel-list] Re: Texture Brush

[Ravindra]

Hello Duncan,
Thanks for your time. Please see my comments below.

Regards,
Ravindra

On Fri, 2004-02-06 at 05:57, Duncan Mak wrote:
> Hello Ravindra,
> 
> On Tue, 2004-02-03 at 04:27, Ravindra wrote:
> > Please find attached the Cairo side implementation of TextureBrush. I've
> > not debugged this code yet, it has some problems that I'm looking into.
> 
> What are these problems?
I was facing null pointer problem mainly. Anyway, now I have stopped my 
testing. First, I'll do little rework to convert my code in OO-C style and 
then I'll test it again. But, again I'm not very clear as to what argument
types must be used in case of inherited methods. e.g. consider init ()
or setup () inherited from Brush to Texture. Now, I'm not sure what
argument (Brush or Texture) will these methods take when being
implemented in Texture.

> > I would like to change this code to OO-C style, once I get it working.
> 
> It might make sense to go this route from the beginning. The differences
> are significant enough that having this other implementation working
> does not mean that the transition to an OO layout will be seamless.
I'll take care in implementing other brushes.

> About texturebrush.c:
> 
> In general, I think it's pretty good! Two things:
> 
> * GDI+ uses floats primarily and the -I family of functions is just
> there for convenience. For example, for GdipCreateTexture2, it should
> not delegate to GdipCreateTexture2I. The opposite should happen instead.
> Incidentally, all of Cairo uses doubles for their data storage.
Actually, I have used following API there,
cairo_status_t
cairo_surface_clip_rectangle (cairo_surface_t *surface,
			      int x, int y,
			      int width, int height);
It takes int, so I did not have the other option that you are referring
to. FYI, this API is not implemented. There is an "NYI" comment around
it in cairo.h.

> * For all the Matrix operations (Translate, Rotate, Scale, etc), I think
> we are required to set the texture's matrix after performing the
> operation, for an example see the equivalent functions in graphics.c
> (i.e. GdipMultiplyWorldTransform)
OK fine. I'll do that.

> As for the diffs in gdip.h, I would prefer that we start a new
> texturebrush.h and put all the function prototypes there instead. I've
> regretted merging all of the old headers into one single gdip.h; even
> though it is a lot more convenient, it is a monster to maintain. Bit by
> bit, we should move towards having gdip.h only including other smaller
> header files, and I guess that should be true for gdipFunction.cs as
> well, as it's getting pretty long and scary.
I agree with you.