Don't you have to do some sort of sync() call to get the surface to 
actually match? I suspect Cairo is not updating the clip until it needs 
to draw something, which is why removing the show_layout() seems to work 
(because it never applied the clip).

bugzilla-daemon@freedesktop.org wrote:
> https://bugs.freedesktop.org/show_bug.cgi?id=29501
> 
>            Summary: cairo_restore does not undo a clip done on a DirectFB
>                     surface
>            Product: cairo
>            Version: 1.8.4
>           Platform: Other
>         OS/Version: Linux (All)
>             Status: NEW
>           Severity: normal
>           Priority: medium
>          Component: directfb backend
>         AssignedTo: cairo-bugs@cairographics.org
>         ReportedBy: allison.newman@sfr.com
>          QAContact: cairo-bugs@cairographics.org
> 
> 
> Take the following code:
> 
> 
>     cairo_save(pCairo);
>     cairo_rectangle(pCairo, x, y, w, h);
>     cairo_clip(pCairo);
>     cairo_translate(pCairo, x, y);
>     pango_cairo_show_layout(pCairo, pLayout);
>     cairo_restore(pCairo);
> 
> 
> After the cairo_restore(), if I try to do a DirectFB drawing operation on the
> surface outside the region specified for the cairo clip, there is no drawing
> done.
> 
> I'm not sure exactly where the bug is though, it may be in pango.  If I remove
> either the cairo_clip() or the pango_cairo_show_layout(), I can still draw
> correctly on the surface, but if I have both, the clip remains in effect.
> 
> Adding:
>     pFBSurface->SetClip(pFBSurface, NULL);
> 
> after the cairo_restore() allows me to draw correctly to the surface again.
>

You're possibly right, but I would still consider that behaviour as a bug, particularly when it isn't documented anywhere. For example, I don't see any call for synchronising in the API (apart from actually doing a drawing operation).  All I can say is that I find it highly surprising to have the state of my DirectFB surface changed by cairo, and to not have that state restored when I call cairo_restore().  As there isn't a formal spec, and the documentation (both the API reference manual and the comments in the source code) have nothing to say on the subject, I felt that this was more of a bug than anything else.

This is a bug in Cairo's DirectFB implementation.

However, it has nothing to do with cairo_restore() but with the way surfaces are handled in Cairo. Cairo surfaces assume full ownership of the given resources when they are created. So they are free to set any clip they like on the DirectFBSurface.

But there is a function that the user can use to make Cairo release its contol of the resource and restore its settings to the original state: cairo_surface_flush(). And that function is not implemented by the DirectFB backend.

Ahhhh.  Thank you Benjamin, yes, that was effectively a bug in my code, although as you have noted, the problem is still present, even with the flush.

I'll have a shot at providing a first attempt at correcting the bug now that I know this is truly a problem, rather than just a bug in my own code!

(In reply to comment #3)
> This is a bug in Cairo's DirectFB implementation.
> 
> However, it has nothing to do with cairo_restore() but with the way surfaces
> are handled in Cairo. Cairo surfaces assume full ownership of the given
> resources when they are created. So they are free to set any clip they like on
> the DirectFBSurface.
> 
> But there is a function that the user can use to make Cairo release its contol
> of the resource and restore its settings to the original state:
> cairo_surface_flush(). And that function is not implemented by the DirectFB
> backend.

"Fixed" only due to gutting the directfb code not to try and be clever at all.