[cairo] What do we think about vkvg ?
jp_bruyere at hotmail.com
Mon Jul 2 13:07:05 UTC 2018
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.
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
>> 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
> So creating CAD applications with cairo is demanding, I tried one
> myself some years ago:
> 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.
More information about the cairo