Bug 15652

Summary: [directfb] Regression in 1.6, making gtk/directfb not repaint changed window areas correctly
Product: cairo Reporter: Sebastian Dröge (slomo) <slomo>
Component: directfb backendAssignee: Carl Worth <cworth>
Status: RESOLVED FIXED QA Contact: cairo-bugs mailing list <cairo-bugs>
Severity: critical    
Priority: medium CC: dave
Version: 1.6.4   
Hardware: Other   
OS: All   
Whiteboard:
i915 platform: i915 features:

Description Sebastian Dröge (slomo) 2008-04-22 07:25:37 UTC
Quoting http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477331:
=============================================================

I just tested the graphical installer with the new libraries and I'm
afraid there's a serious regression. It looks like old screen content is
not getting "wiped" when new elements get displayed.

As cairo is the only library to have changed recently, I'm fairly
certain that the cause is there, possibly related to the breaking out of
libpixman. I've uploaded some screenshots to show the issue.

Initial screen after boot (no problems):
- http://people.debian.org/~fjp/tmp/d-i/cairo-regression1.png

After scrolling up in the list previously selected lines should not be red:
- http://people.debian.org/~fjp/tmp/d-i/cairo-regression2.png

After scrilling down to English again, the red partly disappears, except
for the two thin lines around Dutch and a line in the left margin:
- http://people.debian.org/~fjp/tmp/d-i/cairo-regression3.png

The next screen still shows text from the previous one ("Choose a
language:" and the "dot" under the s in "Based":
- http://people.debian.org/~fjp/tmp/d-i/cairo-regression4.png

This is the clearest example. It should only be showing a progress bar,
but instead still has the full previous dialog and all progress info is
printed on top of itself, resulting in the almost black bar:
- http://people.debian.org/~fjp/tmp/d-i/cairo-regression5.png

Note that the installer used a directfb backend, not X.

=============================================================


The version it worked with was 1.4.14, the version that had this behaviour is 1.6.4. Nothing else was updated so it's most likely a regression in cairo.
Comment 1 Carl Worth 2008-04-22 08:23:44 UTC
Interesting.

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,

-Carl
Comment 2 Sebastian Dröge (slomo) 2008-04-22 09:58:43 UTC
I can only answer 2 currently, it's really 1.6.4 and a typo in the bugreport. Also for 3, it does whatever GTK does ;)
Comment 3 Dave Beckett 2008-04-26 14:31:21 UTC
More news from
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=477331

[[
I figure that, of available packages, the first to show this issue is
1.5.6-1 while 1.4.14-1 was the last one to be working.
]]

I've asked if 1.5.4 shows it.

Comment 4 Sebastian Dröge (slomo) 2008-04-26 14:36:06 UTC
As Otavio Salvador noted on the downstream bug, this regression was introduced somewhere between 1.5.4 and 1.5.6.

There were the following changes that could affect the dfb backend (all other changes were generic or backend specific or directfb changes that were cleanup):

+commit ad0a2524ffdc9cc949d11de3aa51c429f13e12b7
+Author: Claudio Ciccani <klan@directfb.org>
+Date:   Wed Jan 2 15:09:58 2008 +0100
+
+    [cairo-directfb] Optimize blend functions in fill_rectangles(), too.
+
+ src/cairo-directfb-surface.c |   25 ++++++++++++++++++++++++-
+ 1 files changed, 24 insertions(+), 1 deletions(-)

+commit 08516d97a1b34cbb119d6d842ae31e4cb4e08740
+Author: Claudio Ciccani <klan@directfb.org>
+Date:   Mon Dec 10 18:54:01 2007 +0100
+
+    [cairo-directfb] Merging from directfb.org
+    
+    - Improved performance in case of surface conversion: allocate a shadow buffer that can only grow
+    - Fixed support for small surfaces (less than 8x8)
+    - Optimize the blending function according to the surface format
+    - Added _directfb_categorize_operation(): selects the blitting function according to the transform matrix
+    - Avoid inverting the matrix when doing a simple StretchBlit()
+    - Use TextureTriangles() instead of StretchBlit() when scale factors are negative
+    - Added support for ARGB32 fonts (converted to A8 internally)
+    - Removed unused functions (flush() and mark_dirty_rectangle())
+    - Code cosmetics
+
+ src/cairo-directfb-surface.c |  847 +++++++++++++++++++++++-------------------
+ 1 files changed, 466 insertions(+), 381 deletions(-)
Comment 5 Sebastian Dröge (slomo) 2008-04-26 15:39:29 UTC
Quoting Otavio from the downstream bugreport again:

> I did a bisect and it shows f3cec9d1c2a4d43cd734aae4bc7f8e7410a5e89a
> as the bad one. Looking at it I had figure that
> 08516d97a1b34cbb119d6d842ae31e4cb4e08740 might be the responsable
> change (since it was merged) and reverted it. It solves the problem.
Comment 6 Carl Worth 2008-04-26 16:09:06 UTC
(In reply to comment #5)
> Quoting Otavio from the downstream bugreport again:
> 
> > I did a bisect and it shows f3cec9d1c2a4d43cd734aae4bc7f8e7410a5e89a
> > as the bad one. Looking at it I had figure that
> > 08516d97a1b34cbb119d6d842ae31e4cb4e08740 might be the responsable
> > change (since it was merged) and reverted it. It solves the problem.
> 

Ugh. That's a commit that's documented to do 9 separate things. It's
really too bad that that wasn't separated into 9 separate commits.

I certainly wouldn't want to ever accept a commit like that into one
of cairo's "supported" backends, (but I pretty much don't review stuff
that goes on in cairo's "experimental" backends).

Good luck tracking things down further. And please let us know if
there's a change we should make in cairo.

-Carl
Comment 7 Sebastian Dröge (slomo) 2008-04-26 16:18:06 UTC
Yeah, I really wonder why one has to create one commit with that many separate changes :)

Well, I've pointed the committer at this bug, maybe he has an idea...
Comment 8 Chris Wilson 2008-10-21 01:27:44 UTC
I didn't have a trivial method to reproduce this bug, so I tackled the bugs identified by the test suite instead - and found quite a few clipping related issues.

Please can you try git (or 1.8.2 when it is released, hopefully quite soon now) and give the directfb a thorough testing.
Comment 9 Carl Worth 2008-11-13 06:16:26 UTC
We *think* this bug is fixed with Chris's work, (since the directfb backend passes most of the test suite now). And while the directfb is still not a "supported" backend, I'm removing the blocker severity for this bug report.

-Carl
Comment 10 Chris Wilson 2012-02-09 15:17:50 UTC
DirectFB has been gutted back to a simple layer over image.

Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.