[cairo-bugs] [Bug 12996] Xlib source surface fast-paths do not use IncludeInferiors, while slow paths do

[bugzilla-daemon at freedesktop.org]

http://bugs.freedesktop.org/show_bug.cgi?id=12996


njs at pobox.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Using Cairo to blit nested  |Xlib source surface fast-
                   |Composite'd windows fails   |paths do not use
                   |for alpha=1                 |IncludeInferiors, while slow
                   |                            |paths do




------- Comment #2 from njs at pobox.com  2007-11-12 22:13 PST -------
Updating title to make bug clearer.  If one looks at the cairo source, one will
notice that there are two render contexts, one used for sources and one for
destinations.  The source context has IncludeInferiors set, the destination
context does not.  So everything works as expected when using Render.

However, some cases get optimized down to XCopyArea, and there is only one GC
that is used for both source and destination surfaces, and this GC does not
have IncludeInferiors set.  Therefore, whether IncludeInferiors is used depends
entirely on how much optimization cairo thinks it can get away with. 
Obviously, this is broken.

One fix would be to disable the XCopyArea fallback.  I don't know what the
speed  implications of this would be.  I'd *hope* the server performed
identity-transform blits equally fast no matter whether they were requested via
Render or XCopyArea, and Render certainly does *have* code to notice this case
and optimize it, but I don't actually *know* that it is equally fast.  

The other obvious fix would be to split up cairo's GCs just like the Render
contexts are split up.  I had a try at this, and it got ugly; there is lots of
code that touches the gc and is shared between the paths for source and dest
surfaces, so you end up starting to make two copies of lots of other functions,
bleh.  Maybe there is a simpler way for someone with more local knowledge of
the codebase, who would have some confidence to refactor instead of just
blindly copying.

The former approach would certainly be simpler, and involve removing code
rather than adding it; inasmuch as Correctness > Speed, maybe it should simply
be adopted.

Also to note, a workaround is to use push_group/pop_group_to_surface;
compositing to the temporary surface works (who knows why), and it's handy for
double-buffering anyway.


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