[Simon]

I'm afraid I don't understand this discussion. I have a 1GHz G4 with a 32MB 5200 GPU running Panther. So this is not a slow or old system, but there are also much faster Macs available.

Now, scrolling is perfect. It's fast, I don't see a delay and it's accurate. It is however line by line scrolling, so it's not perfectly smooth by definition. If I go to system prefs and select smooth scrolling it becomes smooth. It's still fast and it still works fine.

So, what is the problem with Panther's scrolling? Or is this just a problem for people on a 400MHz G3 with 8MB video?



[Edit: What I forgot: Yes, resizing could be faster. I don't know about it on G5s, but on my PowerBook it could definitely be faster.]

[Pierre B.]

There have been in this discussion good explanations for the scrolling or resizing issues under MacOS X, but there is one important detail left out: right now, 2D Quartz operations are NOT hardware accelerated under MacOS X. All these operations are executed in the CPU, while under Windows (and MacOS 9 and X11 of course), this is a work for the GPU or the graphics chip. Right now, there is no graphics hardware capable to fully accelerate MacOS X graphics layer. According to this ArsTechnica article, Quartz is a third generation display layer; comparisons between generations of graphics layers are made in the same article. Quartz Extreme helps the compositor, not the 2D system operations (notice in the previous Apple 2D graphics performance example that they talk about window move, not resizing; why? simply because the window parameters are already calculated by the CPU and stored in memory, and the move operation can be now handled by the GPU). In the Quartz Extreme pages Apple had in the past a very informative pdf explaining more about Quartz Extreme and the compositor, but I don't find it now.

Ironically, the only hope to see one day graphics hardware capable to accelerate Quartz, would be the introduction and mass adoption of Longhorn, which seems to use something similar to display its graphics (but I am not sure).

MacOS X display technology requires hardware from the future. So, be happy with its actual performance on current hardware, since this means it is heavily optimized.

[stew]

Originally posted by Pierre B.:
right now, 2D Quartz operations are NOT hardware accelerated under MacOS X. All these operations are executed in the CPU, while under Windows (and MacOS 9 and X11 of course), this is a work for the GPU or the graphics chip.

While I still don't understand why that means that scrolling must be slower. If you can use the GPU to perform 2D acceleration in OS 9, why can't you in OS X? Blitting a bunch of pixels from A to B (=scrolling) is something gfx hardware can do since the 80s.
The only thing that a OS X web browser is doing different than an OS 9 browser is the text rendering (or, in the case of IE, not even that - QD all the way), all the rest is identical to a web browser in OS 9 or X11. Why can OS 9 do the exact same task faster than OS X?

[Pierre B.]

Originally posted by stew:
While I still don't understand why that means that scrolling must be slower. If you can use the GPU to perform 2D acceleration in OS 9, why can't you in OS X?...Why can OS 9 do the exact same task faster than OS X?

Now, I am not an expert to give a detailed and technical answer to this question, but the problem is that no graphics card/chip today can understand many of 2D Quartz functions. A second generation display layer can talk directly to the graphics card and gain ful acceleration, simply since today's graphics cards are build having this display system in mind. A third generation one cannot do that. Many of the funcions 2D Quartz uses, can only be interpreted by a CPU today. And this hurts 2D operations performance, especially window resizing.

There was a technical discussion over at ArsTechnica some time ago, about these issues. I cannot find a link to the discussion right now, but I remember they were saying that use of pixel/vertex shaders and other technologies, today found only on powerful GPUs, could improve things in the hardware acceleration front. Expect more to come as the graphics hardware evolves.

[stew]

That's no excuse, it's only an indication that OS X is doing things more complicated than necessary. If my graphics chip is good enough for fast scrolling in OS 9, it should be good enough for the exact same task in OS X too. If not, OS X is doing something wrong.

BTW, I am well informed about how and what OS X does in the background to draw the windows on screen. But since it does not make any visible improvement at all (you don't need QE and double buffering to draw antialiased text), why bother? The user experience is suffering, instant feedback is an essential part of good UI design. And IMHO, a good user experience should be the top priority.

[Pierre B.]

Just two links:

Quartz Extreme and Quartz 2D

Introduction to Quartz 2D

It is clear that: (1) Quartz Extreme is the hardware-accelerated Quartz Compositor and nothing more (see the diagram in the second link); (2) with the exception of window scrolling, Quartz 2D still remains in software. Well optimised, but still software.

[Pierre B.]

Originally posted by stew:
That's no excuse, it's only an indication that OS X is doing things more complicated than necessary. If my graphics chip is good enough for fast scrolling in OS 9, it should be good enough for the exact same task in OS X too. If not, OS X is doing something wrong.

Honestly, you can say so today. Perhaps not tomorrow.

[stew]

Tomorrow. People say that ever since 10.0. 10.1 was supposed to be as snappy as OS 9, and so were 10.2 and 10.3. Fact of the matter is, they're not. Will I have to wait until 10.7 until it finally becomes true?

[JLL]

Originally posted by stew:
Tomorrow. People say that ever since 10.0. 10.1 was supposed to be as snappy as OS 9, and so were 10.2 and 10.3. Fact of the matter is, they're not. Will I have to wait until 10.7 until it finally becomes true?

Apple made a forward looking technology in Mac OS X instead of implementing QuickDraw which then had to be dumped just a couple of years later.

MS is following the same path with Longhorn.

[Millennium]

Stew, it's time you learned a little bit about graphics, since it's obvious you know basically nothing at this point.

First things first, let's get our terminology straight. It's not "2-D" and "3-D"; it's "bitmap" and "vector". The difference is not just semantic; these are fundamentally different ways of dealing with graphics, and this difference becomes extremely important.

Pictures on your computer are made up of pixels; small squares of color (pixel is short for 'Picture Element', by the way). Each pixel is usually represented onscreen as three dots of color: one red, one green, and one blue (on a printer, the dots are cyan, magenta, and yellow). These three dots combine to form the square.

Bitmaps are really just huge chunks of data called arrays, which store the color that goes in each pixel. In English, we might right such a thing out as (red, green, green, blue, red), and so forth. The "2-D accelerators" we know of in Windows and OS9 are really bitmap accelerators. That is, they can sling these arrays around very quickly.

The graphics which go onto your screen are stored in a bitmap that's usually called the frame buffer, or something like that. It's just a chunk of memory which is set aside for holding exactly the data which is on the screen. Your graphics card then copies this frame buffer out to the monitor, usually 60-75 times per second.

The graphics systems of OS9 and Windows are bitmap-based. Basically, this means that they deal directly with the frame buffer. When you say "draw a line from 1,1 to 10,10", the computer writes the appropriate pixels directly onto the frame buffer and that's that.

Now, let's move onto vectors. A vector is nothing more than a set of data points. But unlike a bitmap, which states the exact value for each pixel, a vector describes a shape which is drawn in the image. So rather than having the exact pixel values for a line from 1,1 to 10,10, a vector simply notes that a line is there. Relatively simple vectors take up much less memory than a bitmap (since you don't have to store the entire picture), but they take more time to draw out since you still have to figure out what pixels go where. Also, because you know what the shapes are, you can manipulate them easily. A bitmap has no concept of "shape"; it just knows what pixels are what colors, so as soon as you draw something you lose the ability to do anything with it.

Quartz in OSX is vector-based. It still has a frame buffer, just as OS9 does; it has to, so that the monitor will know what to put onto the screen. But OSX doesn't work directly with that frame buffer. It notes the shapes in memory, instead. When the frame buffer needs to be updated, OSX then draws it based on the shapes that it has stored in its memory. This is obviously a little slower, but it is also obviously more powerful, because since OSX remembers the shapes it can do things with them that cannot be done with bitmap graphics. There is another common graphics system which is vector-based: OpenGL. In fact, all 3-D graphics systems today are vector-based. This is why we tend to call them "3-D graphics cards", when actually they're vector-graphics cards.

Up until now, vector-graphics cards have only been used for 3-D stuff. Quartz Extreme is an early attempt at getting these cards to do 2-D graphics. But since this has never really been done before, it's not very well-known how to program it. These are things which have to be discovered, rather than invented. It takes time. Accept this.

Why did Apple do this? For one thing, it actually simplifies graphics, by moving to a single system which all graphics APIs can share. It also means that many of the effects which have been applied to 3-D graphics over the years can be applied to 2-D graphics.

You say that your 2-D graphics card should be good for the exact same tasks in OSX as in OS9. Indeed it is. What you don't understand is that 2-D graphics is itself a fundamentally different task on OSX than it is on OS9. And that yes, OSX does it in a better way, but it is also a newer way, and so it will take some time to adapt.

[stew]

Originally posted by Millennium:
Stew, it's time you learned a little bit about graphics, since it's obvious you know basically nothing at this point.

Thanks for your trust.

Each pixel is usually represented onscreen as three dots of color: one red, one green, and one blue (on a printer, the dots are cyan, magenta, and yellow). These three dots combine to form the square.

If you want to teach me the very basics, do it properly. LCDs have four dots, green is double. And printers have an additional black ink.

The "2-D accelerators" we know of in Windows and OS9 are really bitmap accelerators. That is, they can sling these arrays around very quickly.

And guess what, they're awesome for scrolling. And since, as you told me before, everything on my screen is made of pixels, these chips are very fast at scrolling everything on my screen.

When you say "draw a line from 1,1 to 10,10", the computer writes the appropriate pixels directly onto the frame buffer and that's that.

No, they tell the graphics card to do that.

Quartz in OSX is vector-based.

Enter RDF.

It notes the shapes in memory, instead. When the frame buffer needs to be updated, OSX then draws it based on the shapes that it has stored in its memory.

As do the other systems too. Why do you think Windows' windows flicker when you drag another window over it? Because Windows is redrawing them, not pixel by pixel but line by line, character by character, shape by shape. Duh.
Shapes.
All that Quartz/Vector-babbles is mostly marketing blurb, and the notion that it's inheritantly slower is a sorry excuse. NextStep drew its UI in Postscript on 50MHz CPUs.
More Shapes.

This is obviously a little slower, but it is also obviously more powerful, because since OSX remembers the shapes it can do things with them that cannot be done with bitmap graphics.

Yeah, it can do cool things with my web pages like..uh..nothing. Web browsing in OS X is no different from OS 9, except that it's slower. There are no vectors in an HTML page (unless you're using Flash), and OS X is certainly not vectorizing the cute animated gif here:
All the Aqua buttons are bitmaps. All images on this web page are bitmaps. All icons on your desktop are bitmaps.

