[cairo] [cairo-commit] WATCH_PATH

[Chris Wilson]

On Wed, 2009-07-22 at 12:51 -0700, Carl Worth wrote:
> On Sun, 2009-07-05 at 07:05 -0700, Chris Wilson wrote:
> > Date:   Sun Jul 5 09:21:47 2009 +0100
> > 
> >     [path] Add path watch debugging
> >     
> >     Simple debug macro to print the path to stderr during
> > construction.
> 
> This patch seems a bit dubious to me.
> 
> I mean, I've often been debugging fiddly issues in cairo's geometry and
> needed extra output like this, (or maybe at the trapezoid level instead
> of the path), but I don't think we've generally littered the code base
> with dead code like this.
> 
> My feeling is that this kind of code would be likely to rot, and need to
> be fixed up the next time someone wanted to use it anyway, so we get
> penalized by the clutter and maintenance, but don't get much benefit.
> 
> Does anyone else see that differently?

In this instance, this is overkill. The information I need is why a
particular code path was executed. Often the questions are predictable
such as "why did this backend decide fallback?", so adding trace
information to UNSUPPORTED seems sensible. The other questions are
usually only asked during active development, and never again after that
debugging session (like the WATCH_PATH example).

The other category of information that I want are more in the realm of
performance statistics, but I don't yet have a clear idea of what I
need. So it's difficult to answer a question that has remains ill-posed.

> On the other hand, more general frameworks like the cairo-script
> backend, (that can also be very useful for debugging), seem like a very
> different beast to me. They seem to come out as net useful because they
> are so general, and also because they isolate themselves to their own
> files, etc.

And the script backend just became more useful for debugging as it can
now wrap a target surface to act as a logging surface.

> PS. Cue ickle wishing for userland tracepoints here...

Still wishing.
-ickle