Bug 19353 - Caret in AbiWord does not blink with compiz-fusion with intel 82G33/G31
Summary: Caret in AbiWord does not blink with compiz-fusion with intel 82G33/G31
Status: RESOLVED FIXED
Alias: None
Product: xorg
Classification: Unclassified
Component: Driver/intel (show other bugs)
Version: 7.4 (2008.09)
Hardware: Other All
: medium normal
Assignee: Jesse Barnes
QA Contact: Xorg Project Team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-12-31 19:22 UTC by Martin Sevior
Modified: 2009-10-05 11:06 UTC (History)
2 users (show)

See Also:
i915 platform:
i915 features:


Attachments

Description Martin Sevior 2008-12-31 19:22:47 UTC
Description of problem:

In Fedora 10 running with the compiz-fusion-0.7.8-2.fc10.i386 Window manager the caret in AbiWord-2.6.5 appears as a solid rectangular block which not blink. Furthermore, upon typing large amounts of screen dirt from the caret are generated.

This bug was not present in Fedora 9, nor does it appear in compiz-fusion with the nivdia video card. It does not appear in metacity either. From my knowledge of abiword my guess is that compiz-fusion is not handling screen captures or restores with called from a gtk-idle loop.

Version-Release number of selected component (if applicable):

compiz-fusion-0.7.8-2.fc10.i386
intel 82G33/G31
fedora 10.

How reproducible:
100% reproducible in the combination of hardware and software shown above. Bug was not present in fedora 9.

Steps to Reproduce:
1. enable compiz-fusion with intel 82G33/G31 video card in Fedora 10
2. Start abiword
3. 
  
Actual results:

Observed solid rectangle where the blinking caret should be.

Expected results:


A blinking caret should appear at the location where text enters abiword
Additional info:
Comment 1 Martin Sevior 2009-07-29 16:25:11 UTC
Hi folks what is the progress on this bug?
I recently upgraded to fedora 11 and the bug is still present although in a different form. Now the caret doesn't blink and cannot be cleared. 

see the commentary in the abiword bugzilla here:

http://bugzilla.abisource.com/show_bug.cgi?id=12066

This basically makes compiz and compiz-fusion unusable.

We blink the caret by taking a snapshot of the screen pixmap, then draw the caret over that. It appears that taking this snapshot of the screen pixmap returns a solid black rectangle, rather than what was on the screen.
Comment 2 Michel Dänzer 2009-07-30 06:20:18 UTC
(In reply to comment #1)
> We blink the caret by taking a snapshot of the screen pixmap, then draw the
> caret over that. It appears that taking this snapshot of the screen pixmap
> returns a solid black rectangle, rather than what was on the screen.

With compositing, the screen pixmap (or did you mean the root window? Anyway, same issue) is basically owned by the compositing manager, you can't rely on it having any specific contents. I'm not sure why you would need to read from there rather than from the Abiword window anyway.


P.S. Note that compiz bug tracking has moved to its own bugzilla.
Comment 3 Martin Sevior 2009-07-30 06:41:10 UTC
I guess I wasn't clear. Here is the code we use to retrieve the contents of the gdkwindow we draw onto with abiword:
------------------------------------------------------------------
	UT_Rect* oldR = NULL;	
	cairo_save(m_cr);
	cairo_reset_clip(m_cr);
	m_vSaveRect.setNthItem(iIndx, new UT_Rect(r),&oldR);
	if(oldR) {
		delete oldR;
	}

	GdkPixbuf * oldC = NULL;
	UT_sint32 idx = _tduX(r.left);
	UT_sint32 idy = _tduY(r.top);
	UT_sint32 idw = _tduR(r.width);
	UT_sint32 idh = _tduR(r.height);
	cairo_surface_flush ( cairo_get_target(m_cr));

	GdkPixbuf * pix = gdk_pixbuf_get_from_drawable(NULL,
							_getDrawable(),
			        			   NULL,
						   idx, idy, 0, 0,
						   idw, idh);
	m_vSaveRectBuf.setNthItem(iIndx, pix, &oldC);

---------------------------------------------------------------------
Is the result of GdkPixbuf * pix = gdk_pixbuf_get_from_drawable(NULL,
							_getDrawable(),
			        			   NULL,
						   idx, idy, 0, 0,
						   idw, idh);
Now undefined in compiz?

Can you point me directly to where this bug should be reported? There is a maze of different components and products. Finally I'm not convinced this is not a driver bug. AbiWord works perfectly on an Nivida card with compiz.
Comment 4 Michel Dänzer 2009-07-30 06:56:53 UTC
(In reply to comment #3)
> Is the result of GdkPixbuf * pix = gdk_pixbuf_get_from_drawable(NULL,
>                                                         _getDrawable(),
>                                                            NULL,
>                                                    idx, idy, 0, 0,
>                                                    idw, idh);
> Now undefined in compiz?

I don't see a problem with that, assuming it's the right drawable, andgdk_pixbuf_get_from_drawable does what the name implies.


> Finally I'm not convinced this is not a driver bug. AbiWord works perfectly on
> an Nivida card with compiz.

That's quite possible, I'm not seeing it with the free radeon driver either. But then it would need to be reported against the driver (not compiz, which is most likely not to blame), and with all the necessary information (log/config files, ...)
Comment 5 Martin Sevior 2009-07-30 07:19:28 UTC
I've reported this bug to fedora with all the driver logs:

https://bugzilla.redhat.com/show_bug.cgi?id=478564

Do you know the driver bugzilla links? Is it Driver/i128, Driver/i740?

I can copy and paste all the info  into the correct bug entry.
Comment 6 Michel Dänzer 2009-07-30 07:31:58 UTC
I guess it's better after all to reassign this than to create a new report and lose the history...
Comment 7 Jesse Barnes 2009-08-31 11:38:46 UTC
Sounds like we're failing to flush something out in this config; so it definitely could be a driver bug.
Comment 8 Martin Sevior 2009-10-02 07:25:36 UTC
This bug appears fixed in latest compiz+intel drivers on my Fedora 11 system. As of October 2nd, 2009.
Comment 9 Jesse Barnes 2009-10-05 11:06:43 UTC
Thanks for the update.


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.