And it's not the Quartz compositor that's the bottleneck here. My computer can play fullscreen DVD and DivX movies fluently, and these tasks are by far more complicated than scrolling a web page.

Up until now, vector-graphics cards have only been used for 3-D stuff. Quartz Extreme is an early attempt at getting these cards to do 2-D graphics.

Before that, Blender has been using OGL to draw its UI for ages, and you could enable OGL-accelerated drawing for Java apps in OS X 10.1. Also, Be Inc had unreleased versions of their OS doing similar things.

[Millennium]

Originally posted by stew:
Thanks for your trust.

Thanks for your misinformation.

If you want to teach me the very basics, do it properly. LCDs have four dots, green is double. And printers have an additional black ink.

I was unaware of the doubled green -thank you for that- but even so, the three basic elements are maintained.

As for the black ink, that doesn't count, because the black ink is essentially a separate system, what with black being so common in print and so difficult to reproduce with the three primary pigments.

And guess what, they're awesome for scrolling. And since, as you told me before, everything on my screen is made of pixels, these chips are very fast at scrolling everything on my screen.

The chips do not "scroll"; that's just the thing. They don't know what scrolling is. They just draw the pixels they're told to.

No, they tell the graphics card to do that.

No, they don't; not in a bitmap-based system. They just offload areas of the screen to be redrawn -in their complete form, I might add

