Slashdot Mirror

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.

ed Hat doesn't include anything that could potentially infringe upon patents. The reason why fonts in Windows and OS X look good is because a lot of man-hours went into developing them, so companies like Microsoft got a patent for things like ClearType. That said, if you need better Linux fonts, look into Infinality.

All font rendering on Linux sucks. This includes Infinality. You don't notice it much on phones or tablets, because of the high DPI, but with a standard low-DPI monitor or TV set, it's painful.

The only completely open-source solution I've seen that provides acceptable results on a low-DPI screen is Anti-Grain Geometry. But as far as I can tell, this was never incorporated into any actual distribution, and has remained just a tech demo.

RGB is not even close to most visible colors. The overall graph here shows the full visible color gamut, and RGB is the small triangle inside it: http://www.antigrain.com/doc/introduction/cie_1931.jpg

RGB is a small subset of the visible color gamut. It's the triangle in this graph: http://www.antigrain.com/doc/introduction/cie_1931.jpg

http://www.antigrain.com/research/font_rasterization/index.html

It's even worse than that: the horrible legacy of hacks that windows uses pretty much guarantees that apps will always render horribly in anything by the default PPI. Their rounding "tricks" cause the text to scale inconsistently, as it's snapping individual letters to horizontal pixel boundaries. (err, it's more complicated than that; see the above link for a very well written discussion of the problem, and a very nice discussion of font rendering issues in general)

As long as windows apps scale badly, there's a strong incentive to *not* produce a high-PPI display; customers would likely blame the monitor for "screwing up windows".

One thing that hasn't been mentioned yet is that font rendering on Linux is utterly horrible.

A couple years back I tried several Linux distributions. Looking at the browser window hurt my eyes – horribly blurry and aliased compared to the ClearType rendering in Windows. I downloaded and installed the MS corefonts and it didn't help. I even tried recompiling TrueType to support RGB subpixel rendering (which is not included by default!) and it still looked terrible compared to Windows. There doesn't seem to be any way to get TrueType to do RGB subpixel smoothing and yet for hinting to respect pixel boundaries the way that ClearType does. Instead it's all a blurry mess. Anti-Grain Geometry has some very promising open-source experimentation on font rendering, but sadly, so far it doesn't seem to be put into production in Linux or anything else.

Its why I said
http://www.tkzinc.org/
http://www.wxart2d.org/
http://www.box2d.org/

There is also
http://antigrain.com/

Heck, depending on his real requirements, a branded copy of firefox3 with plain canvas (or WebGL) might be enough (with jQueryUI/YUI/Google Web Toolkit)

Safari. The first Windows release even included Quartz rendering until it was removed due to complaints from Windows users.

How would you say AGG compares to Cairo?

The author of Antigrain is a perfectionist.

Just look here - http://www.antigrain.com/svg/index.html . And version 2.4 is under BSD license.

Instead, it has an auto-hinting system, which works just great when you have anti-aliasing or subpixel rendering turned on.

Unfortunately, no, it does not. Subpixel font smoothing has been a long standing issue in Linux (and other systems that use FreeType) for me, as, unfortunately, it's nowhere near as good as Microsoft's ClearType. I recall there had been some patches for FT in more recent releases of Ubuntu that improve things (but might violate patents?), but the occasional letter still has a line so blurred out that it's nearly invisible (normally diagonal lines in "k" and "x" suffer), or another line that's way too thick.

I understand the problem with the patents, but there are alternative methods which are much better than anything we have in Linux at the moment, and, IMO, better than what either Microsoft or Apple has to offer.

...and probably irrelevant in the longer term.

This is not the first time this has happened. GL2 was also supposed to be a cleanup, but turned out to be anything but. This latest fiasco is more significant as a failure of governance than of technology. All the right ideas were there; they were published in some detail over a year ago in the Pipeline newsletters. But the ARB very obviously a) can't agree to get anything meaningful done, and b) now has subzero credibility with developers. It's not coming back from that.

So yes, I think cutting-edge cross-platform 3D is dead for the next 2-3 years. Let's face it, it was never exactly healthy. It's not the end of the world. Linux share is currently growing mostly at the low end, netbooks etc, while the Mac seems to be thriving despite the fact that Apple doesn't give a flying fsck about gaming and never has.

Fast forward a couple of years, though, and things like Larrabee will be hitting the market; embarrassingly parallel hardware that can be programmed with standard languages and tools. The API's role as gatekeeper of functionality will be gone. And suddenly, 3D rendering libs can be written by anyone with the time and expertise, without having to go through Microsoft or the ARB or NV or AMD/ATi or Intel or anyone. Experimentation, competition, cross-fertilization, evolution. Remember Outcast's voxel engine? Seen things like Anti-Grain? This will happen.

(Or, yes, people could just reimplement the DXwhatever API directly, but that would be a little disappointing.)

Today was not a good day, by any stretch of the imagination. But it's not the end.

it's a consequence of aligning edges with the nearest pixel. You can either have blurry fonts with precise spacing or clear fonts with the sort of sub-pixel spacing variations you describe.

Or also you could have both, but that would require rewriting the font rendering engine, as the GP suggested.

To make this more slashdot worthy, I really recommend the url below to read about font rendering on varoust platform and why only mac gets it right.

http://antigrain.com/research/font_rasterization/index.html

Apple Windows and Linux all have pretty awful sub pixel rendering. Ideally you want a solution that lets you tweak the size of a font infinitely: you should be able to make any word or any letter any size what-so-ever. To my knowledge none of the common sub-pixel rendering systems provide this level of fine grained control.

