Re: 7 Places Where Mac OS X is Still Behind Windows

Timothy A. Seufert wrote:
> In article <1122359574.663926.53160@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
> websnarf@xxxxxxxxx wrote:
> > Timothy A. Seufert wrote:
> > > In article <1122331259.941560.226800@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>,
> > > websnarf@xxxxxxxxx wrote:
> > >
> > > > Timothy A. Seufert wrote:
> > > > > For example, Quartz 2D draws practically everything with subpixel
> > > > > rendering (in other words, it's antialiased). To the best of my
> > > > > knowledge, no 2D graphics hardware does that. That alone required
> > > > > Apple to use software rendering.
> > > >
> > > > This is incorrect. Every graphics card from the early 1990s onward has
> > > > supported "off-screen" rendering. So there's no problem in just
> > > > rendering to a higher resolution offscreen buffer and down-sample the
> > > > result down.
> > >
> > > <Dr. Evil>
> > > Riiiiight.
> > > </Dr. Evil>
> > >
> > > No, you couldn't do that in the early 1990s. Offscreen rendering, yes.
> > > Downsampling, no. Especially not filtered downsampling.
> > >
> > > In fact, you probably couldn't do it up until a few years ago.
> >
> > nVidia had this working in hardware around 1997. Other vendors, such
> > as Matrox may have had it working even earlier.
>
> 1997 is not very 'early 1990s', is it?

That's when I saw it first appear. That's not when it was first
possible. We were doing it in software in 1993, only because there was
so little demand for it -- certainly not from Apple.

> > The problem is
> > actually relatively simple and could have been offered much earlier,
>
> The problem is simple if and only if you want to support nothing more
> than the easy cases, like 2^N x 2^N source pixels averaged to 1 output
> pixel. (Sum and shift right, ho hum.) To support arbitrary scale
> factors with high quality filtering algorithms, you need a lot more
> gates.

Gates that were certainly available. You can program up the horizontal
taps, and feed the vertical ones one scan at a time, and voila! Done!
The technology to do that was well within the accelerator vendors
capability whenever someone wanted it.

> But we're concerned with what happened, not what coulda happened.

What happened, is that Microsoft drove the accelerator technology,
because Apple didn't think to make even one single request. Its true
that accelerator companies would not have done a whole architecture
just for Apple (except possibly Radius) but a modification here or
there that the accelerator companies could see Microsoft eventually
adopting, would certainly have been something interesting to these
companies. (Even though, MS never adopted downsampling, the graphics
vendors would not necessarily have been able to assume this, and MS
might have changed its mind if all the accelerator vendors were
implementing it.)

> [...] The reality is that not even the simple version was available in
> the early 1990s.

Nobody was asking for it! I remember a coworker writing up a paper and
software simulation for it, and thinking it was cool, but lamenting
that there didn't seem to be a way to get it utilized by anyone.

> [...] And the complex version was only available through the 3D
> pipeline (with significant lack of generality) or the video overlay and
> whole-framebuffer scaling functions (same comment) in the late 1990s.

It doesn't occurr to you for one second, that there it isn't any easier
to implement scaling in overlay than it is into a blitter.

> (And those fixed functions were far from universally useful. If you
> were unlucky, and it was easy to be unlucky because your average PC
> notebook vendor didn't use the better chips, you got a video chip in
> your notebook which did no filtering at all when stretching a low
> resolution to native res. The result was so bad as to be nearly
> useless.)
>
> > but it was not part of the architecture being worked out between
> > Microsoft and the graphics vendors.
> >
> > Either way, as an alternative, you can down sample the stuff in
> > software, which is essentially what Apple was doing up until the latest
> > release anyways isn't it?
>
> ROTFL! For somebody who goes on to claim superior graphics expertise,
> you sure seem to be ignorant of the basics of antialiased rasterization.
>
> No, Paul, that isn't likely to be what Apple was/is doing in the
> software Quartz 2D rasterizer. There are far better techniques.

Just the downsampling you numbnutz. Fast enough PCs can still do this
at a reasonable clip. The point it is that doing this would have
eventually motivated graphics vendors to provide an accelerated way of
doing it.

> Let's try a little thought experiment to demonstrate the quality and
> performance problem. Consider the simple case of an intermediate
> aliased rasterization step at twice the linear output resolution (4x the
> number of pixels). Say you want to draw a 100% black primitive against
> a white background. Rasterization may turn zero, one, two, three, or
> four pixels 100% black in any given 2x2 block in the intermediate
> buffer. Thus, averaged output pixels may have 0%, 25%, 50%, 75%, or
> 100% intensity.
>
> But if you plot (at infinite resolution) the rectangle representing the
> primitive's outline, overlaid upon the output pixel grid, the line may
> actually cover an arbitrary percentage of any given final output pixel.
> Therefore, increments of 1/4 full intensity are nothing better than a
> crude approximation.

1) Nobody says you have to limit yourself to 2x2 increase.
2) You can use tiling so that 4x4, say, doesn't chew up memory you
don't have.
3) Infinite is completely unnecessary -- the channel resolution is only
256 levels anyways, so more than 16x16 doesn't even make any sense.