Enter RDF.

Exit your ignorance.

As do the other systems too. Why do you think Windows' windows flicker when you drag another window over it? Because Windows is redrawing them, not pixel by pixel but line by line, character by character, shape by shape. Duh.

Wrong, wrong, wrong. The reason that Windows has this problem is that it has only one framebuffer.

This leads to discussion of another graphics trick, known as double buffering. In this system, two framebuffers are used. The problem with a single framebuffer, you see, is that once you've overwritten any part of the screen, the old data for it is irretrievably gone. You have no way to determine (from a visual standpoint) what is "behind" a window unless you recalculate everything. This slows the system down, which produces the flicker you're seeing.

In double-buffering (another trick OSX uses), two framebuffers are kept. When the screen has to be redrawn, changes are first applied to one of the framebuffer. Any regions of the screen which need to be redrawn because of this are then simply copied over from the other framebuffer, rather than being recalculated. Finally, the first framebuffer is copied to the second, so that they're back in sync. This allows for clicker-free drawing, but takes up much more memory.

All that Quartz/Vector-babbles is mostly marketing blurb, and the notion that it's inheritantly slower is a sorry excuse. NextStep drew its UI in Postscript on 50MHz CPUs.

NeXT had its own little hardware-assisted tricks, basically adapting the PostScript hardware from printers in order to make things work right. Anyone from that era can also tell you that DPS hogged resources like nobody's business, not to mention the problem of security holes.

And if that isn't enough, DPS was also a much older vector-based model. Early versions didn't even support color. It never supported transparency -there was no need, since PostScript was designed for printers, not for screens- and that takes a huge amount of processing power. It wasn't double-buffered either.

Yeah, it can do cool things with my web pages like..uh..nothing. Web browsing in OS X is no different from OS 9, except that it's slower.

Irrelevant. It is true that Web browsing is not an area which makes particularly good use of vector graphics at the moment. That does not mean that vector graphics are not worthwhile.

There are no vectors in an HTML page (unless you're using Flash), and OS X is certainly not vectorizing the cute animated gif here: All the Aqua buttons are bitmaps. All images on this web page are bitmaps. All icons on your desktop are bitmaps.

Yes. Your point is... what?

And it's not the Quartz compositor that's the bottleneck here. My computer can play fullscreen DVD and DivX movies fluently, and these tasks are by far more complicated than scrolling a web page.

You are correct. DVD and DivX movies (and most other full-motion video systems) are inherently bitmap-based. The bitmap accelerator in your graphics card takes over for these tasks; Apple used to call this technique "QuickTime acceleration".

Before that, Blender has been using OGL to draw its UI for ages, and you could enable OGL-accelerated drawing for Java apps in OS X 10.1. Also, Be Inc had unreleased versions of their OS doing similar things.

Blender is an application, not an operating system. I fail to see what the other examples have to do with this topic.

Tell me, stew; have you ever so much as cracked a single book on how computer graphics work? You sound like some kiddie who's pissed off about something as insignificant as the smoothness of your window scrolling and, not understanding why, is instead making stuff up off the top of your head.

[Cadaver]

Microsoft's Longhorn OS will be just as "slow" as MacOS X on older hardware.
MacOS X's windowing system is smooth as silk on my dual 2.0GHz machine (thanks to its two independent 1GHz processor buses and 400MHz dual-channel RAM bus).

The windowing system of Windows (95-XP) were written to work quickly on legacy X86 hardware. X86 hardware has gotten very fast in the last several years, making this antiquated system run very quickly. Ever notice that Windows95 didn't support live window resizing? Why? Because the hardware at the time couldn't do it quickly. If a 2.0GHz G5 ran MacOS 9 (Classic may count), it would also seem blindingly fast.

The windowing system of MacOS X was written as a forward-looking system, designed to do things no current windowing system can (rotations, transparencies, alpha blending, etc). This takes horsepower... and yesterday's hardware simply wont do it justice. Enter new hardware (see first paragraph above).

Windows users will have to also shell out big bucks for system upgrades (or a new machine altogether) to make Longhorn run well, too. Microsoft has gone on record stating that when Longhorn is released, it'll require new hardware for users in many cases.

[stew]

Originally posted by Millennium:
Tell me, stew; have you ever so much as cracked a single book on how computer graphics work? You sound like some kiddie who's pissed off about something as insignificant as the smoothness of your window scrolling and, not understanding why, is instead making stuff up off the top of your head.

Yes, getting personal is surely getting us closer to a solution here and is always a good sign of good discussion manner.

FYI, I am a 4th year CS student, writing his thesis about that OS X distributed audio system I wrote. And if I am some pissed off kiddie, then I am some pissed of kiddie that worked in the CG software industry for a few years after reading and understanding books like Watt/Watt "Advanced Animation and Rendering Techniques".

Once you stop treating me as if I were stupid, I'd be happy to join an in-depth technical discussion where you explain my what exactly it is that makes a next-generation display interface on a 1GHz computer slow down scrolling.

[stew]

Originally posted by Cadaver:
The windowing system of MacOS X was written as a forward-looking system, designed to do things no current windowing system can (rotations, transparencies, alpha blending, etc). This takes horsepower... and yesterday's hardware simply wont do it justice.

Scrolling does not use alpha blending.
Scrolling does not use transparency.
Scrolling does not use rotations.
In fact, dragging a transparent terminal window is more fluid than scrolling in a web browser, because even the old iBook's Radeon 7500 GPU can accelerate transparency, alpha blending and rotations easily, and OS >= X.2 is using it to do that.

[Millennium]

Originally posted by stew:
Yes, getting personal is surely getting us closer to a solution here and is always a good sign of good discussion manner.

I'm merely trying to call your bluff. You claim to know much, but your arguments indicate otherwise.

FYI, I am a 4th year CS student, writing his thesis about that OS X distributed audio system I wrote.

You're writing a thesis as an undergrad? Which school would this be? Where can I find links to your system, given that you seem to assume I know about it, which would mean that information must be out there? And what does an audio system have to do with video? OSX is a complex system; that you know about audio in no way implies that you know about video.

And if I am some pissed off kiddie, then I am some pissed of kiddie that worked in the CG software industry for a few years after reading and understanding books like Watt/Watt "Advanced Animation and Rendering Techniques".

Where did you work? What did you do? What does that particular book -which deals with rendering software, not rendering systems- have to do with this discussion anyway? I find it interesting, by the way, that someone who "worked in the CG software industry for a few years" suddenly switched tracks to deal with audio, which is a very different beast.

[stew]

In case you missed it, this thread is not about me, the education system of the country I live in, my former employment or my choice of subject for my thesis.

This forum and this thread are about Mac OS X, and the specific topic we were discussing is the speed (or the lack of) of scrolling in various applications running in OS X. And frankly, I couldn't understand so far why you are refering to vectors, transparency and rotations when we're talking about scrolling a web page, which obviously does not involve anything of that (with the exception of font rasterization, which is usually derived from a vector description of the glyphs' outlines). So please, tell me what OS X is doing to render a web page that is more complicated than decoding DivX.

Do I really have to remind a moderator of this board to stay on topic?

[Millennium]

Originally posted by stew:
In case you missed it, this thread is not about me, the education system of the country I live in, my former employment or my choice of subject for my thesis.

Nice way to avoid my questions.

You said you knew more about graphics systems than your arguments would imply. I am asking where that knowledge came from. Thus far, I am not impressed.
[quote]This forum and this thread are about Mac OS X, and the specific topic we were discussing is the speed (or the lack of) of scrolling in various applications running in OS X. And frankly, I couldn't understand so far why you are refering to vectors, transparency and rotations when we're talking about scrolling a web page, which obviously does not involve anything of that (with the exception of font rasterization, which is usually derived from a vector description of the glyphs' outlines).

So please, tell me what OS X is doing to render a web page that is more complicated than decoding DivX.

Apples-to-oranges comparison. You are trying to compare rendering to decoding. I will compare both of these processes on a Web page versus a DivX file, in an attempt to explain this to you.

I'll start with decoding. DivX runs a frame through a decoder, which (due to temporal compression) may involve some of the previous frames. The end product is a bitmap the size of the frame.
Meanwhile, a Web browser runs the page through a parser and then through its own engine, which is in many ways similar to a video decoder. The end result on a Mac is not, however, a bitmap of the page; rather, it is a set of "notes" (for lack of a better term) containing the text of the page (and associated images) and their positions on the page.

Having gone through this, let's look at the draw process. A DivX file goes through the QuickTime system, which simply copies the frame into the framebuffer, and it's all done. The Web page, however, then goes through the CoreGraphics rendering system, where the bitmap must first be created before it can be pushed out to the framebuffer.

This is why scrolling is slower. Drawing in Quartz -or any vector-based system- requires an extra rendering step. That is where the slowdown occurs. You may notice that non-Quartz browsers -Mozilla in particular- seem to scroll faster than others. Because they use QuickDraw, they can bypass this extra step. That comes at a price, however; the operating system loses knowledge of what is being drawn onscreen. At the moment, there are no real repercussions of that. This is likely to change in the future.

Do I really have to remind a moderator of this board to stay on topic?

I am not a moderator of this board, nor have I been for over a year. I moderate the Web Developer and Developer Center forums. You can check the moderator lists on the main page, if you like.

[Pierre B.]

I don't know in what extent the possible Quartz optimizations have been done. Take for example GLTerm: it is just a terminal application which uses the OpenGL drawning context, not the standard Quartz one of MacOS X. Result: insanely fast! For example, try to scroll in a full screen GLTerm window after displaying a long document (e.g. man tcsh); it is almost impossible to separate the mouse arrow from the scroll bar. No other OS X application can do that.

Of course using OpenGL as drawing system has some disadvantages (see the developer notes in the above link). It is perhaps up to Apple to allow a more seamless integration and interaction between Quartz and OpenGL.

[stew]

Originally posted by Millennium:
Thus far, I am not impressed.

That's because I'm not out to impress. Web forums are not pissing contests, at least not in my view. If you are interested in my CV, feel free to PM me, but I have no intention whatsoever to brag in a public forum about private matters.

Meanwhile, a Web browser runs the page through a parser and then through its own engine, which is in many ways similar to a video decoder. The end result on a Mac is not, however, a bitmap of the page;

Of course it is. That's what Quartz is keeping in its per-window buffers (double buffering works with bitmaps and only with bitmaps).

This is why scrolling is slower. Drawing in Quartz -or any vector-based system- requires an extra rendering step. That is where the slowdown occurs.

Any other web browser is doing exactly the same. A web browser in GTK+ or GDI+ is just as well not rastering the fonts itself but is telling the OS when and where to draw text, then the system handles that.

You may notice that non-Quartz browsers -Mozilla in particular- seem to scroll faster than others. Because they use QuickDraw, they can bypass this extra step.

That does not make sense. First, Mozilla on OS X scrolls just as slow, at least for me. Second, Mozilla is at least partially using the same drawing engine as Safari, the font rendering looks and behaves exactly the same (may I also quote the Mozila 1.1 release notesp, "Mozilla now takes advantage of Quartz rendering for users of Mac OS X 10.1.5"). Third, if QuickDraw were faster, how comes that Internet Explorer on OS X is so slow at scrolling?

No, why I suspect that scrolling is so slow in OS X is that it is doing the pixel-blitting in the backbuffer in the system RAM, then copying it to the display buffer in the VRAM. You can clearly see that OS X is not redrawing but simply pixel-copying large parts of the scrolled web page when you use Quartz Debug to highlight updated regions.

Now, the problem here is that
a) the pixel-blitting is happening in system RAM and therefore cannot be accelerated in hardware like it is in OS 9 and
b) this is using a lot of memory bandwidth, making this problem more apparent on notebooks, G3s and machines with slower AGP slots.

I back my theory by the observation that scrolling is a lot smoother when I resize the window to be smaller vertically but still retaining the same height. In this case, the area that needs to be redrawn (which, by your explanation, happens completely in vectors and is the bottleneck) is still the same, but the are that needs to be blitted is smaller.

I ceratinly do not believe that there is anything complicated to render in a web page that would cause Quartz2D to be the bottleneck. Bitmap images like graphics in a web page or aqua widgets are not vectors, not even in Quartz2D. Text rendering is vectors, but that's not so complicated that it'd need to slow down anything that much. OS X is fast at drawing text, and many other display systems draw text just as pretty and are fast.

I am not a moderator of this board, nor have I been for over a year. I moderate the Web Developer and Developer Center forums. You can check the moderator lists on the main page, if you like.

I guess that these forums also follow the general netiquette that say that personal issues, as for example my CV, do not belong here.

[stew]

Originally posted by Pierre B.:
it is almost impossible to separate the mouse arrow from the scroll bar. No other OS X application can do that.

With the human mind being very easy to trick*, I suspect people would perceive OS X as much faster if Apple changed nothing about the scrolling itself but just made the scroll bar stick to the pointer. It doesn't matter if it's fast, it only has to feel fast - after all, isn't the Mac about the user experience instead of technical details?

*For a more about perceived speed in computer UIs, see chapter 2-3-5 in "the humane interface".

[entrox]

Originally posted by stew:
No, why I suspect that scrolling is so slow in OS X is that it is doing the pixel-blitting in the backbuffer in the system RAM, then copying it to the display buffer in the VRAM. You can clearly see that OS X is not redrawing but simply pixel-copying large parts of the scrolled web page when you use Quartz Debug to highlight updated regions.

There's no need to suspect anything if you have the ability to actually measure it. I'm sure that you're able to use a profiler (Shark is excellent) and just take a look. I just did!

I attached it to a running OmniWeb process and just let it collect samples while furiously scrolling around. From what I can gather, the most time is spent redrawing the HTML page itself (roughly 40%). Only 20% are actually spent copying memory around in _NXScroll, which you can mostly attribute to __memcpy. If you look at the disassembly, it is clearly written to take advantage of AltiVec (which is about the only piece of code using it there it seems). But yes, it is doing everything in system memory. Frankly, I fail to see how it could work otherwise.

[stew]

Originally posted by entrox:
From what I can gather, the most time is spent redrawing the HTML page itself (roughly 40%). Only 20% are actually spent copying memory around in _NXScroll, which you can mostly attribute to __memcpy.

Would be interesting to do a similar profiling on an OS 9 or X11 browser. Did you try browsers other than Omniweb?

If you look at the disassembly, it is clearly written to take advantage of AltiVec (which is about the only piece of code using it there it seems).

It'd be a shame if OS X' _mempcy didn't use AltiVec!

ut yes, it is doing everything in system memory. Frankly, I fail to see how it could work otherwise.

Disable double buffering while scrolling and replace the _memcpy with a GPU blit. Much faster, less CPU usage.

[Catfish_Man]

Looks like Safari spends about 18% of its time in memcpy (and the call tree for it is from [NSScrollView scrollClipView:toPoint:]), 7.9% in _dyld_get_image_header_containing_address, 7% in vecCGSFill8by1 (vector code for NSRectFillUsingOperation), 4.6% (ugh) in objc_msgSend, 2.8% in vecCGSColorMaskCopyARGB8888 (seems to be used in text drawing, not quite sure what it is), and 1.6% in spin_unlock. memcpy does appear to use vperm some, but not all that much. So while scrolling, Safari appears to use Altivec in many of its most cpu intensive functions, does a lot of memory copying, and a lot of filling in pixels. The page I used is arstechnica.com, and it was already loaded when I started profiling. I just scrolled up and down a lot with the mouse wheel. Since this turned out pretty similar to Omniweb, I'd guess any webcore based browser will look like this.

[edit] Camino looks similar, except it spends more time drawing (and uses more CPU total) [/edit]

[entrox]

Originally posted by stew:
Would be interesting to do a similar profiling on an OS 9 or X11 browser. Did you try browsers other than Omniweb?

No, it was just a quick test to see what's happening.

It'd be a shame if OS X' _mempcy didn't use AltiVec!

Well, browsing through the disassembly of various functions, I was a little disappointed to only see it in memcpy().

Disable double buffering while scrolling and replace the _memcpy with a GPU blit. Much faster, less CPU usage.[/B]

But how can you do a GPU blit? From what I can gather, Quartz2D does all the drawing into memory, which then gets uploaded as a texture (quite a few actually) and drawn by OpenGL. I can't see how to compose a texture on the graphics card itself, short of doing some fancy fragment shaders. We can't just do "unsigned char *vram = (unsigned char*)0xA0000" anymore ;-)

