Re: gallium surface still maintained ?

Hello,

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
architectures only.

Best regards,

Guillermo

2016-08-05 16:49 GMT+02:00 Petr Kobalíček <[email protected]>:

> 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".
>
> Cheers,
> Petr
>
>
>
> On Fri, Aug 5, 2016 at 11:38 AM, Guillermo Rodriguez <
> [email protected]> wrote:
>
>> 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
>>
>
>

-- 
cairo mailing list
[email protected]
https://lists.cairographics.org/mailman/listinfo/cairo