Re: 7 Places Where Mac OS X is Still Behind Windows
- From: websnarf@xxxxxxxxx
- Date: 25 Jul 2005 23:32:54 -0700
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. The problem is
actually relatively simple and could have been offered much earlier,
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?
> [...] 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.
And the reason why you think this was only done a few years ago, was
because DVD only came to the Mac a few years ago. PCs have been able
to play DVDs right from their very introduction which was around 1998.
> 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 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, 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.
> 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.
> [...] For example, say you
> want to scale a 137x201 pixel image. Oops, all early consumer 3D
> hardware had either broken support or no support at all for textures
> whose dimensions were not a power of 2.
Ok retard. The power of 2 limitation was something that was unique to
3DFX. 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.
> 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.
> [...] You have presented a simplistic view
> in which antialiased 2D primitive rendering is completely equivalent to
> filtered downsampling from a higher resolution image.
This is the most obvious and simple solution. Its not the only one.
> [...] 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.
> You're also assuming the Quartz 2D primitives are compatible with GDI.
No I am not. Obviously things like down-sampling would probably have
tapped into the 3D engines of most systems when it first became
available. But since Apple simply wasn't a played in accelerated
graphics back in those days, it just didn't matter.
> 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.)
> 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.
> [...] (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 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.
> > > 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.
> [...] 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.
> > Accelerated downsampling, as an alternative, I saw in nVidia cards at
> > around 1996.
>
> Remarkable how the previous "early 1990s" claim actually turns out to
> mean 1996.
If down sampling was done in software in the early 90s, then trust me,
every graphics vendor would have implemented a solution far earlier.
It was just a chicken and egg thing. Downsampling was the only thing
missing.
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.
> > > As it happens, the enabling technology for Quartz 2D Extreme comes from
> > > the _3D_ section of recent video chips.
> >
> > The UI needs perspective correct Z for windows?!?!
>
> And here's where you go off the deep end.
>
> No, the UI does not need perspective correct Z.
>
> None of this has anything to do with the UI. It's about another layer
> of the system.
>
> We're talking about 2D primitives, here. Lines, circles, etc. The
> MacOS X GUI is actually built mainly using bitmaps, not line/vector art.
>
> If you want to accelerate the drawing of 2D vector art, and you have an
> advanced 2D imaging model whose needs cannot be met using the classic
> GDI-oriented 2D hardware, what you need is either hardware designed for
> your own 2D API (not going to happen with Apple's marketshare), or
> hardware which is sufficiently programmable that it's possible to use
> the same rasterization algorithms as your software implementation. In
> short, a system where it's possible to move some of the software to run
> on the GPU instead of the CPU. And shaders, while usually identified
> with 3D, are the answer to that problem.
Right because OpenGL is oh so new to graphics cards.
> > > [...] It has become possible to
> > > implement fully accurate Quartz 2D rasterization using shader programs.
> > > It can't be done on first generation shader hardware like Radeon
> > > 8500/9000/9100/9200 or GeForce 3/4, but the more recent cards have
> > > sufficient shader program length and control over the precision of
> > > calculations to pull it off.
> >
> > This is completely retarded.
>
> 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.
> [...] You are pretty
> arrogant if you think that you know better than the graphics teams at
> both Microsoft and Apple.
Than Microsoft -- for sure; I helped implement the stuff for them.
I've worked with ex-Apple employees on graphics acceleration; and I've
had to educate them. But this was in the mid to late 90s. I don't
have first hand knowledge of what Apple has done since then, but if
they don't have an accelerated GUI, then obviously not much!
> [...] (And at ATI and NVidia, for that matter --
> they've been enhancing 3D pipeline capabilities to make them more useful
> for 2D for some time now.)
>
> > Shaders allow you to deliver highly complicated *3D* effects.
>
> 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. 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.
> [...] 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. My complaint is about what
Apple has not done for the past 7 years. Not what they could do
today.
> > There is no graphics effect in OS X, that cannot be done with
> > accelerated 2D (and with a speed that always stayed ahead of any UI
> > task on top of it). Its just a matter of some effort and design to
> > write the software to do it.
>
> You are wrong. Deal with it.
In this case, this is extremely unlikely.
> > 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.
> > > Everybody makes security mistakes. The question is, what's the response
> > > to them? Hide your head in the sand, which is basically what Microsoft
> > > did prior to XP SP2? Or do something better?
> >
> > Microsoft has not been hiding its head in the sand.
>
> Really? Then why did they leave system default settings (for things
> like which services to start, etc.) at such horribly inappropriate
> values for so long? Why, prior to SP2, did they have a near-formal
> policy of almost never making any security improvements which might
> break a handful of badly written applications? Why did they spend years
> and years doing amazingly dumb things over and over again, like adding a
> seemingly infinite number of ways for numerous applications to
> auto-recognize and run downloaded code with no user intervention?
Because they did not realize there was problem. I am not defending
Microsoft on thier problems with security, but as soon as the issue
became something that was highlighted as it is today, they have
definately reacted to it. Your question was about response. Microsoft
is responding, regardless of what you think of that response.
> That's right, because they were pretty much ignoring the problem. It
> wasn't until after SP2 development began that Microsoft as a company
> belatedly began to realize it couldn't afford to be lazy about security
> any more.
You don't recall Microsofts "month of bug fixing"? Or their numerous
attempts to engage with the "hacker community" to try to deal with bug
disclosure? Microsoft has been working pretty seriously on security
for around 4 years now. As a response to Linux of course (which is
secure by design.)
> [...] (This is why SP2 took so long to finish; I recently read an
> interview with the project's manager in which he mentions that it
> started out as a much smaller scale project which grew into a monster
> once security became a major focus of the patch.)
>
> I am sure there always were some people worried about security inside
> MS, but prior to SP2 the visible actions of the corporate whole were
> very ostrich-like.
The record does not match this. Again, I am not defending Microsoft.
But certainly they recognized and started responding to the problem
quite some time ago. (The real issue is the *quality* of their
response.)
> > 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. Even Safari "open sourcedness" is a bit
questionable since the Konqueror people are having a hell of a time
reintegrating the patches from Apple.
> If you look at Apple's security patch notes, a high percentage of them
> are actually patches to open source software bundled with MacOS X, such
> as Apache. Most of the remainder are patches to components of MacOS X
> which are open source.
>
> Are there parts of MacOS X which are closed source and impact security?
> Yes, of course. But it's hardly the picture you paint where Apple
> relies 'heavily' on obscurity to present an illusion of security.
But the important point is that this has not been tested. Apple just
has too small of a marketshare. This recent Dashboard problem seems to
indicate that at least some of its design was not reviewed by security
conscious people. So we know that Apple's design process is hardly
bullet proof.
Compare this to Linux, where this sort of thing *can't* happen.
Because if it does, word gets out, and people stop using whatever
feature is causing problems then it gets fixed, in a public way that
everyone can see, and then maybe people start using the feature again
after its fixed in a way that can be thoroughly audited.
There isn't a comparison. Just like Microsoft, Apple, has to, to some
degree, rely on hope, obscurity, and the unaccountable but hopefully
good engineering of their developers. Its not a guarantee, and the
only thing so far that keeps Apple unscathed so far, is likely that it
is completely untested.
--
Paul Hsieh
http://www.pobox.com/~qed/
http://bstring.sf.net/
.
- Follow-Ups:
- Re: 7 Places Where Mac OS X is Still Behind Windows
- From: Timothy A. Seufert
- Re: 7 Places Where Mac OS X is Still Behind Windows
- References:
- Re: 7 Places Where Mac OS X is Still Behind Windows
- From: websnarf
- Re: 7 Places Where Mac OS X is Still Behind Windows
- From: Timothy A. Seufert
- Re: 7 Places Where Mac OS X is Still Behind Windows
- Prev by Date: Re: Dell Monitors
- Next by Date: Re: OSX vs XP
- Previous by thread: Re: 7 Places Where Mac OS X is Still Behind Windows
- Next by thread: Re: 7 Places Where Mac OS X is Still Behind Windows
- Index(es):
Relevant Pages
|