[stew]

Originally posted by entrox:
But how can you do a GPU blit? From what I can gather, Quartz2D does all the drawing into memory, which then gets uploaded as a texture (quite a few actually) and drawn by OpenGL. I can't see how to compose a texture on the graphics card itself, short of doing some fancy fragment shaders. We can't just do "unsigned char *vram = (unsigned char*)0xA0000" anymore ;-) [/B]

You can do it the same way it's done in OS 9: From VRAM to VRAM. There is no need to do the blit in they system RAM and then copying it to the VRAM - the VRAM does already have all the information it needs to do the blit itself. The OS X way of drawing everything in a system RAM backbuffer is causing redundant traffic on the AGP port - I don't need to copy the whole window to the VRAM, only the parts that were redrawn.

Once you're through with the whole process, you can copy the final texture back from VRAM to system RAM, to keep the backbuffer in sync.

Yes, what I'm proposing here is a partial breach with the double buffering philosophy in order to reduce CPU usage and latency.

[sniffer]

I had to go back and check if the difference is that big now that we have Panther and all.

I have Mozilla 1.3.1 from http://wamcom.org/ in OS 9 and Mozilla 1.6 in OS X on a iBook G3 ATI Rage 128 mob (no quartz extreme support).
The difference with Mozilla isn't *that* major. Thought the OS 9 version is a little faster.

