[cairo] Write ups on Microsoft Avalon

[Ravindra]

Hi Carl,

On Thu, 2004-05-13 at 18:59, Carl Worth wrote:
> Thanks for your feedback. It looks quite useful. I'll do my best to
> address each issue you've raised.

You are most welcome. However, I must be saying thanks for your efforts
:-)

> >    - support for user-created/built-in start and end line caps
> 
> There's too much possible variety here, (one soon gets to arrowheads
> with infinite variations), for this to belong inside cairo itself. But
> it shouldn't be too hard to do everything at the layer above cairo.

Yes, there is too much possibility here. I was actually looking for a
way to do create a cap and attach to a line. Also, I was talking about
having different end caps. AFAIK, Cairo uses same line cap when drawing
a line. The missing thing I feel is support for start cap and end cap.
In GDI+ I can set different caps for start and end of a line. e.g. I can
draw a line that has round cap at the starting point and ends with
triangle cap. So, here we have two requirements actually. One to create
custom caps and another to have different end caps for a line.

> One thing that is missing that may be needed is the cairo_stroke_path
> function. This function will compute a path that, if filled, would
> create the same result as a stroke of the current path. This function
> would allow you to then add your custom caps to the path, but still fill
> the entire result in a single operation. That's important to do so that
> you don't get seams when dealing with translucent paths for example.
> 
> The support for cairo_stroke_path is near the top of the TODO list, and
> I actually have most of the work done for it. However, this code does a
> fine job of exposing problems in the current polygon tessellation
> implementation. So we need to fix that before we can commit
> cairo_stroke_path.

This API seems to be helpful, once available. But, I want to bring
another point here. GDI+ takes baseInset value from user and uses that
value as the space between the customized cap and the line. I don't
know, if you are going have something similar.

> >    - setting for dash cap
> 
> What do you mean by this one?

Here, I meant that we can set different cap for dashes, when we draw
dashed lines using GDI+. There is an API that takes three arguments
basically, startCap, endCap and dashCap. StartCap refers to the starting
cap for the line, endCap for end point and dash cap is used for drawing
dashes in a line. Obviously, dashCap is useless, if line does not
contain dashes.

> >    - setting for gamma correction [2]
> 
> Gamma-correct composited is still missing in the backends that cairo
> uses, (eg. Render). And that is an issue that does need to be addressed
> eventually. On the TODO already.

Thanks for this :)

> >    - support for metafile
> 
> I'm not quite sure what you mean by this either. What would you like to
> see cairo provide?

Actually, I was not very sure myself about this. I think we can
implement something like this in a layer above Cairo.

> > [1], to draw something without antialiasing, once you suggested me to
> > do it pixel by pixel manually. Sorry, I could not give it a try yet,
> > but would try it sometime once I'm done with other things.
> 
> Heh, I didn't seriously intend for you to implement that. What I meant
> was that the only way I could think of to achieve the effect of
> pixelized rendering in cairo would be to carefully construct a path that
> outlined each pixel. That would be quite slow to render, and it would
> ugly be design. I can't imagine that would be a useful exercise.
> 
> The question to ask yourself is what you really want. If you are
> implementing a pixel-perfect specification that demands that result,
> then that may be the kind of approach you would have to take.

Basically we have to create some patterns similar to the ones provided
by GDI+. Some of them are supposed to be drawn with no anti-aliasing.
It's not a major requirement for us but would be helpful, if any such
switching exist in Cairo for anti-aliasing.

> But my guess would be that "turn off anti-aliasing" is probably intended
> to mean "I'm willing to sacrifice rendering quality in exchange for
> speed" in which case the approach above would have the opposite effect
> from what was desired. We do already have cairo_set_tolerance which does
> allow a quality/speed tradeoff, (though I haven't tried to see how much
> dynamic range it offers).

Thanks for the detailed response!

Regards
Ravindra