Post by Bruyère Jean-PhilippeI'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.
Post by Bruyère Jean-PhilippeI'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
Post by Bruyère Jean-PhilippePost by Stefan SalewskiPost by Bruyère Jean-PhilippeIntel 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
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
https://lists.cairographics.org/mailman/listinfo/cairo
--
cairo mailing list
***@cairographics.org
https://lists.cairographics.org/