kdrive is Keith Packard's X server, a rename of TinyX. It's not a complete rewrite, but is based on XFree86's (and now X.org's), device-independent code (DIX), coupled with it's own device-dependent code (DDX).
The Xlib replacement you're talking about is XCB, which is a library designed to simplify access to the X protocol from sophisticated clients like Qt/GTK+.
Well, with X11R6.8, it's about caught up with OS X. Work is already underway to get X on OpenGL (like Longhorn), and the Cairo 2D graphics library already has good OpenGL-based acceleration.
You've got the general setup correct. It helps to think of the X server providing "display services" to all the client applications that want to display something.
X supports advanced 3D accelerators about as well as Windows does, though not quite as well as MacOS X does. A lot of the work after 6.8 will be on getting X to support 2D on OpenGL like Longhorn will.
Even if you got to a 100% OpenGL GUI, you'll still have network transparency. OpenGL has a couple of quite good network protocols. The older one is GLX (which is what most people support now), and the newer one is called Chromium. OpenGL, like X, was designed from the beginning to allow network transparency.
X11 itself is just a protocol. It specifies a byte-stream for getting programs to do things. This same byte-stream can be sent over fast IPC on a local machine, or over a network link. XFree86, X.org, and Sun have particular implementations of servers that support the X11 protocol.
X is the name of the windowing-system project invented at MIT in the 1980's. It was the successor to 'W' (stood for 'Window').
X.org, formerly the X Consortium, a bunch of industry-types (HP, Dell, DEC, IBM), tasked with developing X.
XFree86.org started as a port of the X code to PCs, and for much of the late 1990's and early 2000's, was the standard-bearer of X development.
Freedesktop.org is an umbrella project for *NIX GUI development.
At MIT, X went through several incompatible protocol versions, culminating at X11. Version 11 of the X protocol is what most servers speak today. MIT then formed the X consortium, which continued to develop X.
At some point in the early 1990s, what would become XFree86 forked from the X Consortium code, and was intended as a distribution for PCs.
The X Consortium and XFree86 continued make releases, and merged code between them periodically. At some point, the X Consortium was renamed X.org. X.org releases went up to X11R6.6. XFree86 releases, which maintained their own version number, went up to XFree86 4.4 (4.3 corresponded roughly to the X11R6.6 code). During this time, XFree86 was the primary developer of X11.
After a license change at XFree86, and concerns about it's slow pace of development, X.org and freedesktop.org forked the XFree86 4.4 code (just prior to the license change), and released X11R6.7. X11R6.8 is the latest release from X.org/freedesktop.org
How can you know that? Do you write the video drivers for all current video hardware? Look at it this way: if current hardware was capable of accelerating anti-aliased bezier curves, they'd accelerate GDI+. The fact that GDI+ is so slow suggests that they are not accelerating it, because 2D cores don't have that kind of capability.
I still don't understand why a video driver would want to hook a rendering function only to do it in software by the CPU. Maybe the vendor-provided emulation is slow?
If the rendering is done by the CPU anyways, then why does turning the performance slider down hurt GDI performance so much? Currently, the only GDI acceleration utilized by most Windows software is:
If Avalon doesn't have to provide predictable pixel accuracy, then why does GDI? I mean, if that support is going to be chucked anyways... Becuase GDI is an existing API, and you can't change the semantics of an existing API like that.
An EMF is just a list of GDI rendering commands. In a way, but there is a layer of logic above the GDI rendering commands. GDI is fundementally a raster API, while EMF is a vector file format. There is a translation layer involved.
When you set a point on a metafile, it is the same thing as in a PDF. Yes, but setting a point in a metafile isn't the same thing as setting a point in a PDF. Look, if you ignore anti-aliasing (which you're doing), it's a matter of semantics more than capability. Assuming you haven't changed the coordinate transform, when you draw a pixel at 2,3 using SetPixel, the semantics of the GDI say that you'll get a single pixel at 2,3. The semantics of PDF and EMF don't say anything about what pixel will get drawn. You could make the GDI resolution-independent by removing these semantics, but that'd break the API for applications that depend on the existing behavior.
I have yet to see a list (even tenative) of functions or classes that Avalon will be made up of. Who cares about functions and classes? Those are just details that'll be revealed when the API is released. What matters is the underlying semantics exposed by the API. The fundemental concept of Avalon is that all drawing occurs in a 3D space using a 2D projection. That means you get a 2D image by default, but the capability exists to rotate things in space. All drawing will be composed of tesselated triangles. Drawing APIs will be provided, so you can draw a Bezier surface, which will be tesselated into triangles and drawn onto the Avalon surface. Anything you can do with triangles in your 3D card, you'll be able to do with the 2D images in Avalon. This includes applying per-pixel effects (bump-mapping, gradients, shading) to objects.
Take this article. "Repainting vs markup": wow caching is already done by GDI in some situations, it would be easy to expand it to everything. It's not caching, it's immediate-mode vs retained mode. Avalon will feature a scene graph API, as opposed to a painter API. The fundemental difference is this: in GDI you can draw a green square on top of a red square, but cannot then move the red square without redrawing the scene. In a scene graph, you add a green-square object to the graph on top of a red-square object. The actual rendering is handled automatically --- if you animate the red-square object by moving it around, the necessary redrawing will be done by the scene graph.
Well, I saw the movie, and several of these criticisms aren't really accurate:
* Implying that Fox somehow had the ability to change all the other Networks stance on who won Florida, when this was not the case at all. I don't remember him implying that Fox News had any power to change it, just that they were in the lead in declaring Bush president.
*Implying that a member of the Bush admin hired a company to turn away African American voters at the polls. I'll buy that.
*Implying that Gore won the election no matter what. If the recount method Gore request had been allowed to finish, Bush would've won. That too.
*Implying that Bush vacationed 42 percent of the time in his first six months, with the implication that Bush can't do work away from the whitehouse (slashdotters should know the ease with which offlocation work can be done) It's not an implication, it's a matter of public record. Whether or not he can do work away from the Whitehouse is a seperate issue. Now, I know when I do work at home, I'm not nearly as productive as I am at work, and I'm not the fricking President of the USA! His work probably involves, to a great degree, meeting with other people, and that's certainly something that is restricted by him not being in DC.
*Implying that Bush didn't read the briefing mentioning the potential terrorist threat. I'm pretty sure it came out that he didn't.
*Implying that there were no flights allowed in the air when the saudis left the country. Yeah, this is true.
*Implying that the Bin Ladens weren't at all questioned before leaving the air. This is patently false. The movie did say they were questioned, just that it was cursory and they weren't detained for more extensive questioning.
Personally, I didn't like the movie. I get his point, but he uses a low-class argumentative style, using emotion more than reason. Personally, I thought there were lot's of ways to nail Bush using a purely rational argument. That said, I'm beginning to think purely rational arguments would exceed the attention span of most voters, so the evil of Michael Moore style arguments is necessary to counter the very effective marketing machine on the Republicans' side.
Of course, the two parties are just similar if all you care to consider is how much the whore themselves out to corporations, and how much they want to affect your personal rights (the traditional libertarian concerns). However, you'd be a moron if you said that the two parties are even remotely similar in their economic, social, and foreign-policy agendas. From my point of view: no matter who I vote for, congress will still be bought out. It'll be either by Disney or Haliburton, but it will be bought out. However, with one president, there is at least the chance we won't kill thousands of people overseas in an unjust war, and won't damage our international alliances more than they already are. With one president, there is the reduced chance of Christian morality being imposed upon the country as a whole. With one president, there is the hope of getting some sensible healthcare that doesn't overtly favor those with the most money. To me those are enough differences to make it clear who my choice should be, even if neither candidate is someone I agree with on all the issues.
PS> Not to mention that the only visible third party candidate, Nader, is an absolute twit, and the libertarian party still ignores modern economics to live in their 19th century dreamworld.
No, DrvTextOut allows a display driver to handle [microsoft.com] all aspects of font rendering. Hmm, that might be the case, but I don't know of any current hardware that actually does this.
Like I said before, GDI is only an interface: the vendor can choose to implement it any way they want. Tell me why a vendor couldn't use the 3d hardware (and ditch the 2d hardware) on their card to support GDI? The primary reason is that the GDI isn't set up to handle things that way. It expects seperate drivers for GDI and D3D functionality. In any case, you couldn't use 3D hardware to accelerate the GDI anyway, because the GDI specifices pixel-exact semantics, and most 3D engines aren't designed to give pixel-exact output.
GDI handles device space transformations exclusively, not you. The current semantics of the GDI is that there is an identity transformation between input coordinates and output pixels. You cannot change that transformation without breaking the semantics of the GDI. Without changing this transformation, you cannot have a resolution-independent interface.
how would you feel if Western Digital decided to not store your data correctly because hard drive technology is changning rapidly? Graphics are not data. They are meant for human consumption, not computer consumption. It is reasonable to expect them to vary slightly, just as audio output varies slightly from vendor to vendor. The point of graphics is to get a good-looking image as fast as possible --- it should not be burdened with trying to guarantee an exact image.
the output from the 3d renderer can be predicted exactly. No it cannot. All you have to do is change the anti-aliasing settings or filter slightly to get a different image. Certainly, no two manufacturers will implement fiThat's why 3D APIs like OpenGL don't guarantee the exact pixels that will be drawn in response to 3D commands.
GDI never guarnteed pixel level access to device surfaces. Pixel-exact API != pixel-level access to device surfaces. Pixel exact API means the API specifies precisely what pixels are drawn in response to graphics command. That level of specification is not feasible with 3D graphics.
What, exactly, can the PDF 1.4 imaging model do that Enhanced Metafiles can't? The GDI imaging model isn't the same as the enhanced metafiles imaging model. Microsoft takes some liberties with it, not the least of which is that it specifies a resolution-independent interface while GDI specifies a resolution-dependent interface. GDI can be used to draw EMF files, just like GDI can be used to draw PDF files, but there is a semantic mismatch between the two. The fundemental distinction is that "change the color of pixel 2,3 to red" makes perfect sense in the GDI imaging model, and has an expected result. It makes no sense in the PDF imaging model. The best the app can do is draw a point at 2.0, 3.0, and depending on the resolution of the screen, that might be a single pixel, a partial pixel (thanks to sub-pixel AA), or a blob of several pixels.
I try, but all the literature that I find about Avalon and Longhorn is increadibly vague. What exactly is vague about it?
There isn't that big a difference in the way 3d and 2d effects are rendered on a modern GPU. There is a huge difference. Modern GPUs are basically general purpose vector microprocessors *with* some specialized hardware. One of those specialized pieces of hardware is a 2D ASIC, which has specialized circuitry for things like drawing lines. It is a seperate functional block from the general 3D core.
Yes, that is what would happen if the video driver didn't support the DrvTextOut DrvTextOut doesn't rasterize the glyphs. It takes pre-rendered glyphs from the software font-rasterizer and alpha-blits them to the screen. This is exactly how Xft/XRender works.
Sure you can; it's called a "standard". I'm sorry that some other rendering engines are sloppy. No you can't. The whole point of resolution-independence is to kill the relationship between pixels an coordinates. You'll get a different set of rendered pixels when you draw to a 300dpi target than if you draw to a 100dpi target. Also, it is not feasible to standardize the pixel output in the face of anti-aliasing, because hardware anti-aliasing algorithms in hardware are still evolving quickly.
I don't think that there is a seperate 2d and 3d engine on modern GPUs. Yes, there are. Take a look at the block-diagram of the ATI R350 core (Radeon 9700).
Or are you saying that video driver writers have to resort to a hack to support alpha blending? The video driver writers have to resort to a hack to support alpha blending. Most current 2D cores were not designed for alpha blending, so cores that support alpha blits tend to hijack the 3D circuitry to do it. Often, these hacks don't fully support all the blit features (like scaling), because the only critical software that depends on alpha blits is the font-renderer, which needs unscaled alpha blits for rendering anti-aliased fonts.
Is there some reason that the GPU can't do alpha blits on demand? Hacks are necessary because the 3D core is set up as a pipeline. Vertex data goes in one end, pixels come out the other end. It's not easy to just hijack pieces of the pipeline and use them from the seperate 2D core.
There aren't seperate 2d and 3d drivers. Yes there are. There is a GDI DDI (the Drv* functions), and a seperate Direct3D DDI.
As for concurrency, unless you have some really crappy driver that doesn't support asyncronous rendering We're talking about concurrency between the 2D core on the card and the 3D core on the card.
Here: Transparency Bezier curves Anti-aliasing Gradients The anti-aliasing link points to something that has nothing to do with anti-aliasing. Aliased output is simply not acceptable today. Transparency, bezier curves, and gradients might be supported in the GDI, but it's not efficiently implementable given the limitations of the GDI driver model.
Contortion could easily be made a space transformation No it cannot. Do you understand graphics? *Convolution* requires a color matrix, which GDI doesn't supply.
and pixel shaders is too vague; pixel shading is a means, not an end. Pixel shaders is not vague. A pixel shader is a program that can perform arbitrary per-pixel operations on rasterized pixels. GDI has no mechanism for doing such things.
Are you trying to say that these support functions don't really work; that they are just for pretend? What I'm saying is that most vendors don't bother to properly hardware-accelerate these functions (because it's hard within the confines of the GDI, and nobody uses it anyway), and supply fast software-emulation instead.
The API already supports device-independent and scale independent rendering through coordinate space transformations as I stated earlier. It's not a resolution-independent API if you have to set-up the coordinate transform for resolution ind
I read this as saying that GPU rendering acceleration won't be available until OSX 10.4, Longhorn(Avalon) and Cairo. I disagreed with this since GDI can already use the GPU for 2d rendering. When people say GPU, they don't mean the 2D accelerator on graphics cards, they mean the 3D accelerator. Mac, X, and Windows have used the 2D core for ages (along with every other OS under the sun). Those things aren't very interesting, and haven't improved in capability in a long time. The programmable 3D core, however, is capable enough to properly support the PDF 1.4/SVG imaging model.
GDI supports accelerated anti-aliasing of fonts (not paths) using the FO_GRAY16 member of the FONTOBJ font description structure... This isn't a limitation of GDI's design. In practice, nothing accelerates font-rasterization. GDI ends up doing the same thing X and MacOS do --- rasterizing the outline in software to a off-screen buffer, and simply using an alpha blit to compose the pre-rendered glyph. The lack of anti-aliasing is a limitation of the GDI design, for 2 reasons:
1) It's a pixel-exact API. It guarantees certain things about what pixels will be drawn in response to certain commands. Of course, with a resolution-independent, anti-aliased rendering engine, you can't make such guarantees.
2) It's designed to use a seperate 2D engine on the card. This brings all sorts of concurrency issues between the 2D engine and 3D engine. That's why nobody release proper accelerators for GDI+ --- it's concurrency issues just make it a PITA. Some drivers do have hacks to allow things like alpha blits to use the 3D engine, but at the end of the day, these things are still hacks.
According to GetDeviceCaps my video card (a GF3Ti200) supports drawing of both curves and gradients. Even if it didn't, this is the video driver maker's problem, not GDI's. It's probably using a fast software-emulation inside the driver. And it is a problem of the GDI, because the seperate 2D and 3D driver model makes it hard to write a graphics core that can use the 3D core's evaluators to draw curves in hardware.
GDI already has all the base functionaility needed to support resolution-independent display technology. However, most drivers won't accelerate them, because that requires coordinating access to the 3D engine while in the 2D driver.
I'm curious about what it is that makes 'third-generation' rendering engines so great? What is it that these do that GDI either cannot already do or couldn't be made to do easily? (without a rewrite)
Sure, you could hack up the GDI to get the first 4 capabilities, but consider what you'd have to do:
a) You'd have to rewrite the client-side library, to present a resolution-independent, rather than pixel-exact API. You'd also have to add support to it for the above-mentioned features. Since it'd be bad idea to just change the semantics of the API silently, so you'd have to put all these changes in a new library (GDI++).
b) You'd have to rewrite the drivers to use the 3D engine instead of the 2D engine, to solve the concurrency issues.
At that point, all you'd have left is the GDI -> Driver API, and it'd be a sub-optimal API at that. That's why Avalon is a complete rewrite of the GDI --- because it needs to be.
Well, these are things that can't really be fixed that way. Most involve addition of new features (to do things that were previously accomplished through work-arounds), while one requires a semantic change that would break compatibility.
1) The Windows 95 plus pack did not have actual anti-aliasing. It was a font-smoothing hack that was turned off by default. Back then, the best font rendering was from aliased, well-hinted Truetype fonts, which Freetype (with bytecode interpreter) could render identically to Win9x.
2) Microsoft's anti-aliasing in Windows 2000 is also a hack. It's not based on a compositing model and doesn't provide windows with a complete alpha channel, just a single alpha attribute. The latter, in particular, makes it mostly useless, because you can't have solid text in an otherwise transparent window (eg: like MacOS X's terminal). It's really just a well-implemented version of the "transparent window" tricks GNOME and KDE use now.
I don't think you understand. That's all that XFixes is! It's an extension containing various "fixes" to the core X functionality. That's it. That's why they seem like little things that aren't related --- because that's precisely what they are.
Who is making apologies? Some dipshit complained that OSS display technologies are a decade behind the competition, and I pointed out that they aren't. If I'm apologizing for X not having a fully GL-accelerated server right now, maybe some Windows "advocate" should apologize for WinXP lacking the same things.
Um, what does GDI have to do with this? We were talking about Quartz extreme. GDI is irrelevent to this discussions for two reasons:
1) It doesn't have the same imaging model. GDI is a 2nd generation display technology. Cairo and Quartz2D are a third generation (resolution-independent) display technology. GDI doesn't do anti-aliasing either.
2) Most drivers don't accelerate the curve and gradient portions of the GDI. GDI+ was designed to foster that, but nobody accelerated that either. That's why Microsoft just decided to use Direct3D to accelerate Avalon.
In practice, GDI doesn't accelerate anything that XAA (XFree86's acceleration layer) doesn't. However, while 2nd-gen apps were fine with acceleration of aliased-lines, and simple fills and blits (which is what GDI and XAA provide), such meagre functionality doesn't cut it for 3rd gen display technologies like Avalon, Cairo, and Quartz.
1) You were the prick for calling OSS developers monkeys.
2) There are a million and a half OS X themes for every OS. Slashdot just happend to post a screenshot from some random user that happend to use one. It's not like GNOME 2.8 released with Aqua icons as the default! Heck, it wasn't even an official press release!
You have to remember that screenshots aren't really accurate. I use 9pt fonts, but people always complain about huge fonts in my screenshots because I use a 133dpi monitor and most people use a 96-100 dpi monitor. So if the person has a high-resolution monitor, their fonts will likely look bigger to you than they look to them.
It won't be fixed completely. It'll be fixed for moving windows, but double-buffered resizing requires functionality from the composite subsystem that isn't there yet. A synchronized resize, like OS X, looks like this:
1) Composition manager saves the current window buffer. 2) Application is signaled to start the redraw. 3) Composition manager keeps displaying the saved buffer, while directing rendering to the new buffer. 4) Application signals end of rendering. 5) Composition manager replaces old buffer with new buffer, and frees the old buffer.
Currently, the ability to do step (1) isn't in composite, and toolkits don't support step (4).
(try resizing your window very fast with content visible) Depending on your configuration, this will be made much better when toolkits and WM's are updated to support XSYNC additions to the netwm standard. Fedora Core 3 Test-1 has then by default, and it makes things look a lot better. It's not as good as Windows yet (GTK+ is just so slow), but it's better. The xsync stuff makes KDE on a par with Windows for resize (on my 2.0GHz P4).
Freetype is an excellent font-renderer. You need a goot set of fonts. The only decent free ones are the Bitstream Vera set --- if you can afford it, I recommend springing for some quality Adobe or Monotype fonts. Of course, you can always just use Ariel and Tahoma from your XP install!
There isn't an official time-table, just the information I've gleaned from lurking on mailing lists and whatnot. If you look at the xserver mailing lists from around this winter, you can piece together the basic plan.
Of course, the key piece here is Cairo/Glitz, which is already quite usable.
Slashdot Mirror
You're conflating a couple of things.
kdrive is Keith Packard's X server, a rename of TinyX. It's not a complete rewrite, but is based on XFree86's (and now X.org's), device-independent code (DIX), coupled with it's own device-dependent code (DDX).
The Xlib replacement you're talking about is XCB, which is a library designed to simplify access to the X protocol from sophisticated clients like Qt/GTK+.
Well, with X11R6.8, it's about caught up with OS X. Work is already underway to get X on OpenGL (like Longhorn), and the Cairo 2D graphics library already has good OpenGL-based acceleration.
You've got the general setup correct. It helps to think of the X server providing "display services" to all the client applications that want to display something.
X supports advanced 3D accelerators about as well as Windows does, though not quite as well as MacOS X does. A lot of the work after 6.8 will be on getting X to support 2D on OpenGL like Longhorn will.
Even if you got to a 100% OpenGL GUI, you'll still have network transparency. OpenGL has a couple of quite good network protocols. The older one is GLX (which is what most people support now), and the newer one is called Chromium. OpenGL, like X, was designed from the beginning to allow network transparency.
X11 itself is just a protocol. It specifies a byte-stream for getting programs to do things. This same byte-stream can be sent over fast IPC on a local machine, or over a network link. XFree86, X.org, and Sun have particular implementations of servers that support the X11 protocol.
Let me try to put things simply.
X is the name of the windowing-system project invented at MIT in the 1980's. It was the successor to 'W' (stood for 'Window').
X.org, formerly the X Consortium, a bunch of industry-types (HP, Dell, DEC, IBM), tasked with developing X.
XFree86.org started as a port of the X code to PCs, and for much of the late 1990's and early 2000's, was the standard-bearer of X development.
Freedesktop.org is an umbrella project for *NIX GUI development.
At MIT, X went through several incompatible protocol versions, culminating at X11. Version 11 of the X protocol is what most servers speak today. MIT then formed the X consortium, which continued to develop X.
At some point in the early 1990s, what would become XFree86 forked from the X Consortium code, and was intended as a distribution for PCs.
The X Consortium and XFree86 continued make releases, and merged code between them periodically. At some point, the X Consortium was renamed X.org. X.org releases went up to X11R6.6. XFree86 releases, which maintained their own version number, went up to XFree86 4.4 (4.3 corresponded roughly to the X11R6.6 code). During this time, XFree86 was the primary developer of X11.
After a license change at XFree86, and concerns about it's slow pace of development, X.org and freedesktop.org forked the XFree86 4.4 code (just prior to the license change), and released X11R6.7. X11R6.8 is the latest release from X.org/freedesktop.org
There is a great, detailed history here.
How can you know that? Do you write the video drivers for all current video hardware?
Look at it this way: if current hardware was capable of accelerating anti-aliased bezier curves, they'd accelerate GDI+. The fact that GDI+ is so slow suggests that they are not accelerating it, because 2D cores don't have that kind of capability.
I still don't understand why a video driver would want to hook a rendering function only to do it in software by the CPU.
Maybe the vendor-provided emulation is slow?
If the rendering is done by the CPU anyways, then why does turning the performance slider down hurt GDI performance so much?
Currently, the only GDI acceleration utilized by most Windows software is:
1) Accelerated lines;
2) Accelerated fills;
3) Accelerated blits.
Turning the slider down affects these things.
If Avalon doesn't have to provide predictable pixel accuracy, then why does GDI? I mean, if that support is going to be chucked anyways...
Becuase GDI is an existing API, and you can't change the semantics of an existing API like that.
An EMF is just a list of GDI rendering commands.
In a way, but there is a layer of logic above the GDI rendering commands. GDI is fundementally a raster API, while EMF is a vector file format. There is a translation layer involved.
When you set a point on a metafile, it is the same thing as in a PDF.
Yes, but setting a point in a metafile isn't the same thing as setting a point in a PDF. Look, if you ignore anti-aliasing (which you're doing), it's a matter of semantics more than capability. Assuming you haven't changed the coordinate transform, when you draw a pixel at 2,3 using SetPixel, the semantics of the GDI say that you'll get a single pixel at 2,3. The semantics of PDF and EMF don't say anything about what pixel will get drawn. You could make the GDI resolution-independent by removing these semantics, but that'd break the API for applications that depend on the existing behavior.
I have yet to see a list (even tenative) of functions or classes that Avalon will be made up of.
Who cares about functions and classes? Those are just details that'll be revealed when the API is released. What matters is the underlying semantics exposed by the API. The fundemental concept of Avalon is that all drawing occurs in a 3D space using a 2D projection. That means you get a 2D image by default, but the capability exists to rotate things in space. All drawing will be composed of tesselated triangles. Drawing APIs will be provided, so you can draw a Bezier surface, which will be tesselated into triangles and drawn onto the Avalon surface. Anything you can do with triangles in your 3D card, you'll be able to do with the 2D images in Avalon. This includes applying per-pixel effects (bump-mapping, gradients, shading) to objects.
Take this article. "Repainting vs markup": wow caching is already done by GDI in some situations, it would be easy to expand it to everything.
It's not caching, it's immediate-mode vs retained mode. Avalon will feature a scene graph API, as opposed to a painter API. The fundemental difference is this: in GDI you can draw a green square on top of a red square, but cannot then move the red square without redrawing the scene. In a scene graph, you add a green-square object to the graph on top of a red-square object. The actual rendering is handled automatically --- if you animate the red-square object by moving it around, the necessary redrawing will be done by the scene graph.
But we aren't fighting those people! Those are American terrorists, and we're not doing anything about those!
Well, I saw the movie, and several of these criticisms aren't really accurate:
* Implying that Fox somehow had the ability to change all the other Networks stance on who won Florida, when this was not the case at all.
I don't remember him implying that Fox News had any power to change it, just that they were in the lead in declaring Bush president.
*Implying that a member of the Bush admin hired a company to turn away African American voters at the polls.
I'll buy that.
*Implying that Gore won the election no matter what. If the recount method Gore request had been allowed to finish, Bush would've won.
That too.
*Implying that Bush vacationed 42 percent of the time in his first six months, with the implication that Bush can't do work away from the whitehouse (slashdotters should know the ease with which offlocation work can be done)
It's not an implication, it's a matter of public record. Whether or not he can do work away from the Whitehouse is a seperate issue. Now, I know when I do work at home, I'm not nearly as productive as I am at work, and I'm not the fricking President of the USA! His work probably involves, to a great degree, meeting with other people, and that's certainly something that is restricted by him not being in DC.
*Implying that Bush didn't read the briefing mentioning the potential terrorist threat.
I'm pretty sure it came out that he didn't.
*Implying that there were no flights allowed in the air when the saudis left the country.
Yeah, this is true.
*Implying that the Bin Ladens weren't at all questioned before leaving the air.
This is patently false. The movie did say they were questioned, just that it was cursory and they weren't detained for more extensive questioning.
Personally, I didn't like the movie. I get his point, but he uses a low-class argumentative style, using emotion more than reason. Personally, I thought there were lot's of ways to nail Bush using a purely rational argument. That said, I'm beginning to think purely rational arguments would exceed the attention span of most voters, so the evil of Michael Moore style arguments is necessary to counter the very effective marketing machine on the Republicans' side.
Of course, the two parties are just similar if all you care to consider is how much the whore themselves out to corporations, and how much they want to affect your personal rights (the traditional libertarian concerns). However, you'd be a moron if you said that the two parties are even remotely similar in their economic, social, and foreign-policy agendas. From my point of view: no matter who I vote for, congress will still be bought out. It'll be either by Disney or Haliburton, but it will be bought out. However, with one president, there is at least the chance we won't kill thousands of people overseas in an unjust war, and won't damage our international alliances more than they already are. With one president, there is the reduced chance of Christian morality being imposed upon the country as a whole. With one president, there is the hope of getting some sensible healthcare that doesn't overtly favor those with the most money. To me those are enough differences to make it clear who my choice should be,
even if neither candidate is someone I agree with on all the issues.
PS> Not to mention that the only visible third party candidate, Nader, is an absolute twit, and the libertarian party still ignores modern economics to live in their 19th century dreamworld.
No, DrvTextOut allows a display driver to handle [microsoft.com] all aspects of font rendering.
Hmm, that might be the case, but I don't know of any current hardware that actually does this.
Like I said before, GDI is only an interface: the vendor can choose to implement it any way they want. Tell me why a vendor couldn't use the 3d hardware (and ditch the 2d hardware) on their card to support GDI?
The primary reason is that the GDI isn't set up to handle things that way. It expects seperate drivers for GDI and D3D functionality. In any case, you couldn't use 3D hardware to accelerate the GDI anyway, because the GDI specifices pixel-exact semantics, and most 3D engines aren't designed to give pixel-exact output.
GDI handles device space transformations exclusively, not you.
The current semantics of the GDI is that there is an identity transformation between input coordinates and output pixels. You cannot change that transformation without breaking the semantics of the GDI. Without changing this transformation, you cannot have a resolution-independent interface.
how would you feel if Western Digital decided to not store your data correctly because hard drive technology is changning rapidly?
Graphics are not data. They are meant for human consumption, not computer consumption. It is reasonable to expect them to vary slightly, just as audio output varies slightly from vendor to vendor. The point of graphics is to get a good-looking image as fast as possible --- it should not be burdened with trying to guarantee an exact image.
the output from the 3d renderer can be predicted exactly.
No it cannot. All you have to do is change the anti-aliasing settings or filter slightly to get a different image. Certainly, no two manufacturers will implement fiThat's why 3D APIs like OpenGL don't guarantee the exact pixels that will be drawn in response to 3D commands.
GDI never guarnteed pixel level access to device surfaces.
Pixel-exact API != pixel-level access to device surfaces. Pixel exact API means the API specifies precisely what pixels are drawn in response to graphics command. That level of specification is not feasible with 3D graphics.
What, exactly, can the PDF 1.4 imaging model do that Enhanced Metafiles can't?
The GDI imaging model isn't the same as the enhanced metafiles imaging model. Microsoft takes some liberties with it, not the least of which is that it specifies a resolution-independent interface while GDI specifies a resolution-dependent interface. GDI can be used to draw EMF files, just like GDI can be used to draw PDF files, but there is a semantic mismatch between the two. The fundemental distinction is that "change the color of pixel 2,3 to red" makes perfect sense in the GDI imaging model, and has an expected result. It makes no sense in the PDF imaging model. The best the app can do is draw a point at 2.0, 3.0, and depending on the resolution of the screen, that might be a single pixel, a partial pixel (thanks to sub-pixel AA), or a blob of several pixels.
I try, but all the literature that I find about Avalon and Longhorn is increadibly vague.
What exactly is vague about it?
There isn't that big a difference in the way 3d and 2d effects are rendered on a modern GPU.
There is a huge difference. Modern GPUs are basically general purpose vector microprocessors *with* some specialized hardware. One of those specialized pieces of hardware is a 2D ASIC, which has specialized circuitry for things like drawing lines. It is a seperate functional block from the general 3D core.
Yes, that is what would happen if the video driver didn't support the DrvTextOut
DrvTextOut doesn't rasterize the glyphs. It takes pre-rendered glyphs from the software font-rasterizer and alpha-blits them to the screen. This is exactly how Xft/XRender works.
Sure you can; it's called a "standard". I'm sorry that some other rendering engines are sloppy.
No you can't. The whole point of resolution-independence is to kill the relationship between pixels an coordinates. You'll get a different set of rendered pixels when you draw to a 300dpi target than if you draw to a 100dpi target. Also, it is not feasible to standardize the pixel output in the face of anti-aliasing, because hardware anti-aliasing algorithms in hardware are still evolving quickly.
I don't think that there is a seperate 2d and 3d engine on modern GPUs.
Yes, there are. Take a look at the block-diagram of the ATI R350 core (Radeon 9700).
Or are you saying that video driver writers have to resort to a hack to support alpha blending?
The video driver writers have to resort to a hack to support alpha blending. Most current 2D cores were not designed for alpha blending, so cores that support alpha blits tend to hijack the 3D circuitry to do it. Often, these hacks don't fully support all the blit features (like scaling), because the only critical software that depends on alpha blits is the font-renderer, which needs unscaled alpha blits for rendering anti-aliased fonts.
Is there some reason that the GPU can't do alpha blits on demand?
Hacks are necessary because the 3D core is set up as a pipeline. Vertex data goes in one end, pixels come out the other end. It's not easy to just hijack pieces of the pipeline and use them from the seperate 2D core.
There aren't seperate 2d and 3d drivers.
Yes there are. There is a GDI DDI (the Drv* functions), and a seperate Direct3D DDI.
As for concurrency, unless you have some really crappy driver that doesn't support asyncronous rendering
We're talking about concurrency between the 2D core on the card and the 3D core on the card.
Here: Transparency Bezier curves Anti-aliasing Gradients
The anti-aliasing link points to something that has nothing to do with anti-aliasing. Aliased output is simply not acceptable today. Transparency, bezier curves, and gradients might be supported in the GDI, but it's not efficiently implementable given the limitations of the GDI driver model.
Contortion could easily be made a space transformation
No it cannot. Do you understand graphics? *Convolution* requires a color matrix, which GDI doesn't supply.
and pixel shaders is too vague; pixel shading is a means, not an end.
Pixel shaders is not vague. A pixel shader is a program that can perform arbitrary per-pixel operations on rasterized pixels. GDI has no mechanism for doing such things.
Are you trying to say that these support functions don't really work; that they are just for pretend?
What I'm saying is that most vendors don't bother to properly hardware-accelerate these functions (because it's hard within the confines of the GDI, and nobody uses it anyway), and supply fast software-emulation instead.
The API already supports device-independent and scale independent rendering through coordinate space transformations as I stated earlier.
It's not a resolution-independent API if you have to set-up the coordinate transform for resolution ind
I read this as saying that GPU rendering acceleration won't be available until OSX 10.4, Longhorn(Avalon) and Cairo. I disagreed with this since GDI can already use the GPU for 2d rendering.
When people say GPU, they don't mean the 2D accelerator on graphics cards, they mean the 3D accelerator. Mac, X, and Windows have used the 2D core for ages (along with every other OS under the sun). Those things aren't very interesting, and haven't improved in capability in a long time. The programmable 3D core, however, is capable enough to properly support the PDF 1.4/SVG imaging model.
GDI supports accelerated anti-aliasing of fonts (not paths) using the FO_GRAY16 member of the FONTOBJ font description structure... This isn't a limitation of GDI's design.
In practice, nothing accelerates font-rasterization. GDI ends up doing the same thing X and MacOS do --- rasterizing the outline in software to a off-screen buffer, and simply using an alpha blit to compose the pre-rendered glyph. The lack of anti-aliasing is a limitation of the GDI design, for 2 reasons:
1) It's a pixel-exact API. It guarantees certain things about what pixels will be drawn in response to certain commands. Of course, with a resolution-independent, anti-aliased rendering engine, you can't make such guarantees.
2) It's designed to use a seperate 2D engine on the card. This brings all sorts of concurrency issues between the 2D engine and 3D engine. That's why nobody release proper accelerators for GDI+ --- it's concurrency issues just make it a PITA. Some drivers do have hacks to allow things like alpha blits to use the 3D engine, but at the end of the day, these things are still hacks.
According to GetDeviceCaps my video card (a GF3Ti200) supports drawing of both curves and gradients. Even if it didn't, this is the video driver maker's problem, not GDI's.
It's probably using a fast software-emulation inside the driver. And it is a problem of the GDI, because the seperate 2D and 3D driver model makes it hard to write a graphics core that can use the 3D core's evaluators to draw curves in hardware.
GDI already has all the base functionaility needed to support resolution-independent display technology.
However, most drivers won't accelerate them, because that requires coordinating access to the 3D engine while in the 2D driver.
I'm curious about what it is that makes 'third-generation' rendering engines so great? What is it that these do that GDI either cannot already do or couldn't be made to do easily? (without a rewrite)
1) Transparency
2) Bezier curves
3) Anti-aliasing
4) Gradients
5) Convolution
6) Per-pixel shader effects
Sure, you could hack up the GDI to get the first 4 capabilities, but consider what you'd have to do:
a) You'd have to rewrite the client-side library, to present a resolution-independent, rather than pixel-exact API. You'd also have to add support to it for the above-mentioned features. Since it'd be bad idea to just change the semantics of the API silently, so you'd have to put all these changes in a new library (GDI++).
b) You'd have to rewrite the drivers to use the 3D engine instead of the 2D engine, to solve the concurrency issues.
At that point, all you'd have left is the GDI -> Driver API, and it'd be a sub-optimal API at that. That's why Avalon is a complete rewrite of the GDI --- because it needs to be.
Well, these are things that can't really be fixed that way. Most involve addition of new features (to do things that were previously accomplished through work-arounds), while one requires a semantic change that would break compatibility.
1) The Windows 95 plus pack did not have actual anti-aliasing. It was a font-smoothing hack that was turned off by default. Back then, the best font rendering was from aliased, well-hinted Truetype fonts, which Freetype (with bytecode interpreter) could render identically to Win9x.
2) Microsoft's anti-aliasing in Windows 2000 is also a hack. It's not based on a compositing model and doesn't provide windows with a complete alpha channel, just a single alpha attribute. The latter, in particular, makes it mostly useless, because you can't have solid text in an otherwise transparent window (eg: like MacOS X's terminal). It's really just a well-implemented version of the "transparent window" tricks GNOME and KDE use now.
I don't think you understand. That's all that XFixes is! It's an extension containing various "fixes" to the core X functionality. That's it. That's why they seem like little things that aren't related --- because that's precisely what they are.
See this post for more context.
Who is making apologies? Some dipshit complained that OSS display technologies are a decade behind the competition, and I pointed out that they aren't. If I'm apologizing for X not having a fully GL-accelerated server right now, maybe some Windows "advocate" should apologize for WinXP lacking the same things.
Um, what does GDI have to do with this? We were talking about Quartz extreme. GDI is irrelevent to this discussions for two reasons:
1) It doesn't have the same imaging model. GDI is a 2nd generation display technology. Cairo and Quartz2D are a third generation (resolution-independent) display technology. GDI doesn't do anti-aliasing either.
2) Most drivers don't accelerate the curve and gradient portions of the GDI. GDI+ was designed to foster that, but nobody accelerated that either. That's why Microsoft just decided to use Direct3D to accelerate Avalon.
In practice, GDI doesn't accelerate anything that XAA (XFree86's acceleration layer) doesn't. However, while 2nd-gen apps were fine with acceleration of aliased-lines, and simple fills and blits (which is what GDI and XAA provide), such meagre functionality doesn't cut it for 3rd gen display technologies like Avalon, Cairo, and Quartz.
1) You were the prick for calling OSS developers monkeys.
2) There are a million and a half OS X themes for every OS. Slashdot just happend to post a screenshot from some random user that happend to use one. It's not like GNOME 2.8 released with Aqua icons as the default! Heck, it wasn't even an official press release!
You have to remember that screenshots aren't really accurate. I use 9pt fonts, but people always complain about huge fonts in my screenshots because I use a 133dpi monitor and most people use a 96-100 dpi monitor. So if the person has a high-resolution monitor, their fonts will likely look bigger to you than they look to them.
It won't be fixed completely. It'll be fixed for moving windows, but double-buffered resizing requires functionality from the composite subsystem that isn't there yet. A synchronized resize, like OS X, looks like this:
1) Composition manager saves the current window buffer.
2) Application is signaled to start the redraw.
3) Composition manager keeps displaying the saved buffer, while directing rendering to the new buffer.
4) Application signals end of rendering.
5) Composition manager replaces old buffer with new buffer, and frees the old buffer.
Currently, the ability to do step (1) isn't in composite, and toolkits don't support step (4).
(try resizing your window very fast with content visible)
Depending on your configuration, this will be made much better when toolkits and WM's are updated to support XSYNC additions to the netwm standard. Fedora Core 3 Test-1 has then by default, and it makes things look a lot better. It's not as good as Windows yet (GTK+ is just so slow), but it's better. The xsync stuff makes KDE on a par with Windows for resize (on my 2.0GHz P4).
Freetype is an excellent font-renderer. You need a goot set of fonts. The only decent free ones are the Bitstream Vera set --- if you can afford it, I recommend springing for some quality Adobe or Monotype fonts. Of course, you can always just use Ariel and Tahoma from your XP install!
See here.
There isn't an official time-table, just the information I've gleaned from lurking on mailing lists and whatnot. If you look at the xserver mailing lists from around this winter, you can piece together the basic plan.
Of course, the key piece here is Cairo/Glitz, which is already quite usable.