Where's my post?

Where’s my post?

Oh ic what I’ve just suggested is something that could make OpenGL look better? And yeah Direct3D 11 got it first so lets wait for a few years before adding it to the dead API. Remember when I suggested instancing and geometry shaders? Now they are there :slight_smile:

I repost here:

glFont(fontName, “TimesNewRoman”) :smiley:
glFonti(fontName, 12, GL_FONT_STYLE_BOLD, …) :smiley:

glDrawText2D(fontName, “Hello World!”, x, y, rotation);


Remember when I suggested instancing and geometry shaders?

Yes, and I remember the fifty other suggestions you made that aren’t there. That doesn’t exactly make you Cassandra.

And instancing wasn’t a hard prediction, since D3D had it in D3D9.

glFont(fontName, "TimesNewRoman") laugh
glFonti(fontName, 12, GL_FONT_STYLE_BOLD, ...) laugh

glDrawText2D(fontName, "Hello World!", x, y, rotation);

If this was the original content of your post, I can understand why the Aether decided to consume it rather than make these forums less useful by allowing its presence.

What amazes me is just how little you really understand about what you’re asking for here. Just how much stuff would have to happen to make these 3 commands not only possible, but possible to the extent that actual people would want them.

So, you are suggesting that IHVs introduce the following into their drivers:

1: The ability to interface with some kind of global font repository. This is necessary to translate things like “TimesNewRoman” and “GL_FONT_STYLE_BOLD” into an actual file containing that particular typeface.

Note: not all operating systems have global font repositories. Also, OpenGL is not supposed to be talking directly to OS’s like that; this is why commands like swapping the default framebuffer are WGL/GLX/AGL/EGL calls.

2: The ability to parse through the myriad of font formats and rasterize these glyphs into images on the screen. This is not a trivial undertaking. Fortunately, there’s an entire open-source library (FreeType2) dedicated to doing this, and it uses a reasonably liberal license.

That being said, rasterization has issues as well. Many good glyph rasterization algorithms are patented. While FT2 does support them, IHVs would also have to license those algorithms from the patent holders. If they can’t, then they have to use crappier glyph rasterization algorithms. And licenses would essentially be a dollar value added to every GPU they make (corresponding to every driver they use).

3: Text layout. You cannot begin to fathom the complexity here. It starts with the very string you give this “glDrawText2D” function. Is that string in UTF-8? Shouldn’t it also support UTF-16, which is a common Unicode encoding? Or are we going to render this functionality of zero value to anyone not writing in English by saying that it’s ASCII-only?

If you’re wanting useful text rendering support, then some from of Unicode needs to be supported. UNIX’s tend to prefer UTF-8 strings, while Windows users are used to UTF-16 strings (since those are the Unicode encoding that each OS supports). Picking one is essentially making the other less useful.

And that hasn’t even begun to scratch the surface of text layout. Are you writing in left-to-right, top-to-bottom style like English and most western languages? Are you writing right-to-left, top-to-bottom like Hebrew or Arabic? And what about spans of text that have left-to-right layout within an Arabic string (things like numbers are written left-to-right in Arabic)?

Speaking of Arabic, how do you deal with the fact that Unicode codepoints do not have a 1:1 mapping to glyphs? You have to pick glyphs based on the neighboring codepoints. There is a fairly complicated algorithm for doing this.

And then there’s Chinese. Or rather, CJK unification. A Unicode string that maps certain CJK characters need to be rendered with different fonts based on whether the text is Japanese, Chinese, or old-style Korean.

And these are just the things that I, as someone who has a passing familiarity with text formatting, know about. There can easily be more things that I don’t know about, since I’m not an expert.

4: Lastly, how exactly do you decide what the X and Y components mean? First, what space are they in? Clip-space? Window-space? Viewport-space? Does this command generate triangles that are passed through a vertex shader? How does this generate values for a fragment shader? Does a fragment shader even get executed?

In short: what you have suggested is about as complicated as writing a GLSL compiler. And we’ve already seen how good IHVs are at that.

And even those arguments ignore the simple and obvious fact that a low-level graphics API has no business rendering text. The next thing you’ll be asking for is glBSP, glPortal, and glHeightMap.

Well not exactly that complicated what I asked for. Something like Direct3D9 D3DX text rendering will suffice, and no need for unicode support at this time.

I was thinking Glu should be adopted by the Khronos so that any functionality IHVs should not implement, the group can take care of it.

Compatibility profile functions should have been moved to Glu instead, and implemented on top of a minimal GL 3 core.

Something like Direct3D9 D3DX text rendering will suffice, and no need for unicode support at this time.

Then go write it. If you think it should exist, write it.

Just be advised that without “unicode support”, it will have at best limited utility. The days when people put up with ASCII-only are coming to an end.

I was thinking Glu should be adopted by the Khronos so that any functionality IHVs should not implement, the group can take care of it.

We’ve had this discussion before: the ARB does not have programmers. They could contract the work out to someone, but it would be nothing more than just another library written on top of OpenGL. It would not be part of OpenGL.

And that’s what this part of the forum is for: suggests for OpenGL, not other libraries.

Compatibility profile functions should have been moved to Glu instead, and implemented on top of a minimal GL 3 core.

The point of compatibility was to make old code compatible. Having the people using older code alter their entire codebases (changing gl to glu for the appropriate functions). would be counterproductive to this end.

First up, these aren’t really part of D3D either. D3DX is an extensions utility library, similar in basic concept to a mixture of GLU, wgl and a few other bits and pieces. What you might see as being “font support in D3D” is a whole load of code that translates into lower-level D3D calls to handle creation of textures, vertex buffers, draw calls, etc. You can run a D3D app that uses this interface in PIX and examine what’s happening behind the scenes if you wish. It’s perfectly possible to write a fully functioning D3D program without even touching D3DX at all. D3DX is not D3D, so your initial basis for your argument is invalid.

Second up, OpenGL has had this for a long long time - in or around 15 years - in the form of wgl extensions. Yes, they’re platform-specific, but then so are fonts, which brings me to point 3.

Third up, fonts are platform-specific. Font formats are platform-specific, font handling is platform-specific, font terminology is platform-specific. It’s by accident rather than by design that there’s actually a lot in common between them, but it could have easily turned out the other way, and may just as easily go the other way if a new iteration of an OS does things differently.

At this stage I predict that you’re going to throw FreeType at me, but remember - FreeType is an additional library. It’s not part of the OS, it’s not part of how the OS handles fonts. I’m failing to see much difference in concept between this case and - for example - image formats. That brings me to point 4.

Fourth up, OpenGL has always defined itself as “a software interface to graphics hardware”. This is page 1, line 1 of any OpenGL book. OpenGL philosophy is that it does not define image formats, it does not define model formats, it does not define window-system interaction; it’s in keeping with this philosophy that it does not define anything to do with fonts either.

So in a nutshell, while it was probably worth discussing, it’s really not appropriate for inclusion in OpenGL IMO. Just use a font library that can interface with OpenGL instead.