Re: gallium surface still maintained ?

Guillermo Rodriguez <[email protected]>
Newsgroups gmane.comp.lib.cairo
Message-ID <CABDcavZAKHo58hWXYsvCBpTCipXpNZBZ+KsTe1a+7WFPH=TYJw@mail.gmail.com>
Hi,

2016-08-05 11:00 GMT+02:00 Enrico Weigelt, metux IT consult <
[email protected]>:

> On 05.08.2016 10:35, Enrico Weigelt, metux IT consult wrote:
>
> <snip>
>

> Oh, could you check whether your driver sets DRM_CAP_DUMB_PREFER_SHADOW.
>
> https://lists.freedesktop.org/archives/dri-devel/2016-August/114970.html
>
> On my box (w/ an i915) the driver sets this flag, so I'll have to assume
> that writing individual bytes going to be slow, and a shadow buffer
> should be used, which then is copied over in bursts.
>

The driver I am using does not set that flag.

Anyway my application does all compositing on a back (shadow) buffer, and
then blits dirty regions to the DRM buffer.


>
> Now the interesting question: how to archieve that ?
> Is there some easy way to trace which pixels/regions in a image surface
> have been touched ?
>

I keep track of dirty regions which are merged together using a naive
algorithm: The resulting dirty region is just a rectangle that encloses all
dirty rectangles. That is then blitted to the screen in each update cycle.

This merging algorithm is obviously inefficient in some cases. For example
let's say you have two small dirty regions in opposite corners of the
screen; the merged dirty region will be large, and blitting that will be
less efficient than blitting the two original dirty regions. You could
optimize this by applying some heuristics in order to decide when to merge
and when not to merge, but I haven't found the need to do that yet.

Guillermo

-- 
cairo mailing list
[email protected]
https://lists.cairographics.org/mailman/listinfo/cairo
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.