[cairo] XCopyArea and Cairo - trying to implement scrolling

[Chris Wilson]

On Fri, May 15, 2015 at 07:39:56PM -0700, Richard Billington wrote:
>    So I've had an interesting time. I've parsed your message as essentially
>    saying either
> 
>      * re-implement xcopyarea using cairo constructs
>      * OR, continue to use xcopyarea and handle the resulting graphics-expose
>        event with a cairo-based function
> 
>    I've tried re-implementing xcopyarea, and it resulted in a bad-match X
>    error based on something that gets put on the event queue - hard to tell
>    what because as soon as the error occurs it locks keboard input to X up
>    :-(

Stop calling XGrabServer() whilst debugging :)
 
>    I've also noticed that the when scrolling I get "no-exposure" events, so
>    that means even if I implemented a cairo-based handler for graphics-expose
>    event, it wouldn't be called when scrolling.

That's just how you structure your draw loop. Basically you just want to
listen to X for when you need to redraw parts of the screen, and you own
internal dirty handler to accumulate drawing. So when you scroll, you
can copy part of the existing window/pixmap, and draw the freshly
exposed surface.

Actually, if you used the double buffering mechanism I mentioned earlier
you can copy from the Window into the backbuffer, draw the new area,
then flush out the backbuffer to the Window without hitting the
self-copy issue and not having any tearing artefacts.
 
>    So I explored the "function"s being used. That is, before calling
>    xcopyarea, the function "property" of the xlib graphics context is set to
>    a value from 0 to 15. The function I'd used successfully with the purely
>    xlib implementation was "GXandReverse" (defined as logically "src AND NOT
>    dst"). With a window rendered using Cairo, this resulted in odd scrolling,
>    the worst of which was that the background went from white to black, but
>    it had additional problems. I surmise this is because the colors have an
>    alpha channel and so the logical combination has a different result, but I
>    really haven't thought it through. Instead, I experimented and found that
>    using "GXxor" (defined logically as "src XOR dst") worked much better,
>    thought it seems to smear text one pixel to the right, though graphics
>    scroll fine.

It's your GC. You just want to use GXCopy for scrolling (the function is
just a bitwise operator between src and dst).
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre