Slashdot Mirror
Cairo 2D Graphics May Become Part of ISO C++
An anonymous reader sends this news from Phoronix:
"The C++ standards committee is looking at adopting a Cairo C++ interface as part of a future revision to the ISO C++ standard to provide 2D drawing. Herb Sutter, the chair of the ISO C++ standards committee, sent out a message to the Cairo developers this week about their pursuit to potentially standardize a basic 2D drawing library for ISO C++. The committee right now is looking at using a C++-ified version of Cairo. Sutter wrote, 'we are currently investigating the direction of proposing a mechanically C++-ified version of Cairo. Specifically, "mechanically C++-ified" means taking Cairo as-is and transforming it with a one-page list of mechanical changes such as turning _create functions into constructors, (mystruct*, int length) function parameters to vector<struct>& parameters, that sort of thing — the design and abstractions and functions are unchanged.'"
C++ stopped being a fully-humanly comprehensible language a long time ago. Might as well just add more crap to it like it's going out of style.
Cairo is a great library, I've used it and found it very easy, but it's not remotely approaching a standards-quality design. The closest I've seen would be Anti-Grain Geometry, which makes phenomenal use of templates.
i sincerely hope cairo itself remains 1. pure c and 2. as a project, entirely unconstrained by complaince to whatever 'standard' these c++/microsofty goons want. if they want to take a snapshot of cairo's api as a model for some c++ api, fine, whatever, couldn't even stop 'em if we tried. though the effort would be better spent finding more active maintainers for cairomm.
but cairo underlies current versions of major linux gui toolkits. i can't help but view this as some sort of convoluted gambit on microsoft's part to infest it with bureaucracy and c++ architecture astronautism and eventually seize control of the direction or just kill it.
This is redundant. High level concepts like drawing graphics are always going to be system dependent, and today's operating systems come with them already. I don't see why having this as part of the C++ base library benefits..
Blitting to the screen may be OS-dependent, but rendering to a canvas need not be.
One of the hallmark problems of design-by-committee is that they extend languages for the sake of doing fun things, not because people need it.
While everyone needs containers (like vector/hashmap), nobody needs a simple graphics library. There is practically no hardware out there that doesn't have some sort of hardware accelerated graphics and simple operations just make no sense there.
So, my question really is why they are doing this? I'm betting the answer is not one where they have actual usecases in mind.
The problem is, what's efficient, or nice, is not well defined. Should you antialias lines? If so, what type of antialiasing? Is that type of AA efficient on the graphics card in use? If you don't do that, do certain programs break?
These are all questions that have been answered before by java –yes, everything breaks, because everyone needs to implement graphics subtly differently.
Hey let's get a standardized vector and 2D drawing library going! Fuck the hardware or implementation details which indicate you'd be better off not limiting the dimensions to 2. Never mind the fact that we'll be filling triangles on a GPU for any sort of efficiency at all. Nope. Fuck starting at the actual primitives present and working up from there, let's do the top-down approach yet again -- When the performance conscious folks include messed up limitations, like the Diamond Inheritance pattern (Which has no reason to exist, variable placement should be virtual too, dimwits).
Yeah, I'll stick with C. At least it doesn't pretend to do anything but present the Von Neumann architectural constructs to me and let me build my OOP, etc atop them. It's still not optimal because it has the moronic assumption that functions should be on the stack and not the heap -- thus hindering or outright preventing closures, co-routines, and arbitrarily limiting recursion despite the system's available RAM -- but it's miles beyond C++ in terms of idealic design splattering all over the hard brick wall of reality's implementations. I mean really, if you can't use method overloading properly with templates and polymorphism then the language is broken by design, and there are no complete implementations.
Hey! I got an idea. You know what would be nice in C++? How about a standardized ANSI terminal interface, like VT100 -- Get ncurses into the spec. Oh! And you know what else? How about RMI! Yeah! Oh oh oh!! I got one I got one! INTER-fucking-FACES for IPC! Yeah! So you could query a program's interface and pass data between processes transparently in a language independent way -- and the doc comments could be lexical tokens too, so that if the .dat file was present even a terminal mode program could query a program's usage without needing a manually constructed manpage, and other programs could implement the same interfaces allowing us to assemble programs from sets of features. You know, something smarter than STDIN and STDOUT and a char**? Something actually fucking useful for a damn change?
Is there anything it cannot do?
Garbage collection.
If Pandora's box is destined to be opened, *I* want to be the one to open it.
Java, C#, and JavaScript all have graphics and canvas component libraries. All these libraries render graphics differently on different systems. In the C++ universe, programmers have had to use 3rd-party libs like Qt, so a C++ standard library for graphics is long overdue.
Do you develop for windows? I suspect yes, because in linux we've had this library for years and everyone knows it's a freakin' cross-platform library with very good documentation, coding style, naming convensions, specs, ...
Stop ranting already.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
Heh, that's correct.
Here's the proper link to Herb's post. http://lists.cairographics.org/archives/cairo/2013-December/024858.html
(You have to flip to 2014 archives to see the full thread.)
"It's implemented on the CPU" is the first gigantic red flag here. The implication of this is that it's so tightly specified that it's impossible to implement efficiently (i.e. on all vendors different GPUs which do subtly different things re how the exact pixel colours come out).
There was a paper in committee that would make it possible (authored by Boehm, no less). It didn't live to see C++11, though.
Most modern GC based languages can be faster and reduce memory fragmentation with heavy allocate and deallocate work loads, compared to C/C++. The trade off is less control and more jitter, but the benefit is potentially higher throughput. Without heavy micro-optimizations and essentially your own GC, C/C++ cannot compete.
.Net with ASync and tasks will give most other languages a run for their money, it has better scaling than most others. It heavily focuses on reducing context switching and increasing data locality.
What it comes down to is the GC keeps working memory highly compacted in a very efficient way, such that it allows memory allocations to be nothing more than incrementing a pointer. No searching for free space involved. It can also do background compaction while your program is running, and on different threads. These things are less efficient than micromanaging this stuff yourself in C/C++, but the amount of work involved makes it an expensive optimization, which is virtually free in a GC language.
I'm not trying to say that GC languages are faster in general, but in many common work loads, the GC compensates enough to make a GC language near C/C++ speeds. If I can write a program 5x faster, have fewer bugs, and have it running 80% the speed, that's a win.
Most of the time, programs are not CPU or memory limited, just limited by bugs and development speed. The more popular programs are actually heavily IO bound.
Many C/C++ programs have negative scaling with lots of IO. Once you've hit peak performance, it actually gets slower instead of maintaining current rates.
The problem is, what's efficient, or nice, is not well defined. Should you antialias lines? If so, what type of antialiasing? Is that type of AA efficient on the graphics card in use? If you don't do that, do certain programs break?
You're making this more complicated than it needs to be.
First of all, why would you ever want to draw Bresenham-style non-anti-aliased lines? The only reasons I can think of would be if you're emulating some sort of legacy system, or if you are working on an embedded platform with a monochrome LCD display. And these are unusual enough situations that I think it's reasonable to expect you to write your own code or use a library designed specifically for your purposes, rather than demand that a proposed industry standard be modified or eliminated entirely simply because it doesn't fit your particular idiosyncratic need.
And since when is it important precisely which anti-aliasing algorithm gets used? I checked the SVG standard, and it says nothing about what particular algorithm is used for lines and other primitives. Indeed, as you mention, it would probably be inefficient to do so, since not all GPUs may be optimized for the same method. Yet this is a cross-platform standard, supported by multiple browsers, and works just fine in the real world. If someone is writing vector graphics that rely on undocumented, system-dependent aspects of rendering to display correctly, they're doing it wrong.
I think he's referring to signed integer overflow conditions, which don't behave as most people would probably expect and aren't trivial to handle correctly.
Most modern GC based languages can be faster and reduce memory fragmentation with heavy allocate and deallocate work loads, compared to C/C++.
Suspicious sounding statement. Such things are ususally based on writing C++ like java (i.e. new everything). C++ uses stack allocation for very much stuff, and that is free (the pointer increment is already done on function entry) and 100% guaranteed fragmentation free.
If I can write a program 5x faster, have fewer bugs, and have it running 80% the speed, that's a win.
Why would C++ be slower to develop? You're confusing garbage collection with "memory management". C++ does memory management very well. I can't recall the last time I had a leak and that's not because I'm super awesome.
Most mm is just plain invisible in C++, since stuff is deallocated on scope exit. For everything else (nearly) there's reference counting. Reference counting doesn't work if you have general (i.e. cyclic) mutable graphs. I'm not sure I've ever had one of those.
SJW n. One who posts facts.
The STL is *part of* the C++ standard library. Its the various container classes, algorithms functions, etc. There's also iostream, the old C header files, and some new stuff like threading in the C++ standard library.
Also, not all C++ compilers implement all of the C++ spec (in fact, none of the major ones do, see export keyword). Most embedded compilers leave out the STL, because they don't support templates or do so only partially. Many others require you to separately build and link the STL, and don't by default have it in the runtime (for an example of this, the Android NDK). This is due to be fixed 3 years after the heat death of the universe.
I still have more fans than freaks. WTF is wrong with you people?
I've noticed that regardless of all claims about how Java can be faster than C++, I've never seen Java desktop applications beat C++ at the most important thing - startup time. I'll give you an example with JDownloader - that application takes 10-15 seconds to start.
Speed perception from the user's point of view is based on startup time and latency. I still haven't seen a Java desktop application that feels responsive.