[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: 2.13.40 regtests

From: Graham Percival
Subject: Re: 2.13.40 regtests
Date: Fri, 26 Nov 2010 00:00:50 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

On Thu, Nov 25, 2010 at 05:45:36PM -0000, Phil Holmes wrote:
> It wouldn't take me long to write a C# program (less than a day, I'd
> guess) that reproduced quite a lot of the regtest checker
> functionality and did a pixel-by-pixel check for image changes.

Hmm.  It shouldn't take a huge amount of time to compare each pair
of regtest images -- they're named, so you'd be comparing
something like 500 pairs of .png images.  (Neil: were you thinking
of something else?)

The bigger concern is about false positives.  If your program
notified you about any pair of images with any pixel differences,
you'd be swamped with meaningless changes.  Our regtest checker
does some kind of thresholding which doesn't display significantly
changed images, but I'm not certain how that works.

I don't think you can just look at the number of changed pixels.
A tiny change to spacing could give you a huge number of changed
pixels [which wasn't important], while a missing augmentation dot
[a serious problem] would only give you a tiny number of changed

Then again, we're not talking about relying on this new checker
exclusively, and the current system isn't perfect either.  I don't
think that using both systems would add a huge amount of extra
time to the Bug Squad duties.

> I've done the latter bit in about 20 minutes on the figured bass png
> that started this discussion.  The difference file it produces is
> attached.  I'd be quite happy to do this, but wouldn't do it if it
> was felt to be stepping on other toes.  I don't know python well
> enough to try looking at the existing file.  I realise this couldn't
> be run as part of the build process, since it's windows only, but
> I'd be happy to run it locally and when I shuffle off the coil
> others _could_ do the same.

You wouldn't be stepping on toes, but writing it in C# introduces
a few inefficiencies, which you noted:
- can't be added to the build process.  (no, I cannot forsee ever
  adding mono to gub)
- most developers can't use it [without installing mono].

I have two alternate suggestions:
1) write it in C#, then add a Frog tracker issue to port it to
python.  If there's an existing, working, program, then writing a
python version would be easier.
2) treat this as a long-term project, and slowly write a python
version yourself.  We use python a lot in lilypond, and it's quite
a nice and easy-to-learn language, so learning python could have
other benefits down the road.  (potentially in your daily job, in
addition to lilypond stuff)

I'm *not* suggesting that you try to modify the existing python
script or the build process -- writing a separate python script to
do your comparison would be much easier.  Once such a script
exists, it could be merged into the build process relatively

- Graham

reply via email to

[Prev in Thread] Current Thread [Next in Thread]