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.
We have stdio.h why not stddraw.h ?? It's not like stdin/stdout are not system/hardware independant.
The second link goes to the wrong article.
Here is the correct link
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.
Link 2 is for a different story.
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.
Rasterization is hardly system dependent.
There's a variety of well defined mathematical algorithms for coordinate space transformation, intersection, and ultimately rasterization of polygonal and parametric/polynomial shapes.
No one is saying this graphics library is going to draw to the screen, in fact based on the discussions and proposals - it'd raster directly into memory (and it's up to the user to implement system dependent methods to take it from memory and display it on the screen, if that's even what the user wants).
the "sent out a message to the Cairo developers this week" link above points to the knight's landing page from another story...
Actually, it's correct grammar. Benefit is also a verb.
http://www.merriam-webster.com/dictionary/benefit
(scroll down)
Is there anything it cannot do?
The old C++ looks better and better as they nail every bit of crap they can find to her wretched offspring.
It had better be both damn well specified, and super under specified at the same time.
If it's not well enough specified, different OSes will do different things re (for example) antialiasing, where they decide the centre of a pixel is, etc
If it's too well specified, no OS will be able to implement it efficiently.
My suspicion is that it'll end up under-specified, and useless because of it, in the same way as java's drawing libraries are typically an endless source of bugs (common ones being that the developer assumed that no AA would happen, and then breaking on OS X or more recent windows installs, and rendering nasty looking halos around things, because the developer assumed they could just over-draw something and it would disappear).
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.
Yes, I know, but it seems to me that those kinds of functions don't belong in the base library as the particulars would be design dependent anyway. For example, we have mpfr for floating point math, which is distinctly separate from the rest of the toolchain, and is an optional piece. Maybe the line is arbitrary, but it seems like feature creep to me.
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?
Except for the glitz backend, Cairo has nothing to do with the GPU - it's all implemented on the CPU, same implementation on all architectures, all platforms.
Antialiasing options are defined as flags.
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.
Obviously this is early stages, and I am not outright opposed to the concept of having a standard vector graphics library. The creation of formatted documents (pdf) and images is a low level and common task. The productivity of many programmers could be increased by having a standard library which can be easily linked against.
However I do feel like this opens up a can of worms. Will they also include a FreeType interface to support text output? What backends will be included by default?
A vector graphics library without the ability to handle text seems seriously crippled. On the other hand choices for including text output basically come down to:
Graphics libraries and their APIs are Here Today, Gone Tomorrow. The hot thing today will most likely be superseded and irrelevant in 10-15 years time.
Glass-TTY interfaces, like the implementations of stdin and stdout in C++ compilers targeting PCs when not redirected to a file or pipe, have for the most part been superseded by GUIs. At least Cairo would provide a starting point toward a bare-minimum image manipulation and GUI component that a C++ program can expect, much as Tkinter does for Python.
One can implement coroutines in C.
Yes benefits is a verb, but in this context it is a transitive verb, meaning a direct object is required.
Create a standard interface and leave the actual implementation to be platform dependent. In this case rendering results will differ depending on platform.
C and C++ leave even operations on signed integers implementation-defined, so leaving the precise appearance of text implementation-defined shouldn't be too much of a problem.
the STL isn't part of the standard runtime
I thought apart from <iostream> and friends, the STL was the C++ standard library. Are you by any chance referring to the difference between a "freestanding" implementation and a "hosted" one, where a "freestanding" implementation is permitted to leave out standard libraries?
Is there anything it cannot do?
Garbage collection.
It can, tho. It's not yet in the standard but there are actual garbage collectors for C++.
Skip to 1:15:00 and watch Herb Sutter explain why they're doing this stuff.
http://channel9.msdn.com/Events/GoingNative/GoingNative-2012/C-11-VC-11-and-Beyond
I hate reading the comments on Slashdot.
Conservative ones, yes.
But accurate ones? Multithreaded? Without "stopping-the-world"?
If Pandora's box is destined to be opened, *I* want to be the one to open it.
... benefits me.
Satisfied?
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion. -- Spazmania (174582)
I'll finish it for him...'anyone.'
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)
As someone who learnt C then C++ as my first languages, I agree. If there's such a thing as too high level, we're reaching it.
I'm self-taugh but I know how the metal works and made my own toy OS. Then learning other languages was a piece of cake.
Languages like C#, Python,etc are so easy it almost feels like cheating.
C and C++ leave even operations on signed integers implementation-defined, so leaving the precise appearance of text implementation-defined shouldn't be too much of a problem.
Right. Except that is complexity exposed to the programmer and easily dealt with via int32_t, uint32_t .etc. This is inconsistency exposed to the user.
You seem to be confusing "this works well on linux" with "this is the perfect solution for all platforms, and it works perfectly across all platforms".
"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).
The implementation-defined precision of floating-point types (float, double, and long double) is inconsistency that could end up exposed to the user if the last significant figure is displayed or if a rounding difference causes an if statement to go one way or the other.
No, he isn't. He's saying that people who code for Windows only aren't even aware of the fact that there are great cross-platform libraries available to them which work just fine on Windows. And he is right.
libxml2 has a similar story, by the way.
No, he's assuming that the existence of one cross platform library for one well specified task means that another task can be well specified in a way that it can be efficiently implemented on all platforms. That's not true of graphics. This isn't even true of different implementations of graphics drivers on one platform, let alone across platforms.
just like the STL isn't part of the standard runtime.
STL is the part of the standard C++ library - has been that way sinco ISO C++98.
Since when do libraries become the "standard"?
Since ANSI C89 standardized things like fopen()?
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.
Why isn't it true for rendering 2D graphics to a memory or a file? What, exactly, is different between Windows and Linux in drawing a line of a given color and thickness from (x1, y1) to (x2, y2)?
(And don't say "anti-aliasing algorithm" - that should just be a configurable parameter.)
A real world complex cross platform program using Cairo is Firefox (most recent might use something different by default on Windows, I haven't kept up). It works pretty good on all platforms including non-main stream with (at least on my platform) options to control things like anti-aliasing.
https://en.wikipedia.org/wiki/Inverted_totalitarianism
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.
Is there also a GUI toolkit such as GTK on its way into ISO C++?
You seem to be confusing "this works well on linux" with "this is the perfect solution for all platforms, and it works perfectly across all platforms".
Cairo works fine on Windows. Firefox used it for quite a few releases, and I believe still has it included as a fallback if their custom "Azure" rendering library is turned off or can't work for some reason. In fact, it was Mozilla that contributed the Direct2D back-end to Cairo. (Cairo is quite flexible - you can make it render its canvas to almost anything: SVG, PDF, Windows GDI, X11, and a couple of others.)
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.
but how do I interact with the program? Will the new standard include anything like mouse input?
Industrial space for lease in Flatlandia.
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.
You mean, std::forward_list?
Rather than make C++ appeal to people who probably should stay in their high level languages, I think they should be putting their time into productivity. As much as I liked to spend time in C++ not writing any actual code playing with macros, templates, etc. in addition to finding new ways to hang myself; I don't find myself doing C++ anymore - I just don't like fooling around enough (yet I still do perl for fun; does that make sense?)
I think all the man power needs to be put into technical development not fluffy graphics libraries. I'm not as big on portable compiling as I am for some kind of binary format and linking system that would make it easier for an old program to run on a newer OS without needing all these virtual machines. Not exactly Google's NaCl (or whatever it's called) or a byte code but an attempt to address such issues. Not for java style portability, but something so legacy software can run without easily breaking (which it can do even with Java over time) and yes, it would get into OS turf... just like many other languages do as far as how library code is linked and loaded.
It's been a long time away for me... I've not looked at C++11 but here is a wishlist:
Text output needs improvement more than we need graphics. More debugging, logging, dummy functions, test case related standardization - more dynamic binding, runtime introspection features and other things that go against the initial design goals but ONLY in limited contexts, such as debugging and testing; thereby, retaining the intent of C++ but unleashing it for development purposes (such as a console or recompiling running code and replacing it.) This would fit in with their trend to be all things to everybody without changing/breaking the past decisions. It would be difficult to implement in some cases; but it's a debug mode.
I've always wanted named parameters; which could have been handled completely on the compiler side without run time penalty. ADA style typing was always appealing, for some things. How about something like JSON object literals? Native RegExp literals? A built-in parser generator (grammar definitions that produce parsing code you don't need to mess with.) Easier internationalization.... forget drawing lines, give me a great way to print "hello world" in many languages; or localize time and dates. A Money class to avoid common errors (use of float.) Configuration API. Apache's memory pool system seemed cool to me (APR,) garbage collecting not so much. Parallel processing features (if not already some, work on more-- again thinking of productivity and debugging.) We still don't have a multiple level break yet, correct? (like an exception but more limited in scope and as fast as a goto. Don't freak out, I didn't endorse goto.) I wouldn't mind a way to define a graph literal... I assume we must have a String object that handles unicode issues... we didn't last time I touched C++. Unicode source files... that allowed use of math operators like root... which have unicode characters...
Just ideas... to help bloat the compiler.
Democracy Now! - uncensored, anti-establishment news
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.
its not the GC that allows you to develop faster, its the surrounding infrstructure that does that. Imagien writing your C# code in notepad - you just wouldn't do it, it'd be painfully slow. That's where the development productivity comes from.
GC can be a huge burden though, not only does it encourage sloppy 'the GC will take care of that' style attitude that hurts performance badly (as prime example consider why there is a StringBuilder class at all, if the GC is so fantastic and fast at memory management). If you need to manage something that is not memory, whatever that is, you start to have to worry quite alot about how to trap and free the resource correctly.
I recall an old WCF program I wrote, I implemented IDispose correctly in the handler object, yet if anything thew an exception (which I wanted, to pass to the client as a SOAPFault) it wouldn't clean up the server-side state correctly, and the next call would contain a little bit (of logging state in my case) from the previous call. Bummer. Worse bummer - figuring out how to force the GC to correctly finalise my object when I wanted it done. Ended up having to manage all that object lifecycle manually. Manually! It ended up like coding C again and remembering where to put the delete() call.
So no, GC in the real world is handy, but doesn't increase developer productivity, or code performance (except for benchmarks or simple stuff that don't use it like the real world). Fewer bugs - hardly, you just shift them elsewhere.
FYI, take a look at Microsoft's SafeHandle class. That shows exactly the problem with GC systems. If you have to create a low-level reference counting class to work around the GC, but the creators of the entire VM, then you know GC is not a silver bullet.
C++ is better off without it, stick to RAII and be happy.
StringBuilder exists because the string data type is immutable. It has nothing to do with GC. String concatenation without StringBuilder is a painter's algorithm as it has to keep re-copying the working version of the string for every piece added.
As for proper clean up with exceptions -- that's what using() and finally{} are for. If you're using an object that implements IDisposable and not properly disposing of it when it goes out of scope (for any reason) then you're doing it wrong.
Finalizers are also usually the wrong thing to do in C#. The very definition of the language states that they will be called whenever the hell the GC feels like and you definitely should never rely on them being called in a timely fashion. Generally speaking, you can leave managed objects to take care of themselves and unmanaged objects taken care of in a Dispose() method. 99% of the time, the only thing you should use the finalizer for is forcing a call to Dispose() in case whoever is using your class doesn't bother properly disposing of it.
Yes, Dispose() smells a lot like C++'s delete. That's the way of life -- if you want a guaranteed cleanup then you're going to have do it yourself. There's only so much guessing the GC is capable of. But most of the time you're dealing with regular managed objects and the GC does its job just fine, leaving you to worry about the logic of your program rather than whether or not its leaking memory.
And yes, there are of course situations where the GC outright doesn't suffice. And the language designers gave us utilities for dealing with those situations when they occur. But I have yet to run into one that didn't turn out to be me just doing something dumb (I came from a C/C++ background myself.)
You're right -- GC isn't a silver bullet. But its still a hell of a lot easier to write safe code when you only have to worry about object destruction 10-20% of the time. And if you're really stuck, you can force the GC to collect whenever you feel like (of course you take a performance hit for doing that so its generally not recommended.)
(I suppose the C# team could implement a class attribute to force finalization when an object goes out of scope but I have no idea if that would be a huge performance hit or they just never thought of it or they thought of it and decided they didn't like it or what. Still only solves one small part of the problem in any case though.)
What's the point of this? cairo is a C library. I guess you could standardize it as part of C2014 or something but just converting its interface to C++ as they say is just pointless. It would result in as much work as would be to make a proper C++ api from scratch and wouldn't necessarily result in as good C++ api as cairo is for C.
The point is that AA algorithm *can not* be a configurable parameter, because different hardware simply does it in different ways. It's impossible to implement FXAA efficiently on nVidia hardware, and it's impossible to implement CSAA efficiently on AMD hardware. This is the point, efficient implementation of graphics *must* be sufficiently weakly specified that it can be efficiently implemented. The result of that is that it can not be sufficiently strongly specified that all platforms behave the same, and you can get benefit from having a nice abstracted cross platform API.
My problem with this is how do you build a compiler from sources for a faceless embedded platform. I'm currently seeing this play out in the Qt environment. There are a lot of nice non-GUI features to it but I have yet to be able to cross-compile v5.x of the thing for an embedded ARM platform that has no display, keyboard, or mouse. 4.8.5 works fine but Digia changed a bunch of stuff in 5.x and now I'm SOL.
IMHO, something like drawing should be compartmentalized into a library.
When I start a Java application it usually runs for weeks if not months (until a system update requires a reboot).
I don't really care if it takes 5, 10 or 120 seconds to start up.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
I kinda' missed these flame wars..
Such high-level concepts wouldn't be high level concepts if they were system dependent. Cairo offers a device-agnostic interface, just as C++ iostreams does, or C's file I/O. Many of Cairo's devices are completely system independent - pretty much any device that is not tied to the API of an operating system. So, if you use Cairo to draw into platform-specific handle on Windows or OS X then yes, your application is system dependent. But those are the only examples I think. Everything else is agnostic. With Cairo, you write to raster or vector files the same no matter what OS you're on, and the output is supposed to be the same; unless floating point implementation details interfere with that. Even output via Xlib will work the same for a given X server - you could be accessing that server from OS X, Windows, Linux, BSD, or even an OS-less embedded device that uses xlib with a stand-alone TCP/IP stack.
A successful API design takes a mixture of software design and pedagogy.
That's just silly. All of what you mention is still system-independent. Whether you antialias or not is just a choice of algorithms you use to draw lines. It produces identical output no matter where you run it. If you use Cairo to generate a PDF file or a JPEG file, the only differences in output will be due to floating point implementation differences. The operating system has nothing to do with anything here.
A successful API design takes a mixture of software design and pedagogy.
Nobody in their fucking sane mind uses an OS-provided library/API for antialiasing or for actually rasterizing anything! It hasn't been done for ages if you care about portability at all. Anything that is portable out there will positively not use any platform APIs since they are usually a hell to deal with and are quirky (read: bugs that became "features" by default, not by design). Both Cairo and Qt do basic rasterization using their own code. If you use a cross-platform web browser, it doesn't use any platform APIs for drawing other than for copying the final bitmap to the screen. We're talking anything webkit-based, anything gecko-based, etc. If you use any recent Qt-based application, it does the same.
A successful API design takes a mixture of software design and pedagogy.
Cairo works better at rendering stuff on Windows than winapi-style libraries are. Seriously.
A successful API design takes a mixture of software design and pedagogy.
Drawing a line using hardware acceleration ends up in a bunch of geometry generated and sent to DirectX or OpenGL. That's how it's currently done, and even Cairo has a glitz backend that does just that. Qt supports this model widely. Legacy QPainter API using the OpenGL backend is available for QWidget and QWindow-based apps, and for Qt Quick 1. Qt Quick 2 has a way better performing scene graph implementation that renders using OpenGL as well.
A successful API design takes a mixture of software design and pedagogy.
Your arguments don't seem to work well together. A few posts ago, you argued that the existence of a good cross-platform Linux solution didn't mean a good Windows solution, but now you're arguing about efficiency on different hardware. Any good general Linux solution is going to work on a very wide range of hardware, and in fact if there couldn't be a good solution across a range of hardware there couldn't be a good Windows solution either.
If it's possible to produce a general Windows graphics library, or a general Linux one, it's possible to have a general graphics library that works fine on either.
"When you have eliminated the unacceptable, whatever is left, however improbable, must be the truthiness" - Holmes
Undefined behavior doesn't mean implementation-defined behavior!! Don't use them interchangeably!
A successful API design takes a mixture of software design and pedagogy.
The point is that AA algorithm *can not* be a configurable parameter, because different hardware simply does it in different ways. It's impossible to implement FXAA efficiently on nVidia hardware, and it's impossible to implement CSAA efficiently on AMD hardware. This is the point, efficient implementation of graphics *must* be sufficiently weakly specified that it can be efficiently implemented.
We are talking about 2D graphics here. FXAA and CSAA are not used to antialias 2D lines. Unlike 3D scenes, where you can't AA as you draw because of Z-order, in 2D, it's entirely viable, and is how things have always been done.
Also, accelerating basic 2D primitives is rarely even worth it, and few libraries have done it historically - yet no-one has complained about it even ten years ago, when desktops were several times slower than our phones today. The only thing that normally needs acceleration is blitting images, but that one is easy to specify in such a way that it can be efficiently done everywhere.
The result of that is that it can not be sufficiently strongly specified that all platforms behave the same, and you can get benefit from having a nice abstracted cross platform API.
This also presupposes that all platforms behaving the same is a desirable outcome, which is not necessarily true. E.g. as far as rendering on screen goes, I would strongly prefer the app to use text rendering appropriate to the platform - which would result in different output on Windows vs OS X, but said output would then be consistent with all the other apps that I may be running at the time.
Someone already did that a while back.
Stick Men
The only thing I really miss in it right now is C++ integration of some of the old language constructs. Most notably, I'd like to be able to create a stream from a file descriptor or a FILE pointer. That's pretty much how I do all my IPC. Currently I work around it with an object that contains GNU-specific code for that purpose, but it really seems like something that's missing from the language.
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
Exactly. Any software house that does cross platform graphics work most likely already has a library that does this already. Graphics abstraction layers are insanely common way of masking the underlying hardware or operating system differences whilst providing a common way of drawing to screen.
I've not looked into the details but I'm guessing all this does is standardise that, so that rather than everyone rolling their own, there can now be one that's standard for everyone. You can hop between companies and still know exactly how to draw to screen in C++ without having to learn their own custom internal abstraction layer for doing exactly that.
Graphics have be a part of C/C++ from nearly the beginning. They've been nearly worthless since the beginning (and probably still will be), but they've always been in there. This I suppose is just a refresh of "graphics.h" but instead of wrapping BIOS calls it's wrapping OS API. Perhaps this will serve as a good foundation for high-quality cross-platform GUI libraries but I'm leaning pessimistic.
Two of my imaginary friends reproduced once
Well, that's not what I do. I never keep an application open after I'm done with it - mostly because it clutters my taskbar. Btw, are you talking about desktop applications, or server applications?
Desktop in this case ...
I have only a Jenkins as "server" on my laptop.
I keep most apps pinned to the taskbar anyway, so it looks very similar regardless if the applications are running or not.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
This is the link that inspired my comment btw - http://programmers.stackexchange.com/a/409/31462
Yes, Java programs often have a slow start up.
But often there is a reason, which is not Javas fault but the programmers.
E.g. Eclipse, a wildly used Java IDE.
The first thing eclipse does when started is opening a workspace, a directory holding lots of projects, opening those projects and figuring if "they are up to date".
Other IDEs simply show the GUI and then use a background thread to "investigate" the projects.
It is not Javas fault that reading gazilion of megabytes of source code slows down the start up of Eclipse.
It is the braindead philosophy how Eclipse works. It would be similar slow in any other language.
Imagine Microsoft Developer Studio would not start showing its GUI until it has compiled/built all projects. That would be nonsense, too.
Hence, I rarely close my Eclipse. I just keep it running, after it started it is a well behaving citizen eating zero CPU.
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.
Yes, I've wondered if part of the problem is that the Java community is taught that productivity trumps performance. I mean the language advertises that its goal is to make it easier to write code by not thinking about speed.
... will appreciate readable programming languages. Only pseudo competent programmes too full of them self to see there own weaknesses want to use unreadable languages. And those pseudo competent programmes are an even bigger disaster then then JAVA/.NET generation because they brought us all the buffer overruns malware uses to attack our computers.
BTW: Java is not all that readable either.
Has there even been a full featured PL/1 with all optional features in place? I don't think so. And most C / C++ are not full featured either.
This is not something that is taught to "the Java community", it is in general taught to every CS student.
The reason is simple:
a) you can always optimize a finished solution, but if there is nothing finished you have nothing to work with
b) development time is expensive
c) hardware is cheap
All this are no reasons to actively build inferior solutions.
However: :D
in the time a Java programmer has done his first window and its first menu a SmallTalk programmer already has a visual prototype and the C programmer is still fixing typos after his second "make run", Yeah, I'm exaggerating, but you get the idea
Cost free eBook I read (by iBook/Kobo/Amazon/ObookO/Gutenberg etc.): "The Green Odyssey" by Philip Jose Farmer.