[cairo] cairo-script for unit testing [feedback]

[Ian Britten]

Chris Wilson wrote:

>> One question I couldn't resolve is: What is the intended usage of
>> the cairo-script trace file?
> 
> Within the source tree is a CairoScript interpreter [util/cairo-script]
> and a few example utilities that replay traces to various targets.
   [ snip ]
> Last, but not least, the traces are intended to be readable.

Sounds cool!
If I can make a suggestion, it'd probably be helpful to non-Cairo
developers (Like myself) if that sort of information could start to
be consolidated somewhere on the website...  I hear about "cairo script"
on the mailing list, but am not always sure what it is, what it's
capable of, how one would make use of it, etc...
[And/Or, having an on-line version of the API docs for the developer
version could be beneficial too, assuming the new stuff is documented]

>> As with cairowrap, I don't think that cairo-script will currently
>> be suitable for writing cross-platform unit tests, due to the
>> issues described earlier.
> 
>>From your perspective you do need a logging backend. Ideally you want a
> decorator style surface:
> http://lists.cairographics.org/archives/cairo/2006-September/007911.html

I can't speak for all the pagination/decorator stuff, but certainly
the little draw() example there is basically what I'd be looking for.
More specifically, I think the rough (c++) pseudocode would be
something like:
     void MyTest(void)
     {
           surface = new ImageSurface();
           current_log = ; // in-memory std::stream?  file?
           surface->setLogging(current_log);
           // ... setup
           // ... drawing
           TEST_ASSERT(current_log == master_log);
     }
[ Obviously with my own classes/APIs though ]

Basically, within each test, I'd want to log the setup/configuration
of the surface/context, all my draw calls, and compare the results of
the current run to a known master version.  I'd think the logging
would be per-surface - not just a global off/on (And obviously off by
default).

If there's any chance of this being worked on any time soon, I could
try to better collect my thoughts/requirements/ideas, if that'd be of
any help/interest...

> but the closest we have at the moment is the CairoScript backend,
> i.e. ./configure --enable-script. Hmm, I've not even tried to compile
> this recently - as I recall everything but user-fonts (plus one or two
> other font failures) works. It is cross-platform and since it is a
> backend should be convenient to plug into your test code without
> cross-contamination from GTK+. Take a look and see if that is closer to
> your needs.

Hey, look at that!  "--enable-script" does more than just produce
the cairo-trace utility - There's more *code* here now!  :-o

Seriously though, I never noticed the new cairo-script.h file.  I
gather that it's a Surface, and that it produces a CairoScript
output file, eh?  Assuming that's true, doesn't that still leave
me with the same issues as the output from cairo-script?  (The
pointer addresses, library names, etc in the output...)

Giving this some thought though, I'm wondering if the logging
approach mightn't be better for unit testing.  For example, I've
learnt that Cairo uses very different code paths for image/vector
rendering.  It was quite common in my early work to have code that
drew correctly to one surface type, but failed on the other type.
If I used the CairoScript surface instead of the 'real' surfaces,
mightn't I fool myself into thinking the code is working, when it
may not actually?  If I'm writing a test for a specific reported
bug, wouldn't I want to use the 'real' surface for testing, but
just with logged calls?

Anyways, I'll ponder some of this for a bit.  Besides, I'm still
only using v1.8.x for my (production) work, so I couldn't start
to use this right now anyways.  However, any information that
could be offered about the logging stuff (eg: timeframe/release)
would certainly help me in making a plan!

Many thanks for all the info/suggestions!  Keep up the great work!
Ian