> In order to get full range from downsampling, you have to use absurdly
> high numbers of pixels in the intermediate buffer. For example, in the
> common case of 8 bits per channel, you'd have to render at 16x linear
> resolution (256 intermediate pixels per output pixel) to get full 8-bit
> output range. The computational and memory costs for doing so are, to
> put it mildly, considerable.

You have never heard of a technique called tiling? As I said, you have
to sit down and think about it, but its certainly quite doable.

> Examples of better techniques: One is the obvious one. Simply
> calculate a coverage percentage from the geometric intersection of a
> primitive with each pixel box.

Bzzzt! This doesn't correctly deal with the difference between tiled
and overlapping primitives.

> [...] There are known methods of doing this with much less computation
> than you'd expect.

Yeah, accumulation buffers is the standard solution. Anyways, none of
this matters for 2D.

> [...] Another is to do much the
> same, only modeling pixels as partially overlapping circles, with
> non-linear intensity weighting based on distance of each pixel center
> from the primitive's interior. Gives higher quality results than
> modeling pixels as boxes, especially if the output device is a CRT.
> Once again, there are tricks to do it more efficiently than the
> description would suggest.
>
> I don't know exactly what Apple does in Quartz 2D. But I do know
> they're not likely to have been using the brute force method.

Its actually the easiest solution (using tiling of course), its
completely general, and there's no amount of complications that Apple
could throw at modern hardware that would ever be noticed by an end
user from a performance point of view.

> [...] It delivers either horrendous performance or low quality.

Its perfect quality. Here's an example of an 4x4 grid:

http://www.pobox.com/~qed/sines.tif

Notice how some of the osculating lines gradually seperate with
sub-pixel accuracy.

> [...] Whenever I have
> seen graphics guys from Apple talk about where they want Quartz 2D to
> lie on the performance-quality tradeoff axis, they always say they're
> heavily biased towards quality.

Then the brute force solution is the most obvious solution for them.

> > > [...] The
> > > early examples of chips with 2D resampling hardware typically had it as
> > > a dedicated-purpose function for one or two features. One was to scale
> > > the entire framebuffer to the native resolution of a digital display
> > > (often with no filtering, ugh), a feature found mainly in notebook
> > > graphics chips in those days. The other was video playback
> > > acceleration, where there was hardware to support an overlay plane so
> > > that a single video stream could be scaled and overlaid on top of the
> > > main frame buffer. Both of these kinds of resampling were (so far as I
> > > know) actually performed on the fly in the video refresh section of the
> > > chips, so you couldn't use either one to perform arbitrary operations on
> > > offscreen buffers.
> >
> > No they were done in the frame buffer, not just the overlay. The DAC
> > doesn't have enough time to do it in a general way for all modes. So
> > its pointless to do it that way.
>
> Regardless of whether it was performed in the DAC, it was not general
> purpose. For example, I have technical documentation for Rage 128 and
> Voodoo3, two important chips from the late 90s. I find no evidence of
> general purpose 2D resampling engines in either case. (By general
> purpose, I mean hardware which you could use to scale any arbitrary size
> offscreen buffer at any time.)

That's because you don't need to. Scaling actually only needs to
support the range of [.5, 2]. Why this is so is left as an exercise to
the reader.

