<div dir="ltr">Hello,<div><br></div><div>I definitely share your view.<br><div><br>Blend2D looks very interesting. I hope there will be an ARM port in the future; for what I have seen the JIT engine is currently targetting x86 architectures only.</div><div><br>Best regards,</div><div><br></div><div>Guillermo</div><div class="gmail_extra"><br><div class="gmail_quote">2016-08-05 16:49 GMT+02:00 Petr Kobalíček <span dir="ltr"><<a href="mailto:kobalicek.petr@gmail.com" target="_blank">kobalicek.petr@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">I'm reading the discussion and I would like to contribute.<div><br></div><div>I'm author of Blend2D (<a href="http://blend2d.com" target="_blank">http://blend2d.com</a>) and I'm just finalizing an evaluation version. And I think, from my own experience, that CPU rendering is feasible and can be really fast. The problem is that libraries are not optimized to use CPU well.</div><div><br></div><div>If you check out the pipelines of open-source 2D libraries then you will see basically the same thing - it many cases pixels are just copied from one place to another many times before they are written to the destination buffer. Another thing is the dispatching mechanism - in many cases these libraries call tens of functions (sometimes even allocate dynamic memory) before pixels start changing - and this happens every time you call some drawing function that is not "fillRect".</div><div><br></div><div>I think that the most critical is UI and vector-art rendering, because these generally perform many drawing calls that render tiny things.</div><div><br></div><div>I have my own benchmarking suite that compares performance of Blend2D, Cairo, and Qt. I can announce on this list when I release the beta version so Cairo devs and users can see the real difference between "optimized for CPU" and "supports CPU".</div><div><br></div><div>Cheers,</div><div>Petr</div><div><br></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote"><div><div class="h5">On Fri, Aug 5, 2016 at 11:38 AM, Guillermo Rodriguez <span dir="ltr"><<a href="mailto:guillerodriguez.dev@gmail.com" target="_blank">guillerodriguez.dev@gmail.com</a><wbr>></span> wrote:<br></div></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div class="h5"><div dir="ltr">Hi,<div class="gmail_extra"><br><div class="gmail_quote"><span>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-August<wbr>/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></span><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><span><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></span><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><span><font color="#888888"><div> </div><div>Guillermo</div></font></span></div><br></div></div>
<br></div></div><span class="">--<br>
cairo mailing list<br>
<a href="mailto:cairo@cairographics.org" target="_blank">cairo@cairographics.org</a><br>
<a href="https://lists.cairographics.org/mailman/listinfo/cairo" rel="noreferrer" target="_blank">https://lists.cairographics.or<wbr>g/mailman/listinfo/cairo</a><br></span></blockquote></div><br></div>
</blockquote></div><br></div></div></div>