> >I've been following the list since the very begining so I know that > >the feature list of the first card have been more-or-less agreed upon > >a long time ago. However, I don't remeber that accelerated vector > >graphics has ever come in the discussion, which is strange given the > >"Desktop User" target of the first graphics card. > > Vector graphics are just lines and other geometric primitives, > usually with the added meaning these days that they can be > specified, scaled, and rotated in whatever coordinate system > the programmer wants instead of being limited to integer > pixel coords. Since the OGD is designed to run OpenGL, it > has this capability. (Most people think of OpenGL as a 3D > API, but it works perfectly well for 2D with non-perspective > transformations and Z = 0.) > There is no doubt that OpenGL has the capability to handle 2D graphics, and indeed there are already widget toolkits based on OpenGL, as the one that is used by Blender, if I'm not mistaken. I also think as the majority of this list that using the general case (3D and OpenGL) to deal with the specific 2D case is a good design choice.
However, OpenGL has its limitations when it comes to display some images with numerous sharp discontinuities, like texts or vector graphics. Every OpenGL newbie knows that displaying a few words in OpenGL is not trivial, and the solutions used are often sub-optimal. Among these, I'm aware of two solutions. The first one is to use a font texture, which is a bitmap representation that does not scale well when zooming. The second one is to do a piecewise linearisation of the glyph curves and display it as a set of polygones, but this has the drawback of artificially increasing the vertex workload. Furthermore, with these techniques, anti-aliasing is either impractical or costly. It is however very important feature for a proper font display. What the paper proposes is a generalisation of the OpenGL bitmap textures to a vector texture, which is a space efficient and computationally pertinent way of storing and displaying anti-aliased vector graphics such as glyphs, but not only (think of anti-aliased lines, curves and textured polygones among other possibilities). To my mind, this does not put at stake the OpenGL design choice, but on the contrary reinforces it. > >In these days of ttf-fonts-everywhere and Cairoification of desktops, > >can't we see accelerated vector graphics as a potential attractive > >feature to implement in the board ? Even more convincing, it seems that Xgl > >is now using this technique (via shaders ?) for its fonts rendering > >http://www.freedesktop.org/wiki/Software/Xgl > > Xgl is X Windows implemented on top of the OpenGL API, so the > OGD will happily run Xgl. > Yes and no, since appearently Xgl uses Vector Texture Maps via shaders to implement font rendering efficiently. This solution will be impractical on OGD since, as you said, OGD will not be a programmable GPU. A fallback will be probably be used instead. I think it would be interensting to know why the Xgl guys bothered to implement the Vector Texture Maps. > >As far as I understand, one of the main advantages of the solution > >proposed in the paper is that it integrates perfectly in a 3D GPU > >design. It can even provide regular OpenGl anti-aliased lines and > >polygones. The proposal has already been successfully implemented in > >a GPU, and the hardware part already seem to provide the necessary > >functionalities. There is also > >some related code in GLSL here : > >http://staffwww.itn.liu.se/~stegu/GLSL-conics/ > > Moving from the general to the paper, the OGD won't be a > programmable GPU, so cannot use vector texture maps or other > neat stuff that needs GLSL. Transversal simply don't have > the resources to build a complete programmable GPU on the > first iteration. > Vector texture maps is not only neat stuff, but also one targetted to OGC market : desktop users. This is why I suggest to implement it directly in hardware. I was only quoting the GLSL code as a reference for this task. I want to quote again the original GLSL-independant description, since it disapeared form the selected mail quotations : www.loria.fr/~levy/publications/papers/2005/VTM/vtm.pdf Cheers, Robin _______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