> > > Even today, I'm not aware of any GPU offering a general purpose 2D
> > > resampling engine.
> >
> > You've never heard of nVidia or ATI? They both can do it, and have
> > both been able to for about 7 years.
>
> You know what? I suspect you are just talking out of your ass. To some
> extent I am too, but at least I know that I've seen some technical
> documentation for a couple chips inside that time frame, with nary an
> indication of what you're talking about. Care to prove me wrong, using
> references? (It has to be a general purpose 2D function to win points.)

Direct X multimedia layer. Look it up.

> > > [...] You have to use the 3D section of the chip, using the chip's
> > > ability to resample 2D textures stretched across polygons.
> >
> > That's the way nVidia did it,
>
> Wait. I thought it was Eeevul Bad Mojo to use 3D for 2D in the Paul
> world.

When did I suggest this? nVidia hid this in their drivers, so its not
like it was a relevant detail to anyone who wanted to use it.

> > but how it is done is kind of irrelevant
> > -- it is generally applicable. Remember in the PC world, accelerated
> > 3D is a fairly ancient technology. It only seems new to you, because
> > Macs have not had a 3D solution until relatively recently.
>
> Oh man, you're killing me. With laughter.
>
> 3D acceleration is about 10 years old on the Mac. It debuted in the
> form of Apple's QuickDraw 3D Accelerator PCI card, which used 3D accel
> ASICs designed internally by Apple, not off the shelf parts from the PC
> industry.

That's interesting. Not even SGI had a texture mapping accelerator 10
years ago. Was this a Turien, or Kubota or ShowGraphics part? I
thought those things cost 10s of thousands of dollars. The first
commodity texture mappers were 3DFX and Rendition parts which shipped
in 96 or 97.

> [...] Those were the days when Apple was still large enough to do
> their own thing, from API all the way down to hardware. Of course,
> doing their own thing wasn't always the best course, QD3D being a case
> in point. In any case, the QD3D Accelerator debuted in 1995 or 1996.
> It's hard to tell which from my brief scan of googleable resources on
> the web, but I suspect it was late '95.

But was it a texture mapper? I mean even S3 had a gouraud shader in 95
and claimed to the world first 3D graphics accelerator. But nobody
ever took that stuff seriously.

> I personally began using a Voodoo 1 card in my Mac sometime in '96 or
> '97. Probably '97, but my memory is not totally clear.

That seems highly unlikely. The Voodoo 1 didn't get Mac drivers for at
least 1 year after the part debutted for the PC.

> And Apple began shipping 3D acceleration as a standard feature in the
> PowerMac G3 in 1997.

This is not true. I remember this true idiot Joe Ragosta harping on
about some Apple system he was building that cost him $3k and had no 3D
graphics card in it. Which is not surprising since there were no 3D
applications that ran on the Mac yet. Apple didn't pay attention to 3D
until *after* Quake (which did fully software based 3D) was ported to
the Mac which happened in 1997.

> > > And here you run into really big problems with the idea that it's been
> > > doable for an extremely long time: before ~2002, 3D hardware had too
> > > many limitations to use for this kind of thing.
> >
> > What the hell are you talking about? In 2000, 3D graphics vendors were
> > so bored with what they had already solved that they decided to take
> > over CPU functions and add massively parallel floating point engines.
> > Pixel sampling, has been in Windows compatible accelerators forever.
>
> So let me get this straight: because 3D vendors began to take over "CPU
> functions" in 2000 (whatever that means -- any portion of 3D rendering
> is arguably a "CPU function", since it can all be implemented in
> software), that proves every other feature was already perfect in every
> conceivable way, with no room for improvement?
>
> I don't think so.

The pixel oriented operations were mostly done. Bump mapping,
displacement mapping, and finally shaders were yet to come. But
trilinear, and anisotropic filtering was already available. So really
good downsampling at amazing speeds was certainly available.

> > That company ceased to be at the end of 2000. It also has no
> > effect on the problem at hand since you can just over size the texture
> > and chop off any unused parts. It was really a memory consumption
> > issue, not a real limitation.
>
> Memory consumption issues aren't real limitations in your world?
> Fascinating.

