-
Notifications
You must be signed in to change notification settings - Fork 55
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
long paths are very slow #89
Comments
Nice work! Yes, on machines suffering from the outrageously-slow Cairo (which not all systems do), this seems to do wonders. On my laptop where I built Cairo myself (not following the script in Prior to patch: 137 seconds to render a path with 10^5 randomly-generated points However, a sobering comparison: chrome rendering an equivalent HTML5 script: 0.013 seconds, approximately 20-fold faster. Still, I'll take a 500-fold performance improvement any day. At least with this change, we're not embarrassing anymore. (It's still irritating that on my slow laptop, it's more like 2.8 seconds, which I think is slower than we eventually want to be. Chrome on the same machine is 0.3 seconds, so in both cases we're still seeing something like a ten-fold gap.) This is really, really nice! Please, do commit it to Winston, tag/publish, and send a triumphant email to the list! |
Oh, and Qt is even slightly faster than chrome, at least on my laptop (didn't test the Windows machine). |
Do you understand at all what is behind cairo being slow sometimes? |
I don't know much, but what I do I'd break into parts:
|
Do you have any insight into why cairo is O(n^2) in path length in some configurations but not others? Or did recompiling cairo only give a constant factor speedup? |
No, it ended the It was a while ago when I built it (here were the build steps), but I'm pretty sure it was the same base version of the cairo library, and it must have just gotten configured differently than when one builds with |
It occurred to me that at least I could paste the cairo/config.h file here for posterity:
|
How about asking on the Cairo mailing list? People there must know about the effect of compile options on performance. |
Hi, Cheers |
@stuaxo Hi, i saw your post on the Cairo mailing list. What problem are you trying to solve? |
Hi, I'm a developer on Shoebot, which presents users with a vector drawing API backed by Cairo.
Users can draw anything they like, from simple to complex shapes.
If the default install of Cairo is slow at drawing long paths vs drawing the same path made of lots of single segment paths, then I'd like to collect info and submit a bug.
TLDR: I'm interested in Cairo getting faster and this bug looks like it may point to an optimization for Cairo itself.
S++
On Wednesday, May 26, 2021, 4:34:54 PM GMT+1, Andreas Lobinger ***@***.***> wrote:
@stuaxo Hi, i saw your post on the Cairo mailing list. What problem are you trying to solve?
—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
Cheers - I've replied on the mailinglist, since it's a bit off topic there. The answer was I'm not trying to do anything in particular but I'd like a quicker Cairo in general. |
Thanks, I'm aware of pathfinder - but I don't think someone has made python bindings for it and wrapped it in a WHL yet. It would also mean rewriting our 10 year old Cairo/Pango based codebase, but that's not as important as the first point. Shoebot the project has taught me that if a user has to install any dependency using something other than the languages package manager, they appear on our bug tracker, and it's often difficult get them up and running. This was the case with Pycairo, which has a python package, if not a always a WHL (for non WHL versions need the user to have a compiler setup, which they often do not on non-linux platforms). When we do eventually rewrite, I'm will only choose dependencies that have WHLs on all 3 major platforms: if users can't a library, then it may as well not exist. |
If I'm understanding this right it's really a performance bug in Cairo, but drawing very long paths is O(n^2). This was discussed on the mailing list a while back. Just messing around, I tried the following Winston patch:
This makes plotting long paths insanely faster for me. @timholy I recall there was some other workaround for this, but perhaps we should do something like this inside Winston to make sure people don't hit the slow case?
The text was updated successfully, but these errors were encountered: