Quartz/memory benchmarks...
Quartz/memory benchmarks...
- Subject: Quartz/memory benchmarks...
- From: Allan Odgaard <email@hidden>
- Date: Thu, 27 Jun 2002 03:24:50 +0200
Okay, I did some more in-depth benchmarking.
Using scrollToPoint it seems I can move what would correspond to around
75 MB/s. Using scrollToPoint, but setting copiesOnScroll to NO gave a
speedup of approximately 20% (I still did fill the background in the
drawRect method, so theoretically the same amount of bytes were sent to
the graphics card, but instead of reading the bytes from main memory,
the same byte could be written in a loop).
I then tried to move a similar amount of bytes in an array of unsigned
longs (thus 4 bytes at a time), and to my surprise, the performance here
also gave me 75 MB/s (this was moving normal memory to normal memory,
w/o involving Cocoa, Aqua or similar).
So to answer my original question, it would seem that Quartz doesn't use
a blitter to scroll visible bitmaps, nor would it seem that it uses DMA
to transfer bitmaps from main memory to graphics memory (as I'd assume
we'd then get more than 75 MB/s) -- one exception though seems to be
when moving (or depth arranging?) entire windows, as far as I can see
this does beat the 75 MB/s limit of the simple CPU solution, since I can
move around full screen windows in what appears to be real time.
Furthermore I can conclude that main memory read/write is limited to
around 75 MB/s -- I tested the same code on a PC running Linux, and to
my surprise I actually "only" got 138 MB/s... so it would seem that my
thoughts about "modern" computers were a little optimistic...
I'm left with a bitter taste, because if windows are constructed in main
memory and later moved to the display buffer then we will never get the
power of a blitter to aid in the construction of these windows. So if we
start by filling the background with a repeating pattern (as is default
in Aqua), then clear various rectangles for the various non-transparent
NSViews, and then draw text etc., we'll quickly draw the number of
pixels occupied by the entire window twice -- this means that a window
at the size of 400x400 pixels (in true colour) can't be resized in real
time, even though it may only contain a single non-transparent NSView...
_______________________________________________
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.