Not for completely solved problems -- like 2D graphics.

> Back in the real world, this is a major problem. You're proposing that
> every active 2D rendering context have an intermediate buffer occupying
> a minimum of 4x the memory of the final buffer,

No. Only 4x (or in fact 16x) *tile size* rendering. It actually does
not increase the bandwidth (beyond source images) at all. Though it
does increase rendering bandwidth, which for 2D you can practically
assume you have an infinite amount of.

> [...] plus a substantial chunk
> more (on average) to get up to the next power-of-2 dimension.
>
> Worse yet, all this memory has to be on the video card. You do realize
> that we're talking about time frames before 128MB or even 64MB of VRAM
> were common, right?

This solution doesn't even need more than 1K of extra memory. ATI's
on-chip caches (at the time) were, in fact, perfect for this.

> > > But even assuming older hardware had usable filtered resampling, and
> > > handwaving away the considerable problems with getting identical results
> > > across all hardware when using the old fixed-function 3D pipelines to
> > > scale bitmaps, there are issues.
> >
> > This is only an issue if you are reading back from the display buffer.
> > But if you do that, instead you can down sample the offscreen buffer
> > *in software*. The fact is that readback from the screen to system
> > memory is *ALWAYS* slow, so applications will avoid doing it anyways.
> > So you can provide an essentially pixel accurate answer, that can
> > theoretically cause about a 1-shade off error on the actual screen.
>
> That last sentence does not logically follow. What the hell does
> readback performance (or the lack thereof) have to do with the accuracy
> of downsampling as an antialiased rasterization technique?

The *ACCURACY* is only relevant from a software point of view to
applications that read back the result. Output results just have *look
right*. If you were to actually look at the values in the example
image I gave above, it would be wildly off of what the values in each
channel are *supposed* to be. But optically, my eyes can barely spot a
difference from, say, a 16x16 sample version of the same image.

So for output results, you do what is good enough for the eyes. Then
when an application attempts get the real data, you give it what it
would have been in theory if you had more resources for the display.

> > > [...] Not so; many
> > > imaging models have formal specifications for how to render antialiased
> > > primitives without that intermediate step, and frequently the resulting
> > > output is NOT the same, because the specifications actually try to do a
> > > bit more. Such as having special rules for how to color partially
> > > obscured pixels near line intersections in order to improve the visual
> > > appearance of the intersection, and so forth. You simply cannot emulate
> > > this kind of thing through brute force downsampling.
> >
> > But brute force downsampling is the *best* such solution. Matrox
> > attempted an "edge mask" method a few years, but people complained that
> > it failed to work properly at least as often as it worked correctly.
>
> Approximations and shortcuts in 3D rendering hardware don't always work
> perfectly! News at 11!
>
> You are only strengthening my argument by mentioning this. This is one
> of the fundamental reasons why Apple must use shaders. If you follow 3D
> accel closely, you should know by now that part of the reason the pace
> of innovation in the consumer 3D industry has been so fast was that the
> APIs had loose output requirements, allowing plenty of implementation
> freedom.

Yes, this was a big deal up until about the year 2000. It was when
Tom's Hardware Guide and AnandTech started doing the whole side by side
comparison thing, that all the graphics vendors decided they had to get
in line or suffer a lashing from these on-line review mags. By the
time Mac OS X shipped, all the vendors output very high quality and
optically identical results.

> > > You're also assuming the Quartz 2D primitives are compatible with GDI.
> >
> > No I am not.
>
> Yes you are. You've been criticizing Apple for failing to use hardware
> which accelerates GDI 2D primitives. It necessarily follows that you
> assume compatibility.

No. It. Does. Not.

First, you can construct more advanced primitives from the ones the
accelerators started with. Second, the accelerators generally
supported more modes and functions than Microsoft ever used (it was
just a matter of generality.) Third, accelerator vendors were probably
willing to do small tweaks, or simple features for Apple, if Apple just
had the brains enough to ask for them.

