[cairo] clipmask of multiple rects in different angles

[Enrico Weigelt, metux IT consult]

On 21.07.2016 09:07, Theo Veenker wrote:

> I suppose such a big lag can only happen if your system is too busy
> (drawing or something else). I use xlib, does that fall back on xcb
> these days?

Made some timings of individual steps: on DRM it's magnitudes slower
(also rendering into groups) than XCB, even those steps just operating
within groups (which, IMHO, should go to a recording surface).

Meanwhile I've split it into two surfaces: the individual widgets
are rendered onto an recording surface (within a group), while final
composition is done on the actual target surface (still within a
group), which made it a bit faster. When trying the final composition
without a group (even when clipped to the actually changed regions),
I get massive tearing (clearing background vs. foreground painting)

> Using groups (as per cairo_{push|pop}_group) creates intermediate
> surfaces. I'd try to avoid that. The only situation I use
> cairo_{push|pop}_group() is when drawing a widget with alpha. (still
> dreaming about global alpha in cairo)

That shouldn't be the big deal, as it's just used for rendering the
widget contents, when the widgets themselves change. I've previously
used that also for compositing everything into the root window, but
I've now changed that part.

The idea behind is painting the widgets themselves into their own
context, just as they had their own surface. This operation is only
done when the widget itself is dirty.

>> By the way: when exactly is the clipping applied (and clipped-out stuff
>> dropped out) ? Is that device specific or generic ?
> 
> That should be in the docs somewhere I guess, I'm no cairo expert. I
> belive clipping is the last stage.

hmm, I suspect that it's done when putting the pixels onto the actual
surface - at least on the image surface (which is used by drm).
can I somehow 'compress' it, so invisible objects are kicked out of
the pattern (or not put into it in the first place) ?

>> Theoretically, the clip should limit the actual draw operations on the
>> underlying framebuffer to the dirty regions.
> 
> Maybe you could count per widget howmany times per second is gets
> redrawn. Ideally it should not be more than once per video frame.

The widgets are only drawn when they actually change. I have to widgets
which show the mouse position (one for the absolute, one for the
relative within current widget) - that shouldn't be so much ...

> From the top of my head (haven't worked on it for some time): I have a
> thread monitoring DRM vblank. 

How exactly are you doing that ? read from the drm fd for the proper
event ? Do i have to activate that before it is sent ? Can multiple
such event sit in the queue or only once ?


--mtx