A Proposal to Add 2D Graphics Rendering and Display to C++ [pdf](isocpp.org)
isocpp.org
A Proposal to Add 2D Graphics Rendering and Display to C++ [pdf]
http://isocpp.org/files/papers/N3888.pdf
53 comments
>> Oh, and before they even think about adding graphics they should beef up the file system API.
It's being worked on. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n333... and I think that it should be part of C++14 or C++17 http://isocpp.org/std/status.
It's being worked on. http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2012/n333... and I think that it should be part of C++14 or C++17 http://isocpp.org/std/status.
Why not a full gui? I think I can give a simple reason. Desktop Gui libraries are large and complicated. Assuming you want a full featured cross-platform the choice would probably be qt. But Qt suffers from a lot of api version churn(much faster then c++ standards), includes language extensions(moc) and does a lot of things in a non standard way for c++(including using its own collections and strings).
The alternative I can see would be to write a very minimal functionality cross-platfrom gui library or use something other library that might not as cross platform(lacking mobile platforms(recent initial qt support but likely to improve in the future), not as easy to port, not as good looking on some platforms)
If you check the working groups there are lots of APIs being worked on, including file system ones.
http://isocpp.org/std/the-committee
- SG1, Concurrency
- SG2, Modules
- SG3, File System
- SG4, Networking
- SG5, Transactional Memory
- SG6, Numerics
- SG7, Reflection
- SG8, Concepts
- SG9, Ranges
- SG10, Feature Test
- SG11, Databases
- SG12, Undefined and Unspecified Behavior
- SG13, Graphics
Any modern language should have a "batteries included" set of libraries, even when targeted for systems programming.
http://isocpp.org/std/the-committee
- SG1, Concurrency
- SG2, Modules
- SG3, File System
- SG4, Networking
- SG5, Transactional Memory
- SG6, Numerics
- SG7, Reflection
- SG8, Concepts
- SG9, Ranges
- SG10, Feature Test
- SG11, Databases
- SG12, Undefined and Unspecified Behavior
- SG13, Graphics
Any modern language should have a "batteries included" set of libraries, even when targeted for systems programming.
> Any modern language should have a "batteries included" set of libraries, even when targeted for systems programming.
I would argue the inverse: modern languages should have a lean standard library but a strong package ecosystem.
I would argue the inverse: modern languages should have a lean standard library but a strong package ecosystem.
A standard library is a guarantee that all packages are supported in the target environments for the language.
Can you provide the same guarantee with a package system?
I don't what to target operating system XYZ only to find out the package does not exist.
Can you provide the same guarantee with a package system?
I don't what to target operating system XYZ only to find out the package does not exist.
I'm not sure about Cairo, but IMHO AGG is probably one of the best C++ libraries out there. Great use of C++ capabilities like templates. Too bad, development isn't active anymore.
AGG - http://antigrain.com
AGG - http://antigrain.com
Oh shit, apparently the guy behind AGG, Maxim Shemanarev, died 2 months ago.
http://beta.slashdot.org/submission/3154635/rip-maxim-sheman...
http://beta.slashdot.org/submission/3154635/rip-maxim-sheman...
C++ needs something.
It's a bit embarrassing when someone used to the standard library from most other languages asks "How do I draw this picture of a cat" or "how do I print 'Hello World!' in red in a welcoming font" and you have to say, erm, well.. there is nothing in c++ for that. Maybe you can find a platform dependent library that will work for you.
It doesn't need a library to do everything, but something that lets you draw and write text to a window seems like something that should be available on every platform that can support it.
It's a bit embarrassing when someone used to the standard library from most other languages asks "How do I draw this picture of a cat" or "how do I print 'Hello World!' in red in a welcoming font" and you have to say, erm, well.. there is nothing in c++ for that. Maybe you can find a platform dependent library that will work for you.
It doesn't need a library to do everything, but something that lets you draw and write text to a window seems like something that should be available on every platform that can support it.
"Most other languages" seems like an exaggeration. I don't think you can do any of the things you list easily in Python, PHP (you wouldn't even want to in PHP), JavaScript or Haskell.
Python includes Tkinter for GUI programming. That said, Tkinter is pretty crappy compared to PyQt.
The number of users of Tkinter in Python is so low that I would seriously question its utility in the standard library. IDLE is the only piece of software that I know of that targets it, and it's quite underwhelming.
It is available in the form of cross platform libraries like GLFW.
The motivation reads exactly like the xkcd comic on standards. http://xkcd.com/927/
The rest of the document reads like someone just discovered the Cairo library and wouldn't it be cool if we jammed this into our already overly-bloated standards document?
There is no all-purpose graphics library. What's good for games isn't necessarily good for rendering PDFs and vice versa.
The rest of the document reads like someone just discovered the Cairo library and wouldn't it be cool if we jammed this into our already overly-bloated standards document?
There is no all-purpose graphics library. What's good for games isn't necessarily good for rendering PDFs and vice versa.
...wouldn't it be cool if we jammed this into our already overly-bloated standards document?"
I think C++ gets the most flack for being too complex and bloated. But when you compare it to Java and C#, C++11, the language (based on language specification word/page count), is smaller than Java and only a little bigger than C#. The C++11 standard library is much smaller than both the Java 7 SE and the .Net (FX only) libraries.
Source: http://media.ch9.ms/ch9/5c51/d30749f7-09d7-4266-bd57-d1d4461..., just after 15 minutes in. Or http://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%..., slide 14 and 15 (see the top-right corner of slide 14 for the metrics used for the comparison (page/word count of the language specs). EDIT, for context: the speaker/author referenced is Herb Sutter, member of the C++ standisation committee, and one of the authors of the graphics proposal in question.
I think C++ gets the most flack for being too complex and bloated. But when you compare it to Java and C#, C++11, the language (based on language specification word/page count), is smaller than Java and only a little bigger than C#. The C++11 standard library is much smaller than both the Java 7 SE and the .Net (FX only) libraries.
Source: http://media.ch9.ms/ch9/5c51/d30749f7-09d7-4266-bd57-d1d4461..., just after 15 minutes in. Or http://view.officeapps.live.com/op/view.aspx?src=http%3a%2f%..., slide 14 and 15 (see the top-right corner of slide 14 for the metrics used for the comparison (page/word count of the language specs). EDIT, for context: the speaker/author referenced is Herb Sutter, member of the C++ standisation committee, and one of the authors of the graphics proposal in question.
>But when you compare it to Java and C#, C++11, the language (based on language specification word/page count), is smaller than Java
I watched the presentation where Herb Sutter said that, and I think that claim is disingenuous, because the Java Language Specification is much wordier than the C++ spec.
For example, the section on integer literals in the JLS is 1.5 times longer (measured by word count) than the same section in the latest C++ draft. Is it because Java's literals are more complex than C++? No, it's because of things like explicitly listing the minumum and maximum numeric values of int and long literals (in each of decimal, hex, octal and binary)
In general, I think that the terseness of the C++ spec is not a good measure of the relative simplicity of C++.
I watched the presentation where Herb Sutter said that, and I think that claim is disingenuous, because the Java Language Specification is much wordier than the C++ spec.
For example, the section on integer literals in the JLS is 1.5 times longer (measured by word count) than the same section in the latest C++ draft. Is it because Java's literals are more complex than C++? No, it's because of things like explicitly listing the minumum and maximum numeric values of int and long literals (in each of decimal, hex, octal and binary)
In general, I think that the terseness of the C++ spec is not a good measure of the relative simplicity of C++.
Well I think the idea is that it is a good general metric which should average out over thousands of pages. Just because one section of the Java language spec is wordier than the corresponding one in the C++ language spec does not mean it holds for the entire document.
But I concede the point of complexity; the C++ spec is no doubt more dense. I just don't think it deserves to always be singled out as the most overly-complex/bloated language. The difference is not as big as the cliche would have people believe.
Also, the article is about adding to the standard library, which is much smaller than Java's and .Net's, so invoking bloat is probably not appropriate in the context of the article.
But I concede the point of complexity; the C++ spec is no doubt more dense. I just don't think it deserves to always be singled out as the most overly-complex/bloated language. The difference is not as big as the cliche would have people believe.
Also, the article is about adding to the standard library, which is much smaller than Java's and .Net's, so invoking bloat is probably not appropriate in the context of the article.
Yeah, but you can actually understand what is going on in Java pretty quickly and get the weird corners cases on Stack Overflow.
By contrast, C++ requires that the user understand most of the minutiae, details, corner cases, and weird things that the language describes just to get a rather low level of competence.
The length of a language spec has little to do with its usability.
By contrast, C++ requires that the user understand most of the minutiae, details, corner cases, and weird things that the language describes just to get a rather low level of competence.
The length of a language spec has little to do with its usability.
Absolutely agree. OpenGL, SDL, Cairo, all are great and useful for their own purposes, with rather small overlap between then. A single uniform API for graphics is practically impossible, so why bother? To attract beginners?
Graphics has very limited usage without full GUI. I can think of only games and chart-rendering applications (or similar) that don't really need GUI. But games require some means for windows-handling (like GLUT in OpenGL). And "chart-rendering" require output routines to produce PDF/PS/SVG/PNG.. In any case, you need quite a lot of auxiliary IO functions to really do anything useful. So, how much of thes auxiliary stuff will be included in the standard library?
Also, if they plan to implement output with both DirectX and OpenGL, there is quite a lot of work to ensure that everything works on computers with GPU, without GPU, with ancient GPU, on Windows, Linux, OSX and actually looks roughly the same. This is not easy, if you want to do it efficiently.
For game development, beginners choose Flash game engines, or GameMaker, or something like that. I doubt that C++ can work better for them, even with Cairo built in.
The standard library will always have limitations, so you will need to use external libraries at some point anyway. And a transition to an external library can be difficult, if the standard library is already used extensively.
Yes, probably, humongous standard library is good for cross-platform development, but it must be implemented first. And again, external libraries are sometimes necessary anyway. Also some UI libraries are already cross-platform, like Qt, btw.
Graphics has very limited usage without full GUI. I can think of only games and chart-rendering applications (or similar) that don't really need GUI. But games require some means for windows-handling (like GLUT in OpenGL). And "chart-rendering" require output routines to produce PDF/PS/SVG/PNG.. In any case, you need quite a lot of auxiliary IO functions to really do anything useful. So, how much of thes auxiliary stuff will be included in the standard library?
Also, if they plan to implement output with both DirectX and OpenGL, there is quite a lot of work to ensure that everything works on computers with GPU, without GPU, with ancient GPU, on Windows, Linux, OSX and actually looks roughly the same. This is not easy, if you want to do it efficiently.
For game development, beginners choose Flash game engines, or GameMaker, or something like that. I doubt that C++ can work better for them, even with Cairo built in.
The standard library will always have limitations, so you will need to use external libraries at some point anyway. And a transition to an external library can be difficult, if the standard library is already used extensively.
Yes, probably, humongous standard library is good for cross-platform development, but it must be implemented first. And again, external libraries are sometimes necessary anyway. Also some UI libraries are already cross-platform, like Qt, btw.
That comic is starting to be used in situation where it's pretty irrelevant, such as here. How many cross-platform 2D graphics libraries are there?
Also, the purpose is pretty obvious if you look at the use cases of Cairo and it's obviously not meant for (serious) game making, but there already is an open standard for that.
Also, the purpose is pretty obvious if you look at the use cases of Cairo and it's obviously not meant for (serious) game making, but there already is an open standard for that.
I'd say it's very relevant. The "Motivation and Scope" section bemoans the over-abundance of library choices and then declares that there should be one standard library for all developers to use. That's literally the situation in the comic.
> How many cross-platform 2D graphics libraries are there?
The document itself points out 4 cross-platform libraries. A simple Google search for "cross-platform 2d library" yields at least a dozen more.
> Also, the purpose is pretty obvious if you look at the use cases of Cairo and it's obviously not meant for (serious) game making ...
They explicitly state that they want to serve rendering of any type, including games.
> How many cross-platform 2D graphics libraries are there?
The document itself points out 4 cross-platform libraries. A simple Google search for "cross-platform 2d library" yields at least a dozen more.
> Also, the purpose is pretty obvious if you look at the use cases of Cairo and it's obviously not meant for (serious) game making ...
They explicitly state that they want to serve rendering of any type, including games.
>> That's literally the situation in the comic.
No, the comic describes a situation with 15 competing standards. This is the first standard of it's kind.
>> The document itself points out 4 cross-platform libraries.
The document points out Qt, Cairo, GTK+, or SDL. Let's not count Cairo since this is basically Cairo. Qt is not GPU accelerated (nor is it a graphics library, Qt's graphics library is called Albert I believe) and GTK+ is not really a graphics library either and AFAIK, it itself relies on Cairo. So the only contender is maybe SDL (idk I don't know much about it, but it appears to be higher in the stack). And yeah, Google search does yield a lot of results. Similarly, if you Google for 'programming language', you will also get a lot of results. That does not mean that all of them are interchangeable or that all of them can be used for general purpose computing. If you are going to build a serious project, you will probably choose a platform with some support (such as a standard implemented by several vendors) behind it.
The only real contender that comes to mind is Skia (of the Chrome and Android fames).
>> They explicitly state that they want to serve rendering of any type, including games.
They're talking about 2D games.
No, the comic describes a situation with 15 competing standards. This is the first standard of it's kind.
>> The document itself points out 4 cross-platform libraries.
The document points out Qt, Cairo, GTK+, or SDL. Let's not count Cairo since this is basically Cairo. Qt is not GPU accelerated (nor is it a graphics library, Qt's graphics library is called Albert I believe) and GTK+ is not really a graphics library either and AFAIK, it itself relies on Cairo. So the only contender is maybe SDL (idk I don't know much about it, but it appears to be higher in the stack). And yeah, Google search does yield a lot of results. Similarly, if you Google for 'programming language', you will also get a lot of results. That does not mean that all of them are interchangeable or that all of them can be used for general purpose computing. If you are going to build a serious project, you will probably choose a platform with some support (such as a standard implemented by several vendors) behind it.
The only real contender that comes to mind is Skia (of the Chrome and Android fames).
>> They explicitly state that they want to serve rendering of any type, including games.
They're talking about 2D games.
Cairo is dual-licensed under the LGPL and MPL. Both of these are restrictive enough to make them incompatible with, eg., App Store terms. Yet the proposal does not seem to even mention the license (or maybe I just missed it).
The standards committee is conserned about portability, at least on a technical level. I wonder what their take is on portability issues caused by license terms.
The standards committee is conserned about portability, at least on a technical level. I wonder what their take is on portability issues caused by license terms.
They wouldn't be using the library code. They would just specify what have to be implemented based on the library. They have been doing this with all the libraries that they include in the standard (such as part of boost) and most of the time the resulted specification is way simpler and limited than the original inspiration. Also this is a design for implementation, once done each implementer have to decide how to make it real.
Boost has a very liberal license, unlike Cairo. C++ libraries, at least the GNU C++ library, have directly based some of their implementations on Boost.
This might lead to C++ library vendors not implementing the standard and requiring using a third party library, perhaps later integrating them into their own libraries.
Thinking about it, it is not probably a bad thing, it will just take longer than with other parts of the standard. Of course, this is just pure speculation and things might turn out very differently.
This might lead to C++ library vendors not implementing the standard and requiring using a third party library, perhaps later integrating them into their own libraries.
Thinking about it, it is not probably a bad thing, it will just take longer than with other parts of the standard. Of course, this is just pure speculation and things might turn out very differently.
You have a point if implementers choose to use cairo code instead of re-implementer it, but in the other case they don't need to follow any license at all since licenses are valid just for code, unless they have patents on it (which I don't think is the case in libcairo)
It's not quite the Java 2D API, but damned it's close.
Why not just knock off a good API, like that for <canvas>?
Why not just knock off a good API, like that for <canvas>?
It's covered in the linked document. To paraphrase:
1. It includes some extraneous things such as some CSS stuff. 2. There is some evidence that some of the canvas api may be covered by patents.
1. It includes some extraneous things such as some CSS stuff. 2. There is some evidence that some of the canvas api may be covered by patents.
Regarding (1), the mention of CSS refers specifically to SVG, not canvas.
true, but canvas does have some css things in it, such as, specifically, it uses the Color css submodule.
Oh yeah, good point.
AFAIK, Cairo is said to be the bee's knees. As in, I've heard multiple people refer to it as a yardstick of good library design.
Cairo & <canvas>'s drawing models are rather similar iirc.
The <canvas> drawing model is a very thin layer over the Mac OS X Cocoa drawing model (because it was originally developed by Apple as a proprietary extension to Webkit). The Cocoa drawing model is based on the "Display PDF" model, which is a descendant of the "Display Postscript" system used by the original NeXT OS, which of course was derived from the PostScript page layout language.
I think Cairo just borrowed the PostScript drawing model from the start.
I think Cairo just borrowed the PostScript drawing model from the start.
As are pretty much all immediate-mode 2D graphics APIs, except maybe OpenGL (when used as such).
Third-party libraries are third-party for a reason.
Adding every conceivable library as standard doesn't make sense, unless you're Java, in which case no one cares how much crap you bring along.
Adding every conceivable library as standard doesn't make sense, unless you're Java, in which case no one cares how much crap you bring along.
Other platforms doing this include Python, Erlang, Perl, and C#.
"Batteries included" works very well in many cases. Having a single de-facto dominant implementation helps.
"Batteries included" works very well in many cases. Having a single de-facto dominant implementation helps.
At least in the case of Python, "batteries included" decidedly works badly when it comes to graphics. The really usable and used GUI and graphics libraries for Python are all third-party.
It is indeed helpful in other areas, though.
It is indeed helpful in other areas, though.
None of those languages are meant for systems programming.
So what?!
Every language should have a proper set of "batteries included" in the standard library.
One is not forced to use every single feature on every program.
Every language should have a proper set of "batteries included" in the standard library.
One is not forced to use every single feature on every program.
You're making the situation far simpler than it is.
Extra batteries imply a greater codebase that has to be maintained, must support all modern architectures and compilers, and must evolve in a graceful way while maintaining backwards compatibility.
In general, backwards compatibility is a pain in the neck and results in libraries not evolving once they reach the standard library.
Python has tons of examples: urllib, urllib2 (both of them superceded by Requests, an external library that manages to incorporate a sane API), multiple subprocessing libraries, several refactorings of the OS exception hierarchy, etc.
Oh, and nobody actually uses the included GUI library for anything except the smallest of trivial examples.
This is something that can be tolerable in some high-level languages where performance is not a concern, but systems programming languages should tend to more conservative defaults and things that can be used in production to a certain degree of satisfaction.
Nobody is going to be happy with the default GUI lib in at least one of the many platforms; the existence of dozens of UI toolkits with different idioms, different looks, and different levels of integration are proof of that. And contrary to some more basic use cases, UI libraries tend to be, by necessity, absolutely enormous.
If the end result is going to be another poorly-designed library like many of the STLs modules, I'd much rather developers use the proper UI toolkit for the situation.
Extra batteries imply a greater codebase that has to be maintained, must support all modern architectures and compilers, and must evolve in a graceful way while maintaining backwards compatibility.
In general, backwards compatibility is a pain in the neck and results in libraries not evolving once they reach the standard library.
Python has tons of examples: urllib, urllib2 (both of them superceded by Requests, an external library that manages to incorporate a sane API), multiple subprocessing libraries, several refactorings of the OS exception hierarchy, etc.
Oh, and nobody actually uses the included GUI library for anything except the smallest of trivial examples.
This is something that can be tolerable in some high-level languages where performance is not a concern, but systems programming languages should tend to more conservative defaults and things that can be used in production to a certain degree of satisfaction.
Nobody is going to be happy with the default GUI lib in at least one of the many platforms; the existence of dozens of UI toolkits with different idioms, different looks, and different levels of integration are proof of that. And contrary to some more basic use cases, UI libraries tend to be, by necessity, absolutely enormous.
If the end result is going to be another poorly-designed library like many of the STLs modules, I'd much rather developers use the proper UI toolkit for the situation.
The goal is to have something that any programmer can use regardless of the the operating system.
Libraries in C and C++ are a pain to use, because they are only available for specific operating systems, specific compiler versions and tend to lack compatibility among themselves.
This pain also tends to be part of C culture, as other system programming languages already had the tradition to provide a proper set of libraries on their runtimes.
I think the main cause is that UNIX is actually C's set of libraries, but those libraries do not exist in all operating systems.
However having a set of libraries as default, is great for the guarantee to be able to write OS agnostic code.
No one is forced to use them, if they required more advanced use cases.
Libraries in C and C++ are a pain to use, because they are only available for specific operating systems, specific compiler versions and tend to lack compatibility among themselves.
This pain also tends to be part of C culture, as other system programming languages already had the tradition to provide a proper set of libraries on their runtimes.
I think the main cause is that UNIX is actually C's set of libraries, but those libraries do not exist in all operating systems.
However having a set of libraries as default, is great for the guarantee to be able to write OS agnostic code.
No one is forced to use them, if they required more advanced use cases.
Like I said before, nobody is going to use an OS-agnostic UI library because UIs imply necessary integration and a level of specificity that can't be generalized.
There's half a dozen blitting models with difference performance optimizations. You have at least 4 or 5 popular widget toolkits. Do you support 2D drawing? 3D?
There are some things that just can't be abstracted away without massive engineering costs. No portable standard UI toolkit would be complete and compatible enough to be used for serious applications unless they're willing to stoop to levels as low as Java's so-called "multiplatform" UIs, which honestly look like crap.
A UI toolkit that's low-level enough is useless in desktop and modern mobile platforms. At higher levels they're too OS and device-specific. If they're too device-specific they have no place in a standard library. Thus, no UI toolkit is apt for this space unless you're willing to settle for mediocre, second-class toolkits.
There's half a dozen blitting models with difference performance optimizations. You have at least 4 or 5 popular widget toolkits. Do you support 2D drawing? 3D?
There are some things that just can't be abstracted away without massive engineering costs. No portable standard UI toolkit would be complete and compatible enough to be used for serious applications unless they're willing to stoop to levels as low as Java's so-called "multiplatform" UIs, which honestly look like crap.
A UI toolkit that's low-level enough is useless in desktop and modern mobile platforms. At higher levels they're too OS and device-specific. If they're too device-specific they have no place in a standard library. Thus, no UI toolkit is apt for this space unless you're willing to settle for mediocre, second-class toolkits.
> Like I said before, nobody is going to use an OS-agnostic UI library because UIs imply necessary integration and a level of specificity that can't be generalized.
Begineers and people that care about presenting simple stuff will do surely use it.
The idea is to have good enough libraries to write portable code for simple stuff.
Should anyone have to go though the pain of creating a OpenGL context, matrixes and shaders to put some text on the screen?
You are always free to go write Win32, Xlib, Qt, GTKmm, MFC, Motif, wxWidgets, WPF, embedded Chrome or whatever UI flavor of the months is for REAL applications.
Begineers and people that care about presenting simple stuff will do surely use it.
The idea is to have good enough libraries to write portable code for simple stuff.
Should anyone have to go though the pain of creating a OpenGL context, matrixes and shaders to put some text on the screen?
You are always free to go write Win32, Xlib, Qt, GTKmm, MFC, Motif, wxWidgets, WPF, embedded Chrome or whatever UI flavor of the months is for REAL applications.
The node approach of making dependencies as tiny and reusable as possible is a good model. What C++ needs is a package management, not bloat.
Node works because JavaScript is operating system agnostic. The packages work were there is a VM.
C++ is usually compiled to native code.
A portable package system needs to provide support for all compilers and operating systems targeted by C++ compilers.
I want to be able to write code that does not depend on the convenience from some hobby developers to support AS/400 systems, for example.
C++ is usually compiled to native code.
A portable package system needs to provide support for all compilers and operating systems targeted by C++ compilers.
I want to be able to write code that does not depend on the convenience from some hobby developers to support AS/400 systems, for example.
Features aren't free.
I know it is irrelevant but still is interesting that one of the authors is Herb Sutter from Microsoft and that he chooses to propose an open source library from C instead of something coming from Microsoft.
Earlier discussion: https://news.ycombinator.com/item?id=7012329
Now that this principle seems to be abandoned why not go all the way and give us a full GUI toolkit? That would be so much more versatile than just a 2D drawing API.
I do not see much use for this except maybe making ISO C++ tutorials more exciting because your programs can show something else than console output.
And I mean Cairo is not a simple framebuffer, it is quite complex so why not make another step and give us a full GUI?
I read that the C++ guys want a standard library comparable to those of modern languages like Java, C#, Python etc. and they all come with GUI support.
Oh, and before they even think about adding graphics they should beef up the file system API. That is an actual issue. Right now every piece of crossplatform C/C++ includes a wrapper around platform specific APIs just to handle something as basic as getting a list of all files in a directory. They want to give us vector graphics rendering before that?