> > > Most 2D APIs have differences in how they handle line joints, end caps,
> > > and countless other small details. Due to such differences, it's
> > > probably not possible to render Quartz 2D primitives using classic GDI
> > > acceleration hardware, and since that's a key first step in your
> > > proposed technique...
> >
> > Line ending matching is a well known problem, and GDI basically solves
> > it in the only sensible well known way (using the left->right,
> > top->down tiling assumption.)
>
> Sigh. That's not what I'm talking about. I'm talking about things like
> how you draw beveled, mitered, and rounded end caps and joints. And I
> should have mentioned a more important issue: coordinate systems. GDI
> uses integer coordinates. Quartz 2D uses floating point. So GDI
> hardware isn't real likely to support the coordinate precision available
> in Quartz 2D.

None of these differences pose any problems to the downsample solution
I have repeated here over and over. CAD programs on Windows always did
these things with polylines. Once again, the downsampling idea makes
this work for a GUI with no trouble.

> > > By the way, it's not as if Apple was incapable of using the GPU to
> > > up/downsample or otherwise manipulate 2D bitmaps. They've been doing
> > > that in the window buffer compositing part of their graphics system
> > > since OS X 10.2.
> >
> > If that's true, then they have no excuse for not having had a 100%
> > accelerated GUI for the last 7 years.
>
> You keep veering back to the GUI. Apple's GUI is drawn with bitmaps,
> not line artwork. The most important function for accelerating the GUI
> is support for the blitter, in order to speed up scrolling, and they've
> had that since 10.1 or so.

10.1 eh? On Windows it was 3.1. PCs may have been slow to catch up to
Atari and the Amiga, but at least they made it in prior century.

> > > [...] (Not coincidentally, that was just about the time when
> > > 3D hardware with non-power-of-2 texture support had become prevalent.)
> > > They restrict use of scaling to situations where precise control over
> > > results is not relevant, such as Expose; otherwise the system is
> > > typically doing point sampling, where you don't have to worry about
> > > different hardware producing different results.
> >
> > You knowledge of graphics accelerator history is extremely shakey. As
> > someone who has worked at two different graphics accelerator companies,
>
> And what, pray tell, was your job description?

Driver developer (MTS, senior engineer, whatever.) At Chromatic, this
meant more than just building glue code, since it was a completely
programmable part. So in addition to being intimately familliar with
how the hardware works, and developing the drivers, I would explain
things to the people who wrote the documentation that people like you
might eventually read.

I have these two links to corroborate my claims:

http://tinyurl.com/9olpj
http://tinyurl.com/7px9p

> > and other companies who has access to graphics driver source code, I
> > can assure you Apple has no good reason, and has never had a good
> > reason for not having a 100% full accelerated GUI. Power of 2
> > dimensions is a non-issue. But you don't need my kind of experience to
> > know that -- you just need to think about it for 2 seconds.
>
> Your 2-second thought processes do not seem to have led you to correct
> conclusions.
>
> > > > > But even if some form of antialiasing was present in the hardware,
> > > >
> > > > Every graphics card has had anti-aliasing since about 1999.
> > >
> > > The above was in reference to 2D acceleration hardware, not 3D.
> >
> > The first 3DFX solution to this has no relation to 3D or 2D. It was a
> > frame buffer architecture. In any event, there isn't a Chinese wall
> > between 2D and 3D. There's no reason you can't use a 3D primitive to
> > produce a result used in 2D.
>
> So it's OK for Apple to use fixed function 3D pipeline features to do
> 2D, but not OK for them to use the programmable stuff? Bizarre.

It *WASN'T* ok, because it *didn't exist*. Try to follow the thread.
Today, Apple can do whatever the hell they want since the technology is
different. But you don't need shaders to do anything that's 2D. You
just don't.

> > > [...] Do you know of even a single card available _today_ which
> > > implements antialiased line drawing in its 2D engine?
> >
> > Every card that supports OpenGL. That would be all of them.
>
> I said _2D_ engine...

OpenGL includes 2D.

> But since you bring up GL AA lines, I've learned through both my own and
> others' experiences (watching traffic on OpenGL mailing lists, etc.)
> that they're a total crapshoot, particularly for line widths other than
> 1 pixel. Quality, results, and performance are extremely variable
> across different hardware, including different generations from the same
> vendor.

