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.
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
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 ;)
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.
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(-)
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.
(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
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...
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.
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
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.