Even if they could (which the license they use doesn't allow), why would they shoot it down?
Originally Posted by Marc Driftmeyer
I'm saying a project with limited resources should focus on a limited scope rather than trying to replace any other third party library. A team or company should not forget who their target is, and stay focused on creating a solid product for a certain market/demand. Doing display and event management across all the target platforms is a massive task by itself.
Originally Posted by Ancurio
If there's a threading API in the standard library (and there is), there's no reason not to have a drawing API too. Or a networking one (which is already in Boost and the plan I believe is to move it into the standard library at some point.) It's not like they're adding this into the language; they're adding it into the standard library.
Talking about standard library, I believe most compiler manufacturers should put a bit of work on modularizing their implementations. I wrote a small patcher in C++, and while the Linux version takes a few KBs (less than 40, IIRC), the Windows version needs to either ship with a ~500-600KB dll or take ~600KB if linked statically, while I only used vectors from the standard library (and a limited subset of its functionality, as the program is really simple).
are you sure?
Originally Posted by liam
i read openvg support on all those sites..
yes they're mostly embedded solutions, and yes OpenVG is mostly an api used in embedded (mobile), for now at least
but that is due to the need for a portable, hw - and os-independent accelerated 2d api being *mostly* felt there (since as far as the pc is concerned Windows already has Direct2D and Mac OSX has CoreGraphics, while linux apparently is fine with unaccelerated Cairo...) and doesnt deny it being one such api
The difference is, there's only one way to do threads on any given platform. The threading APIs for Windows, Posix, etc have been stable for decades. They are the perfect target for standardization.
Originally Posted by RealNC
Drawing, even 2d drawing, is not so simple. Algorithms in this field are constantly evolving. We've moved from software rendering to increasingly programmable hardware (vertex/fragment shaders -> geometry shaders -> hull/domain shaders -> compute), we've moved from 8bit palettes to 16/32bit colors then 64/128bit floating-point formats (for complex effects, HDR), we've moved from bitmap text to path rendering, we've added antialiasing, subpixel antialiasing, kerning, hinting, ligatures.
Cairo is a good library, but it is already dated. In ten years, any standard based on that will look like the X11 rendering routines look today: pretty much useless.
It just looks like a huge amount of effort for something people are not going to use in the end...
Whoever decided Cairo was a good idea is a complete idiot, Cairo is slow and its Path Implementation is a broken mess. WTF is wrong with these people?
1. Nvidia Path Rendering (Is the Best in the Industry)
2. OpenVG (Not as fast as NVPath but its Path Rendering Implementation is just as good)
3. Anti-Grain Geometry (Software Based, No Hardware Acceleration but its Path Rendering Implementation is just as good)
why not win32 instead of posix ? see, how useless your suggestion is
Originally Posted by LightBit
even if you are right, in ten years api can be extended/improved
Originally Posted by BlackStar
while you instead proposing to do nothing at all and use iostreams for ui - clearly better, isn't it ?
whoever doesn't understand that standard describes only interface and not implementation, is a complete idiot
Originally Posted by zester