<div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote">2016-08-05 11:00 GMT+02:00 Enrico Weigelt, metux IT consult <span dir="ltr"><<a href="mailto:enrico.weigelt@gr13.net" target="_blank">enrico.weigelt@gr13.net</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On 05.08.2016 10:35, Enrico Weigelt, metux IT consult wrote:<br>
<br>
<snip><br></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
Oh, could you check whether your driver sets DRM_CAP_DUMB_PREFER_SHADOW.<br>
<br>
<a href="https://lists.freedesktop.org/archives/dri-devel/2016-August/114970.html" rel="noreferrer" target="_blank">https://lists.freedesktop.org/<wbr>archives/dri-devel/2016-<wbr>August/114970.html</a><br>
<br>
On my box (w/ an i915) the driver sets this flag, so I'll have to assume<br>
that writing individual bytes going to be slow, and a shadow buffer<br>
should be used, which then is copied over in bursts.<br></blockquote><div><br></div><div>The driver I am using does not set that flag.</div><div><br></div><div>Anyway my application does all compositing on a back (shadow) buffer, and then blits dirty regions to the DRM buffer.</div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Now the interesting question: how to archieve that ?<br>
Is there some easy way to trace which pixels/regions in a image surface<br>
have been touched ?<br></blockquote><div><br></div><div>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.</div><div><br></div><div>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.</div><div> </div><div>Guillermo</div></div><br></div></div>