Re: Quartz blitter/hardware support?
Re: Quartz blitter/hardware support?
- Subject: Re: Quartz blitter/hardware support?
- From: Darrell Walisser <email@hidden>
- Date: Wed, 26 Jun 2002 12:07:28 -0500
On Wednesday, June 26, 2002, at 11:28 AM, cocoa-dev-
email@hidden wrote:
Message: 2
Date: Wed, 26 Jun 2002 07:49:00 -0700
Subject: Re: Quartz blitter/hardware support?
Cc: email@hidden
To: Allan Odgaard <email@hidden>
From: Shawn Erickson <email@hidden>
On Tuesday, June 25, 2002, at 10:42 PM, Allan Odgaard wrote:
Dear list,
Slightly off topic but I hope the people here have the insight to
provide a reply anyway :-)
I use an NSScrollView with a custom NSView subclass.
I set setDrawsBackground and setCopiesOnScroll to YES for the
NSClipView. And my NSView overrides the isOpaque method to return YES.
Still, when my window grows to more than 10% of the screen size (give a
take some pixels) then scrolling can no longer happen in real time
(that is, follow the screens refresh rate) -- even when I only do a
NSFillRect(aRect) in my drawRect method (to fill the newly visible
pixels).
[snip]
If Quartz does indeed use the blitter for these simple operations then
a) what exactly will the Extreme version provide?
Probably the backbuffer of the window will be stored in video memory, so
scrolling will be much faster because you don't have to do a RAM->VRAM
copy every time you scroll, only when you touch the actual pixels of the
backbuffer (in which case the VRAM must be updated).
and b) why on earth
is Quartz so sloooow?
1. Quartz (really the window server), seem to sync screen updates to the
display refresh. This means you normally can't go faster than the screen
refresh rate.
2. To do a screen update, you have to synchronize with an external
process (the window server), which involves IPC and hence has
performance penalties associated with that.
3. You cannot draw directly to the screen. This is the big killer. You
draw into memory shared with the window server, and the window server
copies that data to the screen, after composing it with other onscreen
windows. Take the width of the area you are drawing, multiply by the
height and bytes per pixel (either 2 or 4) and that's how much data has
to be transferred to the video card every time you redraw. Redrawing a
640x480x32, that's ~1.2MB of data that must be moved from sysRAM to VRAM
whenever you draw. AGP-equipped Macs have a much fatter pipe to VRAM so
they suffer less in this respect but it can still become a problem in
some applications, especially games or at high resolutions.
4. Alpha becomes a killer because of 3. With alpha, your redraw areas
will normally be larger and you'll have to update more of the screen.
That's why you are smart to enable isOpaque to YES. In general with
alpha the window server has to touch more memory, because it might have
to touch everything (in the region you update) that is below the
containing window, and this slows down drawing as well.
Because this is such a killer, Apple has provided QuartzDebug, which
shows you what parts of windows are copied from sysram to vram. The goal
is to make the areas you copy as small as possible which usually gives
you modest speedups. This is pretty much the best you can do.
QuartzExtreme improves this situation by storing the backbuffer in VRAM,
so in general you end up copying less data from sysram to VRAM, for
example when scrolling. Scrolling has the potential to be insanely fast
since it is just a VRAM->VRAM copy. The optimizations you apply prior to
QE will probably still give you gains in QE because you still have the
opportunity to decrease the amount of data copied to VRAM, (since I
assume everything in the drawing layer won't be accelerated).
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.