[cairo] clipmask of multiple rects in different angles

[Theo Veenker]

On 21/07/16 18:41, Enrico Weigelt, metux IT consult wrote:
> 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)

I would try if it still tears if foreground painting is as simple as 
filling a square using a simple color pattern instead of a surface pattern.

>
>> 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 ?

Search for vbltest.c

It goes something like this: You request for a vertival blank event for 
the head you window is on. Init drm event context. Then in your event 
loop select on the drm fd. If select() says the drm fd is ready call 
drmHandleEvent(). In your callback do the drawing. If instead you want 
to start drawing before the callback fires you'd have to use a timer and 
stuff.

In the drm API instead of a vblank handler you can install a page flip 
handler. Unfortunately I don't know how to utilize that.

Theo