[cairo] gallium surface still maintained ?
guillerodriguez.dev at gmail.com
Fri Aug 5 16:51:54 UTC 2016
I definitely share your view.
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
2016-08-05 16:49 GMT+02:00 Petr Kobalíček <kobalicek.petr at gmail.com>:
> I'm reading the discussion and I would like to contribute.
> I'm author of Blend2D (http://blend2d.com) 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.
> 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".
> I think that the most critical is UI and vector-art rendering, because
> these generally perform many drawing calls that render tiny things.
> 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".
> On Fri, Aug 5, 2016 at 11:38 AM, Guillermo Rodriguez <
> guillerodriguez.dev at gmail.com> wrote:
>> 2016-08-05 11:00 GMT+02:00 Enrico Weigelt, metux IT consult <
>> enrico.weigelt at gr13.net>:
>>> On 05.08.2016 10:35, Enrico Weigelt, metux IT consult wrote:
>>> Oh, could you check whether your driver sets DRM_CAP_DUMB_PREFER_SHADOW.
>>> 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.
>> cairo mailing list
>> cairo at cairographics.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the cairo