And how many vendors did Apple support? Look, Apple is in control of
their hardware -- they just have to make sure 1 vendor makes it work,
and otherwise simulate it in software. This will force any other
vendor that wants to compete for Apple's business (and they all *were*
interested in Apple's business, believe it or not) to do it "right" or
at least "the Apple way".

> And before you stick your foot in your mouth again, no, the personal
> experience wasn't under MacOS X. Our main platform was Linux. I did
> eventually get the program up and running on MacOS X (it wasn't
> difficult since we used SDL), but that was long after I had given up on
> using GL lines and switched to drawing long skinny rectangles instead,
> so I don't know how well GL lines would have worked on the Mac.

Its just a question of what Apple itself was willing to put effort into
by working with graphics vendors, who were willing to work with them.

> > In the early 90s I was working at a company that was implementing
> > graphics driver compatibility for Apple, and it was all completely done
> > with like 2 people in 2 months (our Windows drivers were two teams of
> > like 6 people each, and we worked on the drivers continuously). Not
> > because the company didn't care to support Apple, but because Apple
> > made practically no requests for any special functionality from the
> > graphics accelerators.
> >
> > Apple dropped the ball. They could have had downsampling, or any other
> > small set of features that they wanted, if only they were smart enough
> > to ask for them.
>
> Uh, Paul, you do know that MacOS 7 -- which is what they would have been
> working on in the early 90s -- would have had no use for downsampling?
> OS X is kinda a different operating system, you know. You may have
> heard about it. First shipped in 2001. It's what we're discussing.

Ok, well every graphics vendor has certainly had downsampling since
2001, so what's Apple's issue?

> (But it's also worth noting here that QuickDraw in 'classic' MacOS was
> notoriously difficult to accelerate. As I understand it, QD was a
> synchronous API -- primitives were guaranteed to be drawn before each
> API call submitting a primitive returned. This was a reasonable design
> choice in 1982/83, but it later turned out to be very bad for HW, since
> you want to queue up a bunch of commands and let the HW work
> asynchronously. Without pipelined throughput, hardware was often slower
> than software, so QD 2D accel drivers tended to use the hardware for
> little beyond blitting. Merely one of the numerous reasons why classic
> MacOS had to go away...)
>
> > > You must think Microsoft is retarded, too. After all, this is the same
> > > thing MS plans to do in Avalon, their next generation graphics system.
> > >
> > > Maybe you might want to consider the possibility that when smart people
> > > a lot closer to the problem than you decide to do something which you
> > > don't understand, you might be the weakest link?
> >
> > Closer than me? To graphics acceleration? Perhaps you would like to
> > cite such a person? There certainly are some, but I know a hefty
> > percentage of those people.
>
> Ah, now we get to the heart of the matter. Your ego is wounded. You
> cannot accept that you did not know where the industry is headed,
> because your self-image depends on thinking of yourself as an Expert.
>
> > > Your thinking is so very limited. Shaders are nothing more or less than
> > > miniature CPUs optimized for the problem space of manipulating small
> > > vectors and calculating pixel values. You can use them for 3D... but
> > > you can also use them for 2D rasterization. And why not? The
> > > hardware's there, it's got tons of FLOPS and IOPS, presently sitting
> > > idle when you're not using it for 3D. Might as well find a way to put
> > > it to work on 2D.
> >
> > Ok, you are the last person that I need a lesson in graphics from. The
> > way you are talking, it sounds like you don't realize the 2D is
> > *ALREADY* done with shaders.
>
> I'm well aware that many functions which were formerly dedicated
> hardware are now privately implemented in the drivers as shader
> programs. I hadn't been aware that traditional 2D functions like the
> GDI accelerator (I assume that's what you're talking about) were being
> done that way, but I'll take your word for it.

Its just a matter of cost. Custom 2D hardware is a boon dongle, and
nobody measures 2D performance anymore, since it basically runs at
infinite speed, whether you are using the 3D engine to do 2D operations
or custom.

> > That's not the point. You *can* solve
> > the problem with shaders if you want, but its a big waste of time. I
> > don't clip my nails with a howitzer. And you don't need to blat out 2D
> > snot with a monster 3D engine.
>
> If it's such a big waste of time, why is the 2D already done with
> shaders? This just gets funnier and funnier.