Internet Exporer and the overal system responsivness on the other hand feel fast like, pardon my language, hell (or XP if you like)!

But considering how close the two Mozilla versions feels I don't think OS X is that bad at the moment relativily speaking. I understand there is a overhead with the buffering in ram and all that, but in the same time when scrolling in OS 9, scrolling is all OS 9 does, and in some extent XP does it a similar way. OS X seems to me to be a little different in that area, and not favor some tasks over other.

If it's true what you suggest stew, wouldn't it be possible to prove this theory within a application? Or will the OS need to be changed first?

[Twilly Spree]

I was working on a Wintel today. It was a powerful (3GHz) HP running XP. Now I noticed that when I moved the window fast around the screen or resized it the edges flickered as they were redrawn. Fast, but not fast enough for me to miss it (20/20 vision).

I notice this does not happen on OS X. Even on slower machines. The OS X way is slower but it does look a lot better.

I don't think it is that much slower. It is within limits.

[stew]

Originally posted by sniffer:
I understand there is a overhead with the buffering in ram and all that, but in the same time when scrolling in OS 9, scrolling is all OS 9 does, and in some extent XP does it a similar way. OS X seems to me to be a little different in that area, and not favor some tasks over other.

What do you mean exactly? I hope you're not referring to the myth of the non-multitasking in OS 9. OS 9 does multitask - cooperatively. When you scroll in a web browser in OS 9, does iTunes stop playing?

