[cairo-bugs] [Bug 15652] [directfb] Regression in 1.6, making gtk/ directfb not repaint changed window areas correctly

bugzilla-daemon at freedesktop.org bugzilla-daemon at freedesktop.org
Tue Apr 22 08:23:46 PDT 2008


--- Comment #1 from Carl Worth <cworth at cworth.org>  2008-04-22 08:23:44 PST ---

Someone's definiteley going to have to do some investigative work to
find out exactly what's going on. Some notes:

1. The directfb backend is still "experimental", not "supported" in
   upstream cairo. Basically that means nobody has ever plugged
   cairo-directfb into cairo's test suite rigging. Since Debian seems
   intent on relying on this, it would be great to see someone remedy
   that, (and it might exercise the bug).

2. The original bug in the Debian BTS says "cairo/1.4.14-1" not
   1.6.4. You're sure that 1.4.14 worked and 1.6.4 has the bug?

3. What operations is the Debian installer performing to erase one
   dialog before moving to the next? That seems like the simplest
   thing to look for to see what operation is problematic.

4. After answering (3) the next step would be to write a small test
   case performing just that operation which we could then more easily
   debug. (And again, just hooking up directfb to cairo/test as in (1)
   might provide plenty of test cases already.)

5. An alternate debugging strategy could be to take the misbehaving
   program and find the commit between 1.4.14 and 1.6.4 that
   introduced the bad behavior. The "git bisect" utility can be
   extremely useful for this, and I'd be glad to walk anyone through
   the steps required to use that.

Thanks for the report,


Configure bugmail: http://bugs.freedesktop.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

More information about the cairo-bugs mailing list