The only good sub pixel rendering I've ever seen is well explained on Anti-Grain's Text Rendering page. This page explains how bad most sub-pixel rendering is, and how much better their open source method is.

their idea of text smoothing is to apply Gaussian blur to it and smudge it a bit. They do not use advanced manipulation like clear type does

LOL!! Incorrect. The Mac uses subpixel anti-aliasing just as ClearType does, but it uses a slightly different hinting algorithm. Of the two, the Apple way is probably better subjectively for most people. More info here: Font smoothing, anti-aliasing, and sub-pixel rendering and here: Texts Rasterization Exposures

"We don't really know how to accelerate all sorts of rendering operations (glyph rendering is proving to be particularly difficult at the moment, for example)"

Linux needs font help

Use the GPU to do font rendering.

The problem with flash and great projects like gnash is that it will never be a full freely distributable implementation as long as we have draconian patent laws. Components such as flash video are patented. Likewise the silverlight won't be complete in a free distribution.

That's changing. The latest beta of the Flashplayer supports h.264 video with AAC audio in an mp4 container. Mozilla Tamarin is the VM introduced in Flashplayer 9 and targeted by everything ActionScript 3 (like Flash CS3 can and Flex 2 always does, as well as the to-be-Free Flex 3 SDK). It's much faster than the one in previous versions, so developers will use that one increasingly. For video content, publishers can choose between an open standard with free tools, or a proprietary expensive one, so what do you think will they do?
That's two major building blocks right there. The rest of the format is basically just tags that define, transform and place sprites. Gnash already does a good job at that. Some pieces in the Adobe Flashplayer's renderer are patented, but there are excellent libraries for that. Of course, the API would have to be implemented (the flash.* packages, mx.* builds on that and will be part of the Flex 3 SDK).
The SWF specification isn't the problem, there are some Free tools out there that already have very good support of SWF and related protocols. With the Flex 3 SDK, there will even be one from Adobe you can legally look at (IANAL).

You have to understand that Gnash tries to support existing content first. That is a big task, and I wish them well. But if you leave out legacy support and focus on what Adobe's current tools put out, it gets much easier. Grossly simplified, there's the VM, there are readers, renderers and codecs, add glue.

I use generic programmming and metaprogramming very often in C++. I does pay off. See http://www.antigrain.com/ for an example.

Many people use templates for generic programming and metaprogramming; that doesn't prove that they are actually useful or that it "pays off" compared to simpler constructs, since pretty much nobody ever bothers making the comparison. Given that most of those libraries, even high performance commercial libraries, have been written without such constructs, it's reasonable to postulate that it doesn't.

Furthermore, being able to do it in C++ doesn't mean C++ "supports" it. Generic programming and metaprogramming in C++ is very limited in what you can do relative to languages that were designed with support for those features, it taxes compilers to the limit, it uses constructs intended for completely different purposes, and it gives lousy compiler diagnostics to users.

C++ does not "support" functional programming, generic programming, object oriented programming, or even metaprogramming; if you invest a lot of work and effort, you can approximate small subsets of these programming styles in C++, badly. And I have yet to see that it's worth the effort; the best and most common use of C++ still seems to be as a slightly better C.

I use generic programmming and metaprogramming very often in C++. I does pay off. See http://www.antigrain.com/ for an example.

I agree that without templates C++ has no real advantages though.

In a similar vein:

I'm still trying to figure out why the Anti-Grain Geometry library went from BSD-like to GPL a few months ago with no code change. http://www.antigrain.com/

I haven't found any information on why the switch occurred and the author doesn't appear to have explained his motivations. I find myself working on a project in which I can employ 2.4, but I can't upgrade to 2.5 due to the licensing restriction, so I must either fork and maintain what I am using from 2.4 or abandon the library.

The bait-and-switch nature of the change is somewhat troubling to me, though I admit the principal author of AGG doesn't appear to be gagging inquiries like in the SQLLedger/LedgerSMB case.

I brought up my laptop to say that my laptop runs circles around an OS X workstation. I forgot to write workstation at the end. The OS X laptops really aren't meant for workstation-level use.

Logically, windows are the central aspect of modern UIs. But in terms of computing power, windows aren't the major burden. It's the stuff *inside* the windows that takes a lot of CPU to draw. Let me see if I can explain the model:

OS X without Quartz Extreme --
Each application has a chunk of memory for it's window. It draws, via the CPU, into this memory using Quartz 2D. The graphics card is largely used for quickly drawing bitmaps. It does not accelerate drawing of any of Quartz2D's vaunted vector graphics. Quartz Compositor then takes all of these windows, and with the CPU, does the shadow and transparency effects, and draws the final result into the screen.

OS X with Quartz Extreme --
Each application has a chunk of memory for its window. It draws, via the CPU, into this memory using Quartz 2D. The graphics card is largely used for quickly drawing bitmaps. It does not accelerate drawing of any of Quartz2D's vaunted vector graphics. Quartz Compositor then takes all of these windows, turns them into textures. Then it sends them to the graphics card, which does the transparency and shadow effects, and draws the results onto the screen.

Now, Quartz Extreme is a big improvement in OS X, because previously, it was the CPU that had to recomposit all the windows everytime one of them changed. However, in the computing world overall, it's not really a big deal. Other window systems don't do the compositing step (which is useful only for window-transparency and shadows) so something like Quartz Extreme wouldn't have any effect at all. Now, Longhorn and EVAS (Enlightenment 17) are actually hardware accelerated desktops. In EVAS, everything is done via the GPU. Take a look at the AGG-2 page. Look at the screenshots. In EVAS or Longhorn, those drawings could be accelerated via OpenGL (which was designed for vector graphics!) In OS X, they would have to be done via Quartz 2D on the CPU.