Besides, preemptive multitasking is in general more responsive than cooperative multitasking, as applications are able to respond to user events independently of whether or not other applicaitons are busy. It appears to be popular amongst Mac users to blame preemptive multitasking for the perceived sluggishness in OS X over OS 9, but this is wrong. Preemtive multitasking and -threading are very responsive, as you can for example see in BeOS.

If it's true what you suggest stew, wouldn't it be possible to prove this theory within a application? Or will the OS need to be changed first?

I'm not too imtimate with the details of CoreGraphics, but I don't think OS X is giving applicaitons direct access to the GPU's blitter. It would probably be possible to build a proof-of-concept application using OpenGL which.

But what should that prove? That blitting directly in VRAM using the GPU is faster than a memcpy by the CPU in system RAM followed by a copy from system RAM to VRAM? I believe this should be fairly obvious that GPU acceleration is faster than having the CPU do the same task.

[voodoo]

on a 867 MHz G4 12" PB the scrolling is super smooth.

What was the problem again?

[sniffer]

Originally posted by stew:
What do you mean exactly? I hope you're not referring to the myth of the non-multitasking in OS 9. OS 9 does multitask - cooperatively. When you scroll in a web browser in OS 9, does iTunes stop playing?

No I don't participate in that myth. Just doing observations on what's going on on the screen.

Besides, preemptive multitasking is in general more responsive than cooperative multitasking, as applications are able to respond to user events independently of whether or not other applicaitons are busy. It appears to be popular amongst Mac users to blame preemptive multitasking for the perceived sluggishness in OS X over OS 9, but this is wrong. Preemtive multitasking and -threading are very responsive, as you can for example see in BeOS.

That's funny you mention it. I have BeOS as my main OS on my PC right now, and XP runs around it when it comes to scrolling in Mozilla and Firefox or regarding video playback. If it's a video driver issue or not I can't tell, but there is something with my setup (standard nvidia gforce 256) that doesn't convince me that this is all about the way things are drawn on screen. Again, just refering to subjective-none-technical observations.

I'm not too imtimate with the details of CoreGraphics, but I don't think OS X is giving applicaitons direct access to the GPU's blitter. It would probably be possible to build a proof-of-concept application using OpenGL which.

But what should that prove? That blitting directly in VRAM using the GPU is faster than a memcpy by the CPU in system RAM followed by a copy from system RAM to VRAM? I believe this should be fairly obvious that GPU acceleration is faster than having the CPU do the same task.

