Re: padding cleanup

[Havoc Pennington <hp pobox com>]

Hi,

On Sun, Sep 12, 2010 at 6:44 AM, Benjamin Otte <otte gnome org> wrote:
> Uh, you've found out about one of my secret projects. Actually, what
> I'm aiming at is reftests (see
> http://weblogs.mozillazine.org/roc/archives/2008/12/reftests.html for
> a description). They are independant of font settings, themes etc if
> done right.

Sounds cool!

> A big problem with comparing a rendering to a default image - unless

Yeah, agreed that an automated test where canonical images were
checked into git would probably keep breaking in annoying ways. I do
think it'd be easier than Cairo - or at least, certain tests would be
pretty robust. For example, if you packed various colored rectangles
into GtkHBox with different packing parameters, I don't think that
would have changed its pixels in years - it's not quite like Cairo
where you're doing the complex antialiasing and so forth, and the
exact pixels rendered aren't necessarily defined. If I have an event
box with background color 0xff0000 and I set its size request and pack
it into a GtkBox, then that just can't change unless a GTK API has
changed. Possibly some font - or fake font that's just full of boxes -
could be shipped with GTK to keep text rendering stuff from
interfering.

However the automated tests are done, just having a "toolset" for
rendering out a bunch of useful widget images as PNGs will be awfully
handy. Some use-cases:

* smoke-test a patch. if I mess with GDK or cairo or size requesting,
if I could build and render a set of "before" images on my machine
locally, and also a set of "after" images, and quickly do an automated
diff - there's no "pixman changed" or "font changed" issues since it's
all on my machine, no canonical images located in git - I could see if
I triggered any g_warning() or changed how anything paints, without
having to manually walk through gtk-demo/testgtk and look for broken
stuff, which is what I've been doing

* quick-check a theme. sort of like metacity-theme-viewer which shows
windows in a bunch of states

* write git-bisect scripts. for example it probably would have been
worthwhile to automate bisecting that bug we just bisected, by writing
a little "git bisect run" program to render the good and bad
insensitive label.

Anyway however it works, clearly your draw() work is going to enable
it, and this has got to be a giant win from that work.

Havoc