[cairo] What do we think about vkvg ?

[Bruyère Jean-Philippe]

I've started this morning some structured performance tests on the model 
of the "The Cairo and Skia 
Benchmark"(https://github.com/ezhangle/caskbench), to get a clear idea. 
I'll keep you informed on the advancement.

I've shared my time past month with the development of some games with 
vulkan to improve my vkKnowledge, vkChess has some vkvg rendering, 
that's a first stress test for my lib.

I've developed a GUI toolkit for c# (to get an open sourced xaml 
equivalent ) with cairo, and with caching and clipping, it's quiet fast. 
(https://github.com/jpbruyere/Crow).

My idea when starting vkvg was to give a kick-start for a vulkan backend 
in cairo, with the liberties of a new lib from scratch to be able to 
explore other api/rendering architectures and also mostly to keep focus 
on the vulkan part which is quiet demanding in terms of brain cycles.

There's some hard parts in 2d vector math optimisation, If I want to 
investigate by myself on that material, it will takes some time. For 
now, I use antigrain curve algorithm, and stroke computations is a 
draft, not really optimized.

In the vulkan part, my solution for Descriptors handling is one 
bottleneck, also "send command and wait" order is not optimal, It would 
be better to wait only before sending new commands (in the context 
only), but with that order, some other perf degradations may be 
introduced. I have to make clear drawings of the possibilities.

On 02/07/18 13:01, Stefan Salewski wrote:
> On Sun, 2018-07-01 at 17:16 +0000, Bruyère Jean-Philippe wrote:
>> Intel is quiet a big company, alone I would hardly suffer
>> comparison.
>> Any help is welcome.
>>
> Have you done some basic performance tests yet?
>
> For fastuidraw it was reported that it can be 9 times faster than
> cairo, but I am not sure if that is the average case.
>
> I would be very interested in faster simple (lines) drawing for
> gtk/gnome widgets, i.e. like GTK DrawingArea.
>
> Currently CPU load is high and speed not that great, as proved by
>
> https://lists.cairographics.org/archives/cairo/2016-October/027791.html
>
> So creating CAD applications with cairo is demanding, I tried one
> myself some years ago:
>
> http://ssalewski.de/PetEd.html.en
>
> For that application Ruby language was the bottle neck, now I am
> considering porting it to a very fast compiled language like Nim, so
> cairo will become the bottle neck. I think it will be fast enough, but
> one has to restrict drawing operations to what is really necessary
> using RTrees and bounding boxes. Doing always a complete redraw would
> be much easier of course, I think CAD tools using GL directly are doing
>   complete redraws.