XFree & Rendering 72
Keith Packard from SuSE (and a member of the XFree core team) is doing A New Rendering System For X. You can check here to see what he has done so far. Looks great! Help is needed, so if you can give a hand - please do. Keith is going to show some more rendering stuff on LWE.
Re:Should the hard part be server or client-side? (Score:1)
O, wrong, i'm an idiot, i now see what you meant, and you were right, and a smart answer was already submitted... I'll stick to reading now :-(
Easier version (Score:1)
Re:Looks intersting (Score:2)
Eh? Whether you can cut and paste stuff is independent of how it's rendered on the screen; cut and paste is largely done by the client(s), with the only server involvement typically being the use of the selections such as the primary and clipboard selection.
...but they'll only use it if and when either the application, or the toolkit it uses, is changed to use the rendering extension, unless they somehow bury that stuff in Xlib itself, which I have the impression they're not doing (and I have the impression might not be doable).
Re:Easier version (Score:1)
It's still in development, and there are no programs (except for the examples) that actually USE this new rendering system.
But once there are (or, more likely, GTK+/QT add support), I'm sure that the distros will include it
Re:Looks intersting (Score:1)
Re:Dynamic resizing of the X display (Score:2)
However, this shouldn't be a big problem, since, for the most part, only the window manager needs to know. The X server could send an "physical screen size changed" event to the window manager and the window manager would rearrange the windows to fit onto the new screen size. If the X server disables edge scrolling, the effect is the same as on Windows; whether the off screen pixels are still stored or not is not user visible in any important way.
Windows actually has a lot more of those kinds of "legacy" assumptions built in; for example, many Windows applications cannot conceive of resizing or moving their main window while a modal dialog is up or while they are busy computing. I'll take the fixed screen size assumption over that any day...
Re:Microsoft's GDI+ (Score:2)
Re:It needs to handle gamma (Score:2)
(F^G*A^(G-1)+B^G*(1-A))^(1/G)
And it does seem that without hardware support this can be really slow. It might be best to do whatever the hardware does as fast as possible, but not define the exact results of alpha compositing so that such changes are doable.
It also appears that your "mask" is in fact a non-premultiplied alpha channel. Thus both are provided by the design.
I am still really confused by the design, though. Is a "picture" in effect a graphics context?
I also want to state why I feel it is very important that the extension do everything with a single graphics context. Many people have said "use GLX" or "use DPS". But I need the ability to write a library that does something like take a gc and set the foreground color to a special value. This is not possible when there are 3 (or 4) different types of gc.
An alternative is to add the missing stuff to GLX: add antialisaed fonts, clipping, and perhaps a few other things to OpenGL and it can be used for all the graphics, and only a single gc object needs to be worried about (though I would also like the ability to switch the gc between windows).
Re:Looks intersting (Score:2)
If that's what he's saying, then he's very confused.
On the X server there's no "text" to be selected on the clipboard no matter how you rendered it on the screen - there's just pixels. There is no guarantee that the text characters sent over the wire in a "draw text" request are somehow "remembered" by the X server, and, even if the X server happens to remember them, there's no X request to fetch those characters back (you can perhaps read the pixels back, but not the text).
As I said at least once, selection is done on the client, though, so whether the server was told to put pixels on the screen by a "draw text" request or was just handed the pixels by the client is irrelevant.
The client has to keep a copy of the text, which it can do regardless of whether it renders that text on the screen by sending the X server one or more "draw text" requests or by converting it to pixels internally and sending those pixels over the wire; that copy is what's selected in the clipboard (or, rather, what's supplied if somebody asks the client for the contents of the clipboard).
Re:Whoa cool. (Score:2)
Well, first of all, I don't know whether there's a universal consensus that the X Rendering Extension constitutes "[putting] lipstick on a pig"; the fact that a person, or even that many people, happen to believe so doesn't ipso facto make it so.
Second of all, "help[ing] the Berlin Consortium" doesn't help all the zillions of X-based applications and toolkits and... that are our there now; to quote the Berlin Vs. X. FAQ [berlin-consortium.org]:
Even if, when completed, Berlin is superior even to X with the Rendering Extension (which might well be the case), if the X Rendering Extension comes out significantly earlier than a version of Berlin sufficient to replace X, dumping the X Rendering Extension work and going off to work on Berlin may be a case of "the best is the enemy of the good".
Maybe Berlin would come out sooner if everybody quit working on X - but
I think that both the X Rendering Extension and Berlin are interesting projects; I'm unconvinced that it'd be a Good Thing if either were abandoned, as, if nothing else, they mean that people are thinking about More Than One Way Of Doing Things, which could lead to a group working on project A picking up Good Ideas from the group working on project B.
Re:Dynamic resizing of the X display (Score:2)
It is true that programs will not know the screen size correctly unless they pay attention to this event. But this is probably not going to break things too badly. Programs just use it to set maximum window size and to force menus/etc to be on-screen. In many cases the window manager will override them anyways.
Windows window-Alpha-Blending :) (Score:1)
Check out this screenshot [unfix.org] for a cool example. Unfortunatly I didn't have a Famke Janssen background ready, but Gail Porter will do
Re:This is berlin without the complications? (Score:2)
Well, in the Berlin FAQ [berlin-consortium.org], they say:
so they at least realize that it will probably ultimately need to be X-compatible - there are just too many X applications out there for them to treat X as irrelevant.
It may not have X support now, but, in that FAQ, they quite explicitly say that it's not ready for prime time yet:
so the fact that it currently lacks X compatibility may not really mean that much.
Re:X12? (Score:1)
That depends on what you mean by a "standard X11 setup." AFAIK, the "Shape" extension to X11 is pretty darn common, so in effect that would be a de facto standard part of an X setup. In short, a so-called "standard" X setup could very well actually be plain X + several common extensions.
Re:Microsoft's GDI+ (Score:1)
Re:Looks intersting (Score:4)
Are you asserting here that anti-aliased text would somehow be stored differently in the clipboard than non-anti-aliased text? I have yet to see any indication that it would have to be; if you're cutting from a word processor, the character sizes and fonts might be available through the clipboard when using a format that includes it (although it'd probably also be made available as Boring ASCII Text, or Boring ISO 8859/n Text, or Boring JIS Text, or Boring UTF-8 Text, or...), but I wouldn't see an indication of whether the text happened to be rendered anti-aliased or not being made available via the clipboard.
(The fact that the text might have been rendered on the screen by sending raw pixels rather than sending text is irrelevant, given that, as I said, the client handles the cutting and pasting, not the server, and the client has the characters available.)
...which, of course, doesn't mean that they necessarily will use them, unless they're modified to use them, or the toolkit they use is modified to use them.
Re:This has been discussed on /. before (Score:3)
For most applications, X11 works OK. If it gets some support for anti-aliasing and compositing, people will be able to do a lot more with it than they can now. Keith's effort seems like a very rational starting point for that: add a small set of server functionalities that addresses the core problems people have.
If X11 additionally got paths, floating point coordinates, and other features in the server, would that significantly expand the application areas for X11? Would it allow existing applications to be speeded up in some important way? If people want those kinds of features, why aren't they using the existing DisplayPostscript extension to X11, already donated by IBM? And is it worth adding a complete 2D rendering API when 3D APIs already provide coordinate transformations, compositing, and all the other features, hardware accelerated, and available on pretty much all platforms, for those applications that really need them?
I can't claim to know the answers; my intuition is that the more minimalist approach Keith is taking is probably the better one for now. But whatever approach might be better in the end, unless significant additional resources materialize, I suspect that is all that realistically can happen. Any volunteers?
Re:Should the hard part be server or client-side? (Score:2)
The X server is a single-threaded application right now, and turning it multi-thread would be VERY hard work.
If it was in charge do do computation-intensive tasks, while performing them it would stop responding at all. I wouldn't like that much, would you?
From a "perspective" point of view: in the scenario you're presenting (application server plus x-terminals), the app. server is usually a "big iron", while the Xterms are tiny systems. Moving a lot of computational load unto them would worsen the usage experience a lot, IMHO.
Microsoft's GDI+ (Score:3)
http://www.microsoft.com/HWDEV/vid eo/GDInext.htm [microsoft.com]
--
Re:This is berlin without the complications? (Score:1)
The problem that Berlin will face is that too many people equate Linux graphics with X, when I think they should be concentrating on getting a lower level accelerated framework, be it FBcon, or even KGI. We need some form of accelerated display that doesn't require root access and all the associated security implications that this includes.
Re:Whoa cool. (Score:2)
2) What people don't seem to understand is that OSS isn't the magic bullet. Sure there is a near infinate number of developers, but the realities of the market are still present. There is only so much public interest, whether or not a product is Open Source. Public interest is ultimately what defines who wins and who loses. Great projects die because they don't have enough public interest. Say the X extension results in a rendering interface even half as good as Berlin. Now you've got a less superior product. Certianly a more bloated product (because it incurs the bloat of regular X, plus it's own protocol) and one that really is cobled together and "hackish." However, it has backwards comptability, and by that sole trait will win. What happens then? Probably Berlin dies. By stealing Berlin's turf, X leaves Berlin with no reason for existance.
3) Competition isn't the magic bullet either. Competition only works when to products are compatible. Take a look around the software world instead of thinking idealistically. There are a lot of graphics programs competing. Why? Because they are all comptabile with each other. Then, look at Office suites. Notice how much fewer products there are in this space. Why, less comptability. Take a look at operating systems? Notice the fact that there are no competing products. Why? No comptability. When there is no comptability, userbase is everything. Look all over the software world. Everywhere you can see products suceeding soley based on userbase. Wordperfect is a better word processor than Word? Who won? OS/2 is better than Windows. Who won? Why? There is always a winner and a loser, eventually. OSS slows the ending, but doesn't stop it. Ultimately one will win. By introducing competition to an interesting product, then the OSS community is hurting itself. Things would be different if both were competing on the same level, but they aren't. Soley because X has more comptability, it will win. No matter which is the superior product. By supporting one or the other, there are bigger implications than just one project getting more code time. After all, code time is infinate. Interest is not. By drawing interest away from Berlin, the X extension is almost guarenting its demise.
Berlin (Score:1)
Re:This is berlin without the complications? (Score:1)
>rotations, AA-fonts..), but no one ever pays attention to them...
For a very good reason. They're walking the same road the Amiga designers did with their approach to the Amiga graphics subsytem. Very pretty and cool to look at untill you realized it was a one-way ticket to a dead end. Berlin isn't either backward compatable with anything but itself right? No thanks.
Re:Looks intersting (Score:1)
No, it means the applications need to render fonts themselves. This sucks, but it's not a show-stopper.
and in all the other apps, MOST PEOPLE THINK IT LOOKS LIKE SHIT
xterm is another app. I haven't heard anybody complain about the fonts in xterm.
Resorting to the cop-out that "well at low resolutions, antialiasing just doesn't work as intended" is a weaseling , pussy-ass, excuse for a fatally obsolescent system.
Yes it is. I didn't intend it as an excuse.
I don't give a fuck about your low res display, nor does the rest of the word.
100 dpi is not high resolution. Or do you really have a 300 dpi monitor?
Re:Should the hard part be server or client-side? (Score:1)
So, by taking this ideal into play the server should send polygons and such as coordinates - not the visual rasterised images.
The easiest way I can think of explaining where the line should be drawn is by imagining users with different needs and how they would interact with the server.
Re: (Score:1)
Re:XFree86 Render and Libart (Score:1)
Re:Dynamic resizing of the X display (Score:1)
Also, it allows you to look at a window full screen even if the program wasn't designed for it. That's useful for games and video.
its about time (Score:1)
now text in X can look as pretty as in windows.
Re:Looks intersting (Score:2)
Looks intersting (Score:1)
until (succeed) try { again(); }
Should the hard part be server or client-side? (Score:3)
This extension is starting to shift some of the load onto the client side:
Rendering geometric figures is accomplished by client-side tesselation into either triangles or trapezoids. Text is drawn by loading glyphs into the server and rendering sets of them.
In most cases, the client IS the same machine as the server, but in some cases, for example if I run an X-program on my shell account and the X-server locally, it means that the shell account starts to do the hard part of the rendering.
The shell acount might run X programs for 50 different users, but each X-server probably serves no more than a few screens, so I think it should rightfully be server-side.
This is berlin without the complications? (Score:4)
It should be noted that Berlin uses a completely different approach to visuals than anything X ever had. It takes the approach that the application never need know or assume what the visual will look like. 'Widget's for lack of a better term are coded modularly into the server, creating a single unique interface for all applications to call upon. No more need for Qt/Gtk wars, just pure simplification. Hell, no more SQUARE windows like X is limited to. (anything none-square is a hack...)
I wish these guys would get more support and maybe one day it'd even be accelerated :)
Re:its about time (Score:1)
Re:its about time (Score:2)
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.
Out Last, Best Hope for a Good Windowing Framework (Score:1)
Dynamic resizing of the X display (Score:1)
Don't you hate it when you use Ctrl Alt KP- to set the X display to a lower resolution (so, say, you can actually read a web page "designed" in 8pt text) and the screens Virtual size in pixels stays the same so the desktop suddenly is "off the edge" of the screen. The "screen size" of the desktop increases proportional to the decrease in resolution in order to keep the number pixels constant the size of the virtual screen increases.
eg: decreasing to 800x600
1280x1024
--------- * (Width x Height)
800x600
The same thing happens in reverse when increasing the resolution beyond that set in the Virtual line of the config file.
Why can't X just change the resolution and leave everything on the screen the way it should be - like Mac Win and BeOS do. Or (gaak) is this a window manager issue
BRAVO! (Score:1)
"Just do it." -- Linus Torvalds (paraphrasing Nike)
"Shut up and show me the code." -- Eric Raymond
--
X12? (Score:2)
One thing I have always wondered, is if the X Consortium is still willing to change the specs of the X Window System to address current problems.
Most problems today are being addressed (we have seen this story, and recently the one of Jim Gettys who believes X is ideal for pocket devices, if only some of the "bloat" code that slipped into XFree over the years would be revisited), if only because of the popularity of Linux for graphics-intensive tasks.
But most of the solutions provided are extentions to X11. Even though it is nice that X11 is made so extensible, this still means that a standard X11 setup uses none of these extentions, practically bringing us back to the mainframe ages: even transparency (heavily relied upon by some window managers, I guess) seems to be such an extention.
Now in my humble opinion, the X Consortium could release a new spec, in which they call the most well-known and useful extentions more or less official, and in which they would probably provide some more solutions as well. This can be done without breaking radically with current X implementations, thanks to the extension system, while it would take away the "officially, this can't be done with X" complaints.
(Maybe X12 would be the wrong name, because it would be a mere upgrade to the X11 spec, with backwards compatibility, so something like X11R7 or X11R6.5?)
Would the X Consortium still consider changes in their specs, or have they merely become the maintaners of a historical document? I am just asking because during the young times I have been with UNIX, it has always been X11R6.4 (or maybe X11R6.3 too?). So I actually don't know how active the Consortium is.
It's... It's...
Re:Looks intersting (Score:1)
What he's saying is if you do anti-aliased text the "old way" of rendering pixmaps and pushing them out, there's no longer any "text" to be selected in the clipboard. It's just an image.
Re:its about time (Score:2)
Windows does not alpha blend text. Mac does not alpha blend text.
Antialiasing without alpha blending is substantially worse than with alpha blending.
Windows has great fonts. Great fonts are bought, and hardly ever given freely (a few notable exceptions occur in the case of TeX).
Alpha blending and antialiasing will help X font looks quite a bit. But good fonts help a lot too. And Microsoft has bought a lot of good fonts.
Whoa cool. (Score:1)
Hmm... (Score:2)
Re:Dynamic resizing of the X display (Score:1)
Re:This is berlin without the complications? (Score:1)
Yes thanks,
--
Simon
Re:This is berlin without the complications? (Score:1)
Berlin uses CORBA so thus remote corba objects thus you can use your own widget set.
Berlin uses a 'visual' hierarchy of objects within the server. I agree that custom widget sets can be made to work alongside with the server, but hacking them in to work from the x-client is *not* what Berlin was intended to do. The one problem with this kind of ideology is that there'll be no easy way to have two widget sets along side each other on the same screen.
Although I may be wrong or they may have changed this since last I heard (a year ago?).
What is Gamma? (Score:2)
Re:its about time (Score:1)
The legalities of this may be shaky, but the risks of being successfully sued aren't that high.
Re:X12? (Score:1)
Besides, leaving non-essential bits as extensions makes projects like putting an Xserver on a handheld easier, because they don't have to support them, and clients can easily check whether or not they do.
Re:What is Gamma? (Score:1)
all CRTs have an exponential (or is it logarithmic?) response function. (Do LCDs too?). Anyway, they don't always have the same constant factor in the response function. So while 255 is 100% brightness, 50% brightness may be 160 instead of 128. Or maybe 80. You calculate this from the gamma, which controls how fast the exponential grows.
Having just the one gamma is an oversimplification of course. You'd really want all three R G B, and for really accurate color matching you'd want to work in maximum luminosity and what not. But just the one value is way better than none.
Johan
Re:Should the hard part be server or client-side? (Score:2)
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.
This has been discussed on /. before (Score:1)
http://slashdot.org/articles/00/05/07/2316257.s
Pay particular attention to comment #275 as it is a concrete
suggestion for what a new rendering model should support.
I'm no expert on graphics rendering models or on the X Windows System and cannot comment on the merits of this new rendering model versus any other model.
I do have this to say - if there is to be a major re-structuring of the X Windows rendering model, it should be designed and architected by a group of people who work together to design a system that will last for ten more years.
It is great that someone is doing real work to address X's very real shortcomings. I just want to make sure that any new rendering model is truly architected to last for as long as possible.
The more well informed and experienced people that get involved in the design, the better off we will all be.
Re:Looks intersting (Score:3)
Re:its about time (Score:1)
Re:This is berlin without the complications? (Score:3)
Win32 has its own, native widget set, and that hasn't stopped people from porting Gtk, Qt, Tcl/Tk, wxWindows, and lots of other toolkits to it. The same will happen with Berlin if the project produces a usable windowing system at all.
It should be noted that Berlin uses a completely different approach to visuals than anything X ever had. It takes the approach that the application never need know or assume what the visual will look like.
The purpose of visuals in X isn't to make the programmer's life miserable (even if they do that on occasion) but because there was a technical need for it. There are other tradeoffs you can make: Win32 and NeWS took different approaches, with different advantages and problems. Berlin won't be able to avoid the issue either, since presumably applications will be able to draw raw 2D graphics under it one way or another. If it automates the visual management, that's one choice, good for some applications, bad for others.
XF86 3D (Score:1)
nf
Re:Should the hard part be server or client-side? (Score:1)
You seem to think that text should be rendered by the client using the new primitives. This would be a step back. But this is just the core, lower part of the new rendering engine, the introduction of new primitives (which can be hardware-accelareted) and an alpha-channel.
Once this infrastructure is inplace, higher level things, like text-api, can start to use it. It has all to be a new api though (X extensions), since IIRC the old api ties text to 2 color bitmaps.
I guess to grand overall back of the mind strategy is to make now X-extentions for all things that have to be improved, then when every toolkit and many applications use only the extensions, we can start thinking about X12 and doing away with the old cruft. At least, that's what i hope...
Re:This is berlin without the complications? (Score:1)
Actually Berlin is implemented in C++.
Anyway, even if you feel your programming skills are not up to par for a project of this scale, go ahead and volunteer to the project leader. There are plenty of other ways you can help (documentation, testing, site admin...)
-----
Re:its about time (Score:1)
What about DRI (Score:1)
Re:Looks intersting (Score:1)
Here's an experiment to do: Go to a Windows machine, run any program with a standard single line text input widget, type some gibberish, and take a good look at the font. Not anti-aliased, right? (Perhaps in some configurations, it may be, but I believe not by default.) Hmm.
At low resolutions, and allowing a choice of text size and alignment that suits the resolution, it is non-anti-aliased text that looks far clearer. Anti-aliased text at low resolutions looks dim and fuzzy. However, as you point out, it is a huge win for WYSIWYG text, when arbitrary positioning, size, and perhaps rotation must be supported.
Re:Looks intersting (Score:1)
system.
It's really no different than writing text to
any other window.
Re:Hmm... (Score:2)
I've done that. Which fonts would you like to use, and for what purpose ??
It is pretty easy to take tools like mkfontdir and type1inst and take the available Type1 versions of the TeX fonts, add them to your X fontpath (xset +fp ~/fonts/), and use them in whatever.
I personally like the cmtex series for fixed width terminal fonts. Of course, the font rasterizer is also a large problem (or rather, its lack of antialiasing and alpha blending).
Re:its about time (Score:2)
Windows fonts are TrueType fonts. True Type font technology, while largely being a subset of metafont technology, is patented by Apple, and it is possible (although it currently seems unlikely) that Apple will call those patents into action.
You can, however, convert True Type fonts into very large Type1 fonts with the ttf2pt1 package. Then they can be used by ghostscript (provided you place them in a font directory, use type1inst and mkfontdir, and edit your gs Fontmap). They can also be used by X if you rebuild the X font loader (it chokes on large fonts without a rebuild - instructions on the ttf2pt1 web site). Of course this still doesn't get you antialiasing, but it does get you some really nice fonts. And that is a large part of the problem with fonts under X. And we know that everyone loves building X and has several hundred megs just waiting for the X source code.
X also now comes with Freetype font rasterizer, so native TrueType fonts can be used. There is really no sign of Apple pulling the plug on it yet, but they can do this whenever they like. Don't forget Apple and Windows dominate TrueType font usage, and presumably Microsoft is paying a lot of money to use the patented technology.
XFree86 Render and Libart (Score:5)
Libart and the Render extension are both fairly low-level mechanisms for 2D rendering. Libart nails down the data structures and buffer layouts (24-bit packed RGB for most work), which has desirable consequences for both performance and simplicity. On the other hand, Render is really optimized for the case where there is hardware support for the primitives.
In many ways, Render is even lower level than Libart. For example, Libart handles vector paths, stroke outline, miters, line dashing, and so on. Render only handles low-level primitives such as triangles and trapezoids. To render more complex shapes, you have to tesselate them into triangles client-side before sending them to the screen.
Neither of these projects currently provides an ideal high-level API for application developers. While it will be possible to write directly to the Render layer, it's probably too much of an impedance mismatch for most applications. Similarly, the current Libart API doesn't provide any way to use the hardware acceleration that Render provides.
Thus, I'm working on a slightly higher level API for Libart, one with basically the same semantics as the existing API, but with the actual representations of data structures abstracted. Thus, a Libart+ "shape" can be a bezier path, a vector path, an SVP (sorted vector path), or a pile of triangles optimized for the Render extension. Similarly, a "picture" can be a packed RGB or RGBA buffer as now, or may be a handle to a pixel buffer actually living on the video card, accessible through the Render extension.
I want this to be a beautiful API for applications to write to. The main advantage is that it can automatically negotiate which functions should be performed server-side and which client-side. For example, no video cards today can actually deal with bezier paths directly. If this ever changes, then Keith can add the relevant stuff to the Render extension, I can add the code to Libart+ to recognize it, and apps will automatically win.
Further, this architecture provides for richer functionality than Render provides, without loss of performance in the common case. Right now, I'm adding the PDF 1.4 blend modes (Multiply, Overlay, Hard Light, Soft Light, etc) to Libart. These blending modes just get implemented in software.
Lastly, I have to say that I think Keith is making exactly the right decisions to keep Render low-level, lean, and simple. I have great confidence that he will ship something soon that provides useful access to hardware acceleration. It is refreshing to see well-engineered stuff coming out of the X world again, after many years of bloated, nearly useless crap from the X consortium and The Open Group. Gambai!
Re:Dynamic resizing of the X display (Score:1)
Changing it now would break all old clients. Unless it was done as an extension, and even then if you were running any old client, changing resolutions could cause problems for that client.
Oh your card doesn't support the new resolution that you requested in the current depth. BadValue.
It needs to handle gamma (Score:5)
Representing the range of brightness of a screen as 8 bits of intensity is actually very efficient and almost exactly matches human visual capability, if you use an exponential version where brightness(N+1)/brightness(N) is a constant for all 8-bit values N. This means brighness is a function pow(N,1/G) where G is a constant called "gamma". If you normalize N to be 0-1 then G is about 2.2.
Quite by accident this brightness function is exactly what cheap CRT's that are on PC's do when fed the linear conversion from D/A converters. So the hardware is actually perfect.
If the screen has a gamma value of G the correct math for adding images A and B so the result is the sum of brightnesses is pow(pow(A,G)+pow(B,G),1/G). The proper math for multiplying A by a mask M is pow(pow(A,G)*M,1/G).
Fortunately the data is 8 bits and thus both the above functions can be provided by 256x256 lookup tables. You can also use 256-entry tables for the two pow functions. Assumming G==2 may allow a lot of other math tricks as well, and is plenty accurate enough for vision.
The biggest problem with their design is that they specified premultiplied. This prevents the above math from being applied correctly, also gamma introduces questions about exactly what value you premultiply by.
I would recommend that they reformat their stuff to describe everything in an unpremultiplied area, and that all math is in intensities, not numeric values. The gamma is a constant built into the server and frozen at 2.2 or 2.0.
There can be a "premultiplied" flag in a picture. This should be used to fix "bad premultiply" that is produced by most (all?) 3D renderers, where the colors are in a gamma space but have been linearily multiplied by the alpha. To unpremultiply these, replace R with A?(pow(R,G)/A,1/G):R and same for G and B, leave A alone, and continue with the composite.
Re:This has been discussed on /. before (Score:5)
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.
Re:It needs to handle gamma (Score:4)
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:Karma fucking whore (Score:1)
As far as my supposed "Karma Whoring" goes, if I was truly a Karma whore, I'd have alot more Karma! I read
I do think it is valid to post a link to an older article that addresses the same issue - many of the arguments that will be made in response to this article have been made before, but not all readers may be aware of them. I think that many good proposals were made in the old article, and people can benefit from re-reading them.
I'm sorry I didn't post the article reference as a link. Next time I promise I will!
Re:Should the hard part be server or client-side? (Score:1)
Well, yes, for the implementation side that is I guess the goal for Xfree5
But I meant the spec-side, API + wire protocol. There, you have to be backwards compatible and use extentions.
By the way, just read on the mailinglist [xfree86.org] that Keith already hacked in some font support, so all the key features seem to be there for a demo. Exciting to watch...
Re:This has been discussed on /. before (Score:1)
Thanks for making a great start on the code. Its about time that someone has actually done some coding rather than just bitching about why things aren't better.