The question is like asking why don't you write your webserver
application in assembly language, using SIMD instructions. Because its
retarded. Just use the high level primitives that match the problem at
hand.

> You want to play the role of a graphics acceleration god, but you don't
> seem able to maintain a coherent point of view longer than a sentence or
> two. Real experts don't flip-flop quite that frequently.

Its not me who's having coherence problem. You just have comprehension
problems.

> > > [...] What you aren't aware of is that the various players in the
> > > graphics industry, both software and hardware, have more or less
> > > collectively decided that the dedicated 2D section of GPUs is a
> > > legacy wart that will be used less and less over time.
> >
> > And yet somehow I am aware that this "seperate 2D part" is already gone
> > in at least one part that's out there.
>
> Try as I might, my abilities in mental gymnastics just can't square that
> claim with your earlier "This is completely retarded" crack and the
> subsequent rant about how horribly stupid it was for Apple to use
> shaders for 2D when everybody sensible was using the 2D part of the chip
> for 2D.
>
> Or is it bad only when Apple does it, and OK for everybody else?

The fact that 2D is being emulated by shaders is something *DRIVER*
implementers are concerning themselves with. Externally, system
developers like Apple still *see* a 2D API, if they care to use it.

> > My complaint is about what Apple has not done for the past 7 years.
> > Not what they could do today.
>
> The trouble is, said complaint is based on a
> brilliant-only-in-your-own-mind idea for what they should have done.
>
> > > > Graphics accelerator companies are not, and never have been the
> > > > limiting factor for development and design of user interfaces.
> > >
> > > Who said they were? Do you like just tossing out random strawmen?
> >
> > My point is, that if Apple has not been 100% acclerated for the past 7
> > years, they don't have anyone to blame except themselves. The idea of
> > using full graphics acceleration for rendering GUIs is such an old
> > problem to me, that I am just shocked that Apple wasn't already there
> > long time ago.
>
> When you want your 2D primitives to be more featureful than the 2D
> hardware of the day, you do without acceleration until the hardware
> catches up. It just turned out to be the case that the catching up
> happened in the 3D section of the chip.

But there is no feature in there that you need to use. If it aint got
Z, it just doesn't matter.

> > > > The two main
> > > > problems with Microsoft's response is that 1) they are bringing PR and
> > > > marketing along to help "solve" the problem via MS propaganda and 2)
> > > > they are taking a strictly firefighter approach to dealing with the
> > > > problem.
> > > >
> > > > The OS you have to compare with on security is Linux. Since its open
> > > > source, its has no choice but to be secure by design, not obscurity.
> > > > Both MS and Apple rely very heavily on obscurity as their security.
> > >
> > > You are so very ignorant. Much of the code in Apple's OS relevant to
> > > security (the kernel, system services, etc.) is in fact open source.
> >
> > And Applescript? Is that open source? Is the GUI open source?
> > Remember that if an application gets its dialog boxes hijacked, your
> > data cannot be considered secure. I thought the only thing open
> > sourced was Darwin.
>
> Enough is open sourced to make a bootable UNIX distribution.

I.e., not anything that is currently being tested in the field. What
matters here is that what is seriously being used in the field has been
audited or open sourced or something. Microsoft uses a BSD licensed
version of FTP -- that doesn't mean I trust Microsoft's who TCP/IP
stack to be secure.

When it comes to security, you can't look at just one piece of the
puzzle. Security just doesn't work that way.

> [...] None of
> the MacOS X GUI is there -- if you download a Darwin install CD you're
> going to be using the text console or X11 -- but the point is, unlike
> Microsoft, Apple can't rely on security by obscurity for many of the
> most vital components in the system.
>
> See
>
> http://www.apple.com/opensource/
>
> for a list of open source projects. You'll note that there are many
> explicitly security oriented projects in the list, starting with the
> very first one listed, CDSA.
>
> > Even Safari "open sourcedness" is a bit
> > questionable since the Konqueror people are having a hell of a time
> > reintegrating the patches from Apple.
>
> You haven't followed the latest developments, I see.

I barely follow Apple at all, its just when appaulling things happen to
spill over and catch my attention.

--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/

.

Quantcast