Speaking of my self, I would certainly get convinced if your hypotese/theory have some proofs that fits into quartz or similar. If that's not possible it gets a little hard to understand how this is relevant to the "third generation" display layer which is a step a way from putting everything directly into the framebuffer in the first place. Just my humble opinion.

[Catfish_Man]

Originally posted by sniffer:

That's funny you mention it. I have BeOS as my main OS on my PC right now, and XP runs around it when it comes to scrolling in Mozilla and Firefox or regarding video playback. If it's a video driver issue or not I can't tell, but there is something with my setup (standard nvidia gforce 256) that doesn't convince me that this is all about the way things are drawn on screen. Again, just refering to subjective-none-technical observations.

I think he was saying that BeOS is responsive, not that it scrolls well.

[mr. burns]

i just tried smooth scrolling for the first time on my dual 500 G4. not too fun. i'm back to normal. someone said their text input is delayed on here. mine is too, but only on this board. i've got other boards open in other tabs and they're fine.

[stew]

Originally posted by sniffer:
That's funny you mention it. I have BeOS as my main OS on my PC right now, and XP runs around it when it comes to scrolling in Mozilla and Firefox or regarding video playback. If it's a video driver issue or not I can't tell, but there is something with my setup (standard nvidia gforce 256) that doesn't convince me that this is all about the way things are drawn on screen.

In my experience, Mozilla and FireFox on BeOS were slow ever since. Opera or NetPositive always seemed much faster to me.
Also, keep in mind that BeOS' drivers are nearly as optimized as Mac OS' or Windows' drivers. Be Inc had to write the drivers themselves with little or no help from nVidia, where nVidia is writing the drivers for Windows and are helping Apple at writing OS X drivers or are writing the drivers for them too.

And Catfish_Man said it already: With the BeOS example, I was only pointing at general responsiveness, not scrolling in particular.

Speaking of my self, I would certainly get convinced if your hypotese/theory have some proofs that fits into quartz or similar.

Well, I can't deliver that right now. I may have the time to do something like that in two months when things in my life calmed down a little, but I don't see the point. If it's only for convincing you...

If that's not possible it gets a little hard to understand how this is relevant to the "third generation" display layer which is a step a way from putting everything directly into the framebuffer in the first place. Just my humble opinion.

That is the major problem in my eyes. Moving away from the framebuffer means moving away from the GPU, putting a high load on the CPU. How can people expect that future GPUs will accelerate Quartz' drawing when Quartz is even unable to the acceleration functions current GPUs offer? Will future GPUs magically be able to perform fast drawing operations in system RAM?

[sniffer]

Originally posted by stew:

That is the major problem in my eyes. Moving away from the framebuffer means moving away from the GPU, putting a high load on the CPU. How can people expect that future GPUs will accelerate Quartz' drawing when Quartz is even unable to the acceleration functions current GPUs offer? Will future GPUs magically be able to perform fast drawing operations in system RAM?

..Or in 2008, around when Longhorn ships, we are all using OS X 10.8 and PowerMacs ships with 2x7Ghz CPUs.. Perhaps you'll also get video cards with a gig of vram so QE doesn't have to struggle with slow AGP ports and tight system bus'es etc. When vector based GUI techniques starts to gain a bigger marked the video card producers can't overlook these things, or/and the software will get better handling this things with the tools already available.
If your suggestion drawing bitmaps directly into the frame buffer in a vector double buffered environment is possible and practical, well that's really cool. But a couple of years down the road, this wouldn't have the same impact despite it being possible or not.

[Pierre B.]

Here is an interesting discussion from the Ars forums. Somewhat old, but still relevant.

I am wondering in what extend Altivec and OpenGL are/could be used to accelerate 2d operations and display drawning. Do we have any news from OpenGL 2?

[stew]

Originally posted by sniffer:
..Or in 2008, around when Longhorn ships, we are all using OS X 10.8 and PowerMacs ships with 2x7Ghz CPUs..

And I don't want to put up with my CPU being wasted for stupid blitting tasks until then. I can't afford buying the latest PowerMac every year, and I'm sure there's tons of other G3 users that wish for a faster UI experience on OS X.

Perhaps you'll also get video cards with a gig of vram so QE doesn't have to struggle with slow AGP ports and tight system bus'es etc.

I'd prefer having a crossbar architecture a la SGI O2 over a unnecessary separation of different RAM segments. But well, looks like that's a pipe dream.

When vector based GUI techniques starts to gain a bigger marked the video card producers can't overlook these things, or/and the software will get better handling this things with the tools already available.

First of all, we need applications that actually use that vector stuff. So far, every icon, button, scroll bar, etc in OS X is just a pixmap and not a vector.

If your suggestion drawing bitmaps directly into the frame buffer in a vector double buffered environment is possible and practical, well that's really cool.

I'm suggesting using the GPU blitting functions where appropriate instead of wasting precious CPU cycles on that task.