The original X graphics infrastructure was pretty badly broken, worse in some ways than the Windows API. X doesn't provide any color information about pixels, so it's actually not possible to know what colors different pixel values mean in different contexts. The only place you can be sure is when drawing to windows, and you can only generate intermediate color values for TrueColor windows.
The Windows API provides color information everywhere instead of pixel information; applications select the color for text, not the pixel values. Each pixmap contains information about what colors are represented by pixel values. This makes anti-aliasing quite possible and ensures that drawing in different contexts will generate consistent results.
If you're interested in bit-level pixel manipulation and complete control over the hardware colormap, then the core X rendering system is just the ticket. All of the limitations we're running into now were caused by compromises necessary to support commercially important applications in the era X was developed; now that hardware is 1000 times faster, we can emulate those tricks and still provide new capabilities.
However, it's even more important to realize that anti-aliased text is only a side-effect of the real benefits that Fontconfig and Xft bring to X.
The core protocol font handling has never been sufficient to support sophisticated text display. Every sufficiently powerful text rendering engine based on X has had to give up on the core fonts and implement text entirely in software. From TeX previewers to commercial publication systems, none of them gain any benefit from the hardware acceleration and network bandwidth optimizations of the core text primitives.
Furthermore, the core protocol font support cannot handle Unicode encoded fonts -- character codes are limited to 16 bits and Unicode requires 24. Even if you limit applications to the Unicode basic multilingual plane, the metrics information cannot be compressed as it is delivered over the wire or stored in Xlib making applications consume huge amounts of memory storing arrays full of zeros.
It is possible to kludge in AA text support for applications using the core protocol, but the results would be inconsistent on the screen and such support would not do anything to fix the worst limitations of core fonts.
As Xft2 now supports legacy X servers (without Render support), it is now reasonable to consider jettisoning any support for the core protocol fonts and switch to only supporting client-side fonts. Servers with Render will get good performance while servers not yet fixed will still work reasonably well.
The last step to take is to make all of the core bitmap fonts available as Unicode bitmap fonts through Fontconfig. The original plan was to make FreeType able to read the existing compressed bitmap font file formats that XFree86 uses. Those formats still suffer from the encoding assumptions that drove the massive space consumption in the core protocol metrics data, plus such fonts are consistently encoded in Unicode.
The new plan is to reencode the existing core fonts as TrueType fonts with only bitmaps for each glyph. The TrueType spec has explicit support for such fonts. Reencoding the fonts will significantly reduce the amount of disk space consumed by the fonts, eliminate all of the existing bitmap readers from the X server (and font server) and simultaneously make the fonts available to fontconfig/xft2-based applications.
Fontconfig is just a standalone library. The benefits of the system will only be realized as applications and other libraries take advantage of the capabilities.
The documentation included in this release is aimed at helping get applications ported to the library, not at helping get systems configured to use the library. That kind of documentation is needed, but it just hasn't been written yet.
Fontconfig has been released, but that's only relevant to application development right now.
The email is pretty technical, and doesn't give any idea of what their goals are. Is this just fiddling around for the fun of it, or are they thinking about introducing a new extension for mainstream use?
The Render extension is designed to replace the core X rendering model for general purpose applications. Its most visible effect today is the presence of anti-aliased text in Qt and Gtk+ 2.0 applications. However, the extension is more than just AA text; it provides a complete alternative to all of the existing rendering code using colors instead of pixel values and image compositing operators instead of boolean raster ops. It's a standard part of XFree86 today and future XFree86 releases will see the remaining parts of the extension fleshed out.
Render is designed to offer the minimal extension necessary to take advantage of modern hardware acceleration. For geometric objects, the work of breaking it into primitive shapes is done on the client side of the wire; the only thing the server does is draw trapezoids (or triangles). Render is based on image compositing so it provides translucent images as well as anti-aliased objects.
Once the extension had progressed to a point where anti-aliased text was possible, I got side tracked for a year dealing with the repercussions of client-side font support. I've recently drafted Carl to help get the graphics pieces finished. He and I implemented the fundamental geometric primitive (the trapezoid) a few months ago and now we're starting to build more complex shapes based on that. As those pieces are all done in the client, we're building the Xr and Xc libraries to provide them.
Xr and Xc will likely become a part of XFree86 once they're a bit further along in development. Carl has plans to port Qt to Xr to replace the graphics operations in that toolkit, we'll see if we can't get TrollTech to pick up those changes much as they picked up the Xft changes last year. Gtk+ already has a relatively sophisticated rendering engine; I'm not sure what part Xr/Xc have to play in that environment.
Tektronix developed a CIE-traceable colorspace
called 'TekHVC' which is designed to be perceptually linear along the three dimensions of hue, value and chroma (saturation).
XFree86 includes support for this colorspace in Xlib.
Why don't you concentrate on making sure the code works instead of aiming for some arbitrary patch size?
It's not arbitrary; I believe about 3/4 of the patch consist of unnecessary changes to code that shouldn't be executed in the Xft code path. Unfortunately, the internal abstractions for dealing with fonts are somewhat strained in the current code base, making this assertion testable but not easily verified by visual inspection.
While the ALS tutorials aren't free, the XFree86 workshops are -- you can spend half a day learning about Gtk+ or KDE programming or even the finer details of XFree86 configuration.
Fonts in the core protocol are in much worse shape than you think.
No advanced font information (like kerning tables)
No standard way for applications to provide their own fonts (PDF documents can embed fonts)
No support for vertical/diagonal escapements
The first problem would have required a significant new extension to codify the information available in current font files and still not solve the problem for future font file formats.
The second has traditionally been solved by creating an application-specific font server. What a kludge.
The third would be relatively easy to add to the existing core fonts, but would have required requests to transmit the new metric information.
Instead of a collection of ugly kludges, a new font mechanism was created placing the burden for locating and loading fonts squarely in the clients space while the X server handles what it does best -- drawing stuff on the screen. While this has been done in the context of the Render extension, the advantages for applications and toolkits is enormous. You should see Owen's changes to Pango using this stuff, he's able to directly access the font file information for composing glyphs together.
However, I agree that building a system which makes all font handling dependent on the toolkit is a bad idea. Towards this end, I've started on the Xft library which is the part of XFree86 designed to make font file access and glyph rasterization consistent across all X applications. Applications are free to go around Xft and do their own thing, but Xft is a thin enough layer and provides transparent access to the FreeType library which accesses the font files so I think this won't happen. I've built Xt applications, changed Tk and Qt and seen changes to GTK+ all using Xft. The results provide identical glyph images and a single location for font configuration throughout my desktop.
Probably the biggest advantage of the new system is that even if the current Xft library turns out to be irreparibly broken, we can pitch it on the scrap heap and start over without changing the X server. Extensions are hard to get propagated to every desktop; libraries can be shipped with applications and installed without trouble.
I added sub-pixel sampled text with very minor changes to the Render protocol; I can add sub-pixel positioned text without any changes at all. Glyphs are now rasterized on-demand, rather than having the entire font done when opened. This means using 10646 encodings is finally feasible within X; Qt, Tk, Java all use 10646 internally, now X can support that natively with no tremendous performance hit.
This can be viewed as the Unix lesson all over again; parts of the system which can easily be done outside of the "kernel" (X server) should probably be done there. In this case, the advantages are overwhelming.
Render is a new rendering model for the existing windowing model; we'll need another extension for a shiny new translucent windowing model. The extension for that will be simple, but the internal reorganization of the X server will be rather gory. Exactly the opposite of the Render extension where designing the extension was the fun part and implementing it was straightforward.
As for Render, it's got everything but separate alpha, polygons and image transformations. Put another way, it's got just enough to manage anti-aliased text and alpha compositing images.
Volunteers to create software renderers for triangles, trapezoids and image scaling are welcome to help. For the polygons, all that I want is code that takes a triangle (or trapezoid) and generates an A or ARGB map, that way I can layer the result over existing compositing acceleration.
The integration is not within XFree86, but of FreeType2 with our binary build and installation process. I should have started that a couple of weeks ago, but got caught with various other activities (like getting Qt working).
The XFree86 pieces are easy to do if FreeType2 is already installed; I expect the distro vendors to just make X require FreeType2 and ship a package for that as well.
ATI non-radeon/non-r128 changes for the Render extension are in XFree86 CVS. Dirk (Hohndel) and Linus both have laptops with Mach64 chips and complained about this little problem over the weekend (after the 4.0.2 code freeze). Ya just gotta get more recent bits.
FreeType 2.0.1 is sitting in XFree86 CVS, but it hasn't been included in the binary releases; there just wasn't time for the kind of integration and testing we would have liked. There aren't any license issues, FreeType2 uses a license which is compatible with the regular XFree86 license.
You need to build/install FreeType2 and then build/install the Xft library with FreeType2 support. Yes, this is a pain, but I expect Linux distros will include support by default.
Owen Taylor is hard at work getting Xft working with GTK+ 2.0, KDE has taken my Qt patches and incorporated them into their copy of the Qt tree. We're on our way to the magical land of anti-aliased text, and it's happening faster than I thought possible even a couple of months ago.
The Render extension will draw anti-aliased geometric objects as well; I just haven't gotten around to making those work yet. So much code, so little time...
The problem is actually that the hardware is doing compositing in linear value space instead of linear intensity space; this makes the "gray" areas of the text somewhat darker than they should be. Yes, it's possible to "do the right thing", but the accelerator doesn't. The other option is to adjust the DACs to compensate, but an awful lot of images destined for the screen already have gamma adjustments. You just can't win sometimes.
I'm certainly not promoting Qt over Gtk; I just wanted to get some samples that people could understand. Qt has the nice property that nearly all of the text rendering funneled down to a very small set of functions.
Talk about bang for the buck; two hours of hacking and I had a browser with anti-aliased text.
Gtk might be as easy, I just haven't looked. Plus, what I wanted was a browser and konqueror is pretty usable for basic browsing.
Yeah, it would be nice to handle gamma correctly, the problem is I haven't found a single graphics card which accelerates this operation. And doing it in software is really slow.
When hardware exists to accelerate this, we can add it in. Until then, there isn't much reason to make the X server CPU suffer through this.
I don't see how premultiplied alphas have any effect on this; Jim Blinn's alpha compositing articles describe using premultiplied alphas along with gamma-corrected compositing. It turns out you need to gamma correct the alpha component to make the images blend properly in any case. Go check out his 'Dirty Pixels' book, or the original article from November 1994 on this issue.
Re:This has been discussed on /. before
on
XFree & Rendering
·
· Score: 5
I went back and reread that comment again; the older article was from my initial call-to-arms and I had only started investigating what a few system would look like. With the help of comments like that, along with the assistance of lots of people, I found plenty of the ideas I'd put forth were wrong.
I disagree with your desire to keep the pixel values and the raster ops visible.
Yup, I was wrong on that one; raster ops are
replaced with compositing operators on color values.
It may be important to support "premultiplied" alpha compositing
Reading Jim Blinn's work along with Porter & Duff convinced me that premultiplied alpha was the "one true representation". You can still use non-premultiplied alphas if you like; the extension can be twisted to make that work, it's just that premultiplied alpha is the "obvious" way to do things.
I think you *should* use IEEE 32-bit numbers and put the "transformation" into the server.
Maybe someday, but I'm sticking with client-side tesselation for now. The number of 2D geometric objects drawn on the screen is miniscule today; maybe when we're drawing thousands it will make sense to move some of that across the wire. The neat part is that we can do that transparent to the application by tesselating in the library for servers which don't support the new stuff.
Having the transformation in the server is necessary for supporting font rasterizers and to take advantage of hardware acceleration for transforming images.
Font rasterization is now the client's problem. The extension does support affine transformations of images using fixed point coordinates; it's hard to imagine what floating point would add to that.
I do think paths should be in the server, because otherwise people will write wrapper libraries that will be slower than doing it in the server.
Given that hardware requires tesselation to triangles, I believe there isn't a significant performance advantage to doing that stage in the server. The key here is getting the huge hardware acceleration speed increase and not worrying to much the small speedups from shifting work from one general purpose CPU to another.
I do not want the Windoze-style 12-parameter call to sepecify a font,
By moving the rasterization to the client side, we can experiment with lots of different font naming schemes to see what we like; there is no longer a performance penalty for using non-"native" fonts.
I just wrote my first FreeType application today; that API seems much nicer than either Windows or XLFD.
Again, I STRONGLY disagree with the conventional wisdom that the only fast way to do images is to have the program know the details of the hardware.
With a color-based rendering model, it's now obvious how to transform color data from one format to another. The extension transparently converts image data.
Make a new type of "gc" that includes the damn window!
What's really sobering is that most 2D graphics systems designed since then use rasterops. Part of that is the conservative nature of system programmers, but it's also true that older systems just couldn't do compositing in software with any reasonable speed.
Re:Should the hard part be server or client-side?
on
XFree & Rendering
·
· Score: 2
When this level of abstraction becomes a performance problem on the client side, additional pieces can be added to the server. A significant feature of this extension is that missing pieces can be emulated on the client side during any transitional period and still gain at least some acceleration from the hardware.
Existing applications actually do quite a bit more work than you realize; they're frequently doing all of the rasterization and sending the resulting images to the server for display. This extension helps share that burder between client and server.
At less than 150 dpi, anti-aliasing text gives most people a headache when used in long passages. When your display has higher resolution than that, it actually helps readability.
Besides, image composition is for more than anti-aliasing; it forms the basis of an entirely new rendering model that replace 25 year old raster operations useful only on monochrome displays with operations that make sense in color.
Placing the primitive rendering routines inside the X server means I can use hardware acceleration. Plus, sending higher-level commands means X will work over a network again. Ever run Enlightenment across the net?
Along with CVS access, XFree86 has created new public mailing lists for development and support. Existing private lists will remain for NDA'd topics, but there aren't many of those anymore.
This is true, but you'll have quite a large number of pixels until the 23 bits bits of the mantissa (the 24'th bit is always one) aren't representing much sub-pixel positioning info.
The problem is when moving objects around the screen it's nice to have the same pixels drawn, but when using floating point, the precision depends on the magnitude of the value. This means you get different jaggies on the edges depending on where you draw something on the screen. Not pretty.
I conclude that 32-bit fixed point numbers are a better fit, and that providing 24 bits of integer part and 8 fractional gives a good tradeoff between rendering accuracy and an extended coordinate space.
SuSE is paying me to specify and implement this stuff. I'll have some demonstrations to show soon.
Nothing in this proposal will affect the way existing applications operate; X provides an extension mechanism which will be used for new functionality. Yes, this means that apps will need to change to get new functionality. Compatability bites.
This paper is being published as a part of the proceedings for this summers Usenix conference where I'll present a nice talk on the subject. They've requested that I make sure you all know who's publishing this.
Keith Packard XFree86 Core Team, SuSE Inc. keithp@xfree86.org
Slashdot Mirror
The original X graphics infrastructure was pretty badly broken, worse in some ways than the Windows API. X doesn't provide any color information about pixels, so it's actually not possible to know what colors different pixel values mean in different contexts. The only place you can be sure is when drawing to windows, and you can only generate intermediate color values for TrueColor windows.
The Windows API provides color information everywhere instead of pixel information; applications select the color for text, not the pixel values. Each pixmap contains information about what colors are represented by pixel values. This makes anti-aliasing quite possible and ensures that drawing in different contexts will generate consistent results.
If you're interested in bit-level pixel manipulation and complete control over the hardware colormap, then the core X rendering system is just the ticket. All of the limitations we're running into now were caused by compromises necessary to support commercially important applications in the era X was developed; now that hardware is 1000 times faster, we can emulate those tricks and still provide new capabilities.
However, it's even more important to realize that anti-aliased text is only a side-effect of the real benefits that Fontconfig and Xft bring to X. The core protocol font handling has never been sufficient to support sophisticated text display. Every sufficiently powerful text rendering engine based on X has had to give up on the core fonts and implement text entirely in software. From TeX previewers to commercial publication systems, none of them gain any benefit from the hardware acceleration and network bandwidth optimizations of the core text primitives.
Furthermore, the core protocol font support cannot handle Unicode encoded fonts -- character codes are limited to 16 bits and Unicode requires 24. Even if you limit applications to the Unicode basic multilingual plane, the metrics information cannot be compressed as it is delivered over the wire or stored in Xlib making applications consume huge amounts of memory storing arrays full of zeros.
It is possible to kludge in AA text support for applications using the core protocol, but the results would be inconsistent on the screen and such support would not do anything to fix the worst limitations of core fonts.
As Xft2 now supports legacy X servers (without Render support), it is now reasonable to consider jettisoning any support for the core protocol fonts and switch to only supporting client-side fonts. Servers with Render will get good performance while servers not yet fixed will still work reasonably well.
The last step to take is to make all of the core bitmap fonts available as Unicode bitmap fonts through Fontconfig. The original plan was to make FreeType able to read the existing compressed bitmap font file formats that XFree86 uses. Those formats still suffer from the encoding assumptions that drove the massive space consumption in the core protocol metrics data, plus such fonts are consistently encoded in Unicode.
The new plan is to reencode the existing core fonts as TrueType fonts with only bitmaps for each glyph. The TrueType spec has explicit support for such fonts. Reencoding the fonts will significantly reduce the amount of disk space consumed by the fonts, eliminate all of the existing bitmap readers from the X server (and font server) and simultaneously make the fonts available to fontconfig/xft2-based applications.
The documentation included in this release is aimed at helping get applications ported to the library, not at helping get systems configured to use the library. That kind of documentation is needed, but it just hasn't been written yet.
Fontconfig has been released, but that's only relevant to application development right now.
The Render extension is designed to replace the core X rendering model for general purpose applications. Its most visible effect today is the presence of anti-aliased text in Qt and Gtk+ 2.0 applications. However, the extension is more than just AA text; it provides a complete alternative to all of the existing rendering code using colors instead of pixel values and image compositing operators instead of boolean raster ops. It's a standard part of XFree86 today and future XFree86 releases will see the remaining parts of the extension fleshed out.
Render is designed to offer the minimal extension necessary to take advantage of modern hardware acceleration. For geometric objects, the work of breaking it into primitive shapes is done on the client side of the wire; the only thing the server does is draw trapezoids (or triangles). Render is based on image compositing so it provides translucent images as well as anti-aliased objects.
Once the extension had progressed to a point where anti-aliased text was possible, I got side tracked for a year dealing with the repercussions of client-side font support. I've recently drafted Carl to help get the graphics pieces finished. He and I implemented the fundamental geometric primitive (the trapezoid) a few months ago and now we're starting to build more complex shapes based on that. As those pieces are all done in the client, we're building the Xr and Xc libraries to provide them.
Xr and Xc will likely become a part of XFree86 once they're a bit further along in development. Carl has plans to port Qt to Xr to replace the graphics operations in that toolkit, we'll see if we can't get TrollTech to pick up those changes much as they picked up the Xft changes last year. Gtk+ already has a relatively sophisticated rendering engine; I'm not sure what part Xr/Xc have to play in that environment.
XFree86 includes support for this colorspace in Xlib.
It's not arbitrary; I believe about 3/4 of the patch consist of unnecessary changes to code that shouldn't be executed in the Xft code path. Unfortunately, the internal abstractions for dealing with fonts are somewhat strained in the current code base, making this assertion testable but not easily verified by visual inspection.
While the ALS tutorials aren't free, the XFree86 workshops are -- you can spend half a day learning about Gtk+ or KDE programming or even the finer details of XFree86 configuration.
The first problem would have required a significant new extension to codify the information available in current font files and still not solve the problem for future font file formats.
The second has traditionally been solved by creating an application-specific font server. What a kludge.
The third would be relatively easy to add to the existing core fonts, but would have required requests to transmit the new metric information.
Instead of a collection of ugly kludges, a new font mechanism was created placing the burden for locating and loading fonts squarely in the clients space while the X server handles what it does best -- drawing stuff on the screen. While this has been done in the context of the Render extension, the advantages for applications and toolkits is enormous. You should see Owen's changes to Pango using this stuff, he's able to directly access the font file information for composing glyphs together.
However, I agree that building a system which makes all font handling dependent on the toolkit is a bad idea. Towards this end, I've started on the Xft library which is the part of XFree86 designed to make font file access and glyph rasterization consistent across all X applications. Applications are free to go around Xft and do their own thing, but Xft is a thin enough layer and provides transparent access to the FreeType library which accesses the font files so I think this won't happen. I've built Xt applications, changed Tk and Qt and seen changes to GTK+ all using Xft. The results provide identical glyph images and a single location for font configuration throughout my desktop.
Probably the biggest advantage of the new system is that even if the current Xft library turns out to be irreparibly broken, we can pitch it on the scrap heap and start over without changing the X server. Extensions are hard to get propagated to every desktop; libraries can be shipped with applications and installed without trouble.
I added sub-pixel sampled text with very minor changes to the Render protocol; I can add sub-pixel positioned text without any changes at all. Glyphs are now rasterized on-demand, rather than having the entire font done when opened. This means using 10646 encodings is finally feasible within X; Qt, Tk, Java all use 10646 internally, now X can support that natively with no tremendous performance hit.
This can be viewed as the Unix lesson all over again; parts of the system which can easily be done outside of the "kernel" (X server) should probably be done there. In this case, the advantages are overwhelming.
(or just maybe bgr) resource so you get sub-pixel sampled text.
As for Render, it's got everything but separate alpha, polygons and image transformations. Put another way, it's got just enough to manage anti-aliased text and alpha compositing images.
Volunteers to create software renderers for triangles, trapezoids and image scaling are welcome to help. For the polygons, all that I want is code that takes a triangle (or trapezoid) and generates an A or ARGB map, that way I can layer the result over existing compositing acceleration.
The XFree86 pieces are easy to do if FreeType2 is already installed; I expect the distro vendors to just make X require FreeType2 and ship a package for that as well.
I know at least one Linux vendor will.
ATI non-radeon/non-r128 changes for the Render extension are in XFree86 CVS. Dirk (Hohndel) and Linus both have laptops with Mach64 chips and complained about this little problem over the weekend (after the 4.0.2 code freeze). Ya just gotta get more recent bits.
You need to build/install FreeType2 and then build/install the Xft library with FreeType2 support. Yes, this is a pain, but I expect Linux distros will include support by default.
Owen Taylor is hard at work getting Xft working with GTK+ 2.0, KDE has taken my Qt patches and incorporated them into their copy of the Qt tree. We're on our way to the magical land of anti-aliased text, and it's happening faster than I thought possible even a couple of months ago.
The Render extension will draw anti-aliased geometric objects as well; I just haven't gotten around to making those work yet. So much code, so little time...
The problem is actually that the hardware is doing compositing in linear value space instead of linear intensity space; this makes the "gray" areas of the text somewhat darker than they should be. Yes, it's possible to "do the right thing", but the accelerator doesn't. The other option is to adjust the DACs to compensate, but an awful lot of images destined for the screen already have gamma adjustments. You just can't win sometimes.
Talk about bang for the buck; two hours of hacking and I had a browser with anti-aliased text.
Gtk might be as easy, I just haven't looked. Plus, what I wanted was a browser and konqueror is pretty usable for basic browsing.
When hardware exists to accelerate this, we can add it in. Until then, there isn't much reason to make the X server CPU suffer through this.
I don't see how premultiplied alphas have any effect on this; Jim Blinn's alpha compositing articles describe using premultiplied alphas along with gamma-corrected compositing. It turns out you need to gamma correct the alpha component to make the images blend properly in any case. Go check out his 'Dirty Pixels' book, or the original article from November 1994 on this issue.
I disagree with your desire to keep the pixel values and the raster ops visible.
Yup, I was wrong on that one; raster ops are replaced with compositing operators on color values.
It may be important to support "premultiplied" alpha compositing
Reading Jim Blinn's work along with Porter & Duff convinced me that premultiplied alpha was the "one true representation". You can still use non-premultiplied alphas if you like; the extension can be twisted to make that work, it's just that premultiplied alpha is the "obvious" way to do things.
I think you *should* use IEEE 32-bit numbers and put the "transformation" into the server.
Maybe someday, but I'm sticking with client-side tesselation for now. The number of 2D geometric objects drawn on the screen is miniscule today; maybe when we're drawing thousands it will make sense to move some of that across the wire. The neat part is that we can do that transparent to the application by tesselating in the library for servers which don't support the new stuff.
Having the transformation in the server is necessary for supporting font rasterizers and to take advantage of hardware acceleration for transforming images.
Font rasterization is now the client's problem. The extension does support affine transformations of images using fixed point coordinates; it's hard to imagine what floating point would add to that.
I do think paths should be in the server, because otherwise people will write wrapper libraries that will be slower than doing it in the server.
Given that hardware requires tesselation to triangles, I believe there isn't a significant performance advantage to doing that stage in the server. The key here is getting the huge hardware acceleration speed increase and not worrying to much the small speedups from shifting work from one general purpose CPU to another.
I do not want the Windoze-style 12-parameter call to sepecify a font,
By moving the rasterization to the client side, we can experiment with lots of different font naming schemes to see what we like; there is no longer a performance penalty for using non-"native" fonts.
I just wrote my first FreeType application today; that API seems much nicer than either Windows or XLFD.
Again, I STRONGLY disagree with the conventional wisdom that the only fast way to do images is to have the program know the details of the hardware.
With a color-based rendering model, it's now obvious how to transform color data from one format to another. The extension transparently converts image data.
Make a new type of "gc" that includes the damn window!
It's called a Picture.
What's really sobering is that most 2D graphics systems designed since then use rasterops. Part of that is the conservative nature of system programmers, but it's also true that older systems just couldn't do compositing in software with any reasonable speed.
Existing applications actually do quite a bit more work than you realize; they're frequently doing all of the rasterization and sending the resulting images to the server for display. This extension helps share that burder between client and server.
Besides, image composition is for more than anti-aliasing; it forms the basis of an entirely new rendering model that replace 25 year old raster operations useful only on monochrome displays with operations that make sense in color.
Placing the primitive rendering routines inside the X server means I can use hardware acceleration. Plus, sending higher-level commands means X will work over a network again. Ever run Enlightenment across the net?
Along with CVS access, XFree86 has created new public mailing lists for development and support. Existing private lists will remain for NDA'd topics, but there aren't many of those anymore.
The problem is when moving objects around the screen it's nice to have the same pixels drawn, but when using floating point, the precision depends on the magnitude of the value. This means you get different jaggies on the edges depending on where you draw something on the screen. Not pretty.
I conclude that 32-bit fixed point numbers are a better fit, and that providing 24 bits of integer part and 8 fractional gives a good tradeoff between rendering accuracy and an extended coordinate space.
SuSE is paying me to specify and implement this stuff. I'll have some demonstrations to show soon.
Nothing in this proposal will affect the way existing applications operate; X provides an extension mechanism which will be used for new functionality. Yes, this means that apps will need to change to get new functionality. Compatability bites.
This paper is being published as a part of the proceedings for this summers Usenix conference where I'll present a nice talk on the subject. They've requested that I make sure you all know who's publishing this.
Keith Packard
XFree86 Core Team, SuSE Inc.
keithp@xfree86.org