Re: What do we think about vkvg ?

On Mon, Jul 02, 2018 at 01:07:05PM +0000, Bruyère Jean-Philippe wrote:
> 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.

Would be interesting if you can get useful results.  The original code
is posted here, fwiw:

  https://github.com/bryceharrington/caskbench

I can move that to https://gitlab.com/cairo if you plan to do work on
it.

I'll remark that it was notorously difficult to get reasonably
apples-to-apples performance comparisons between cairo-gl and skia since
there's so many idiosyncratic differences in assumptions.  The
testsuite's handy for finding areas where performance work is needed,
though.

For instances, differences in antialiasing quality settings can have
huge performance impact - for certain use cases.  Caching or image
atlases can similarly have huge performance implications, that may
suggest unnaturally large (factor of 10 or more) advantages when used by
one lib but not the other.  Etc.

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

Drawings are always nice.  It might also be helpful to document your
research and decision making processes, both for newbies reviewing your
code, and future maintainers that may wonder why things are as they
are.  :-)

I've been working on learning vulkan myself this year, but work
situation appears to be changing a bit, and I'm unsure whether I'll be
continuing or not; I should know better within a couple weeks either
way.

When I presented caskbench and the cairo-gles performance work, one
concern raised that never really got resolved was a desire for state
retention (e.g. so if you're doing animation or interactive drawing, can
calculations from one frame be saved for reuse in subsequent frames).
This seems important, but I'm unclear on what the architectural
implications are, and whether it could be adequately supported within
Cairo's current architecture or if that'd be more work than worth.
I was interested in digging into the problem a bit more with vulkan; if
you get a chance to experiment along these lines I'd be interested in
hearing your findings.

I did some investigation into fixed point math; Cairo uses this
internally and I wanted to better understand the benefit, and how it
might influence decisions about what to put on the GPU.  However, in
playing around with it I couldn't find an advantage other than just that
perhaps it's required by some of the rasterization algorithms.  I didn't
see a good reason to investigate it further.

On data types, I will mention that there has been some desire to see
expanded range and precision of coordinates, as some users have tended
to push the limits (usually unintentionally...)  Similarly, for color
types there's been strong interest expressed in using deeper color
formats than just straight RGB, mainly in support of doing proper CMYK
with PDF generation.  Both of these would be hard to change in
established code, and maybe easier to implement if starting fresh on a
new graphics lib.  Indeed, if one were to go that direction there's a
number of other things like that which are challenging to fix in Cairo
due to stability concerns.

Bryce


> 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.
> 
> -- 
> cairo mailing list
> [email protected]
> https://lists.cairographics.org/mailman/listinfo/cairo
-- 
cairo mailing list
[email protected]
https://lists.cairographics.org/mailman/listinfo/cairo