Unreasonably slow

[tyoma]

I'm developing another graphics library: Anti-Grain Evolution (https://github.com/tyoma/agge). It is based on Maxim Shemanarev's AGG, but is 3 times faster (and leaner in terms of functionality).
So today I performed a simple test and it turns out path drawing in io2d is 6 times slower than I have in AGGE. Should I switch to antialias(io2d::fast) it becomes 3 times slower. But agge always draws in maximum possible quality (it does analytic antialiasing).

This is how I draw path (I eliminated all the obvious memory allocations I could find in the measured interval, _surface and _spiral are created on resize, but never in drawing cycle):

     timings.clearing += stopwatch(counter);

     _surface->line_width(3);
     _surface->line_cap(io2d::line_cap::butt);
     _surface->line_join(io2d::line_join::miter);
     _surface->stroke(io2d::rgba_color(0.0, 154.0 / 255, 1.0));
     _surface->path(*_spiral);

     timings.rasterization += stopwatch(counter);

Can you tell if I'm doing something wrong or is it just Cairo that is so slow?
Being stateful (which is so not C++ish) io2d could make some use of caching, I think...

Below you can see the results are quite similar (all the pixels drawn are within the tolerance of 4 levels), but the timings are hugely different.

[mikebmcl]

The short answer: You aren't doing anything noticeably wrong. Cairo uses GDI on Windows and some aspects of the API design are difficult to implement in an efficient manner using cairo as the graphics backend since cairo turns all paths into line segments, cubic Bezier curves, and two non-path instructions that control rendering aspects. As such, it has no hardware acceleration and doesn't even take full advantage of GDI's path capabilities (see, e.g. https://msdn.microsoft.com/en-us/library/dd183363(v=vs.85).aspx ).

Longer answer:

I don't think you're doing anything wrong. This project is a reference implementation. The focus here is much more on correctness than on efficiency. Using cairo directly would probably provide a number of options for improving efficiency. That said, on Windows cairo uses GDI, which certainly hampers performance due to GDI's lack of hardware acceleration, need to maintain backwards compatibility, etc.

The API that this is a reference implementation of is not tied to cairo, GDI, or any other specific graphics library/subsystem. Indeed, the hope is that on Windows, implementers of the API would use Direct2D, DirectX, or some combination of the two. On other platforms it would likely be implemented using OpenGL or some other high-performance native API.

The API itself is intended to go into a TS (an official publication but not part of the C++ standard itself) in order to gain feedback from both implementers and users on issues such as changes that could be made to increase performance, feature requests, usability, etc. There will likely be a "v2" TS that will make changes based on the feedback and on other concerns.

In the end there are two goals: performance and usability. Usability is (and will be) intentionally given priority over performance, but performance does still matter and if making some small features a bit more complicated can net major performance benefits, performance would almost certainly win in that case.

It's also reasonably probable that v2 will move more towards a stateless design, though that is a difficult issue when designing an API that is intended to exist and be useful for decades. If this effort was attempted 20 years ago with a focus on performance over usability, the result could easily have looked like a mix drawing inspiration from Glide, DirectDraw, QuickDraw, and maybe some very early OpenGL 1.X things that weren't found/didn't have an equivalent in Glide. That's just a guess. But I expect you can imagine what something drawn from all of that would look like now.

So while it would be great to provide interfaces allowing, e.g., custom shaders, it's more important in this case to create an API that provides features and operations which have been known and stable for many years (and thus are unlikely to fundamentally change from an API perspective even though the implementations of the API will undoubtedly change with some frequency as graphics technology continues to evolve).

It's also very important, and quite a bit more difficult, to try to make sure that the addition of new features in the future doesn't require API breakage. For v1 the goal has been to create an API that:

• is relatively easy to teach and use;
• can be implemented on all major platforms that support C++;
• provides all of the "fundamental" operations of 2D graphics; and
• does not knowingly preclude the addition of features that aren't ready for standardization but may become so in future years.

I know it doesn't meet all of those goals in all respects. That is one of the many reasons it is targeted towards a TS rather than the C++ standard itself.

For the expected v2, an additional goal of "provides acceptable performance for lightweight graphical application usage" will hopefully join that list, though what exactly that means is something that can only really be defined if v1 is adopted and published as an official TS such that implementer and user feedback starts coming in. The v1 design is not frozen, btw, but major overhauls, such as making a significant shift towards a stateless design, are impractical at this point and would benefit a lot from implementer feedback in terms of determining what aspects of the current design (if any) are a major bottleneck that could be alleviated with acceptable design changes (i.e. changes that are non-platform specific, wouldn't begin to turn it into an "experts-only" API, and wouldn't expose features that are still actively evolving).

[tyoma]

Thank you for such an elaborate response! Okay, I got it about performance, maybe the question should be directed to cairo support team.
On the other hand, the question asked by @seanmiddleditch still stands. The interface proposed resembles one of the cairo at a very high degree (after a quick glance over their C API), so the statement "The API that this is a reference implementation of is not tied to cairo..." doesn't seem correct. This is not an issue from me, but rather a thought to be considered.

[mikebmcl]

I'm glad you posted this since it's caused me to rethink certain things and to re-read issue #31.

Without getting into a deep discussion of it, at the time these sorts of suggestions first popped up, the API was still evolving very rapidly and Skia, Moz2D, Vulkan, etc., were, at a cursory glance, pretty new technologies. So at the time I dismissed them as being both too new and just a different way of doing the same thing a stateful API did (it didn't help that the main use cases for both Skia and Moz2D were specifically for rendering highly complicated web pages).

Since then I've dismissed the stateful vs. stateless issue as something I already considered and decided, even though I didn't really give it a fair evaluation initially. Stateless seemed like it was mostly for edge cases (high perf rendering of complex scene graphs) and this API was still changing so much that I could barely keep the whole of its evolving design in my head, let alone consider something I thought would be a major rework.

The reality is that you, Sean, and others were correct. I just couldn't see it until now when most of the API has solidified. But the surface class has always been a behemoth, which I've never really liked. The current design for paths, brushes. etc., lets me move state from the surface to those objects, thus making surface more stateless. How much so, I can't quite say yet since I'm rolling back an alternate (and, like the old surface class, not particularly satisfactory) design that I have been working on since the last major design review.

To sum up, thank you to all who suggested a (more) stateless design. It only occurred to me what that might mean for this API as I was falling asleep yesterday. This morning I re-read this issue, #31, and notes from various LEWG design reviews, which confirmed for me that moving towards stateless:

• is possible without a major, impractical design overhaul;
• won't make the API more difficult to learn and teach (it may even make it easier); and
• it actually solves the last major design issue that I've never had a satisfactory answer for.

So three cheers for stateless and all who suggested it.

(And a tin medal for me for finally grokking it before it was too late.)

Thanks again!

-Mike

[mikebmcl]

The R4-compliant (modulo bugs) release is out. I'm going to investigate on my end to see what performance is like.

@tyoma If you can spare the time at some point, I'd be grateful if you could run the tests again. Especially if, prior to the draw loop (i.e. surface::begin_show) you can use path_builder to create the path geometry and then convert it into a path_group that is available to and used in the draw loop. You may already have been doing this; apologies for not having a chance to look at your code yet.

Best regards,

-Mike

[tyoma]

Sure, later this week probably