Re: NSView; size, memory, performance issues
Re: NSView; size, memory, performance issues
- Subject: Re: NSView; size, memory, performance issues
- From: Shawn Erickson <email@hidden>
- Date: Sat, 10 Apr 2004 15:34:02 -0700
On Apr 10, 2004, at 11:29 AM, Ivan Kourtev wrote:
Hi,
I have been (unsuccessfully) trying to find documented answers to two
questions regarding the NSView class and Cocoa drawing in general.
Perhaps someone knows the answers and can explain--here is what I'd
like to know:
1. Does an NSView use a memory buffer for the rendering of the drawing
to the screen or are all drawings buffered and displayed by the
NSWindow containing the view?
I am interested in the answers to this question because I'd like to
estimate the performance costs of resizing an NSView (via NSView
methods such as frame, setFrameSize:, setBounds:, bounds,
setBoundsSize:. Does resizing a view from 100 x 100 to 200 x 200,
for example, require a reallocation of a larger block of memory,
copying of the previous buffer for drawing into the new memory and so
on.
NSViews don't buffer any thing, it is basically a construct to describe
something that can exist in the view hierarchy of a window (in essence
its bounding rectangle and its origin/offset in its parents view
coordinates). NSWindows are the portal into the WindowServer which own
the window (and related buffers) you see on screen. When a view is
asked to draw itself it does so into a buffer maintained in relation to
window (done by locking and focusing the drawing environment before
your drawRect method is called). This window buffer is not directly
related to what is seen on the screen, it is a backing buffer. When a
round of drawing has finished this backing buffer is composited to the
screen (using full alpha compositing) by the QuartzCompositor (on
QuartzExtreme capable systems this is done by the GPU hardware using
surfaces in VRAM or pulled in from system memory). So for example if
the user drags your window around on the screen (not resizing but
dragging) your application is actually not being asked to draw
anything, the compositor is simply translating your backing buffer data
around on main screen with all of the other windows backing buffers.
So resizing a view in a window doesn't cause reallocation of any
buffers. Of course resizing a window does likely require a reallocation
of the backing buffer for that window (I believe while resizing things
are grown in over steps to avoid constant reallocation, then when
resize is complete things are trimmed down to the final size). Note
that some things can cache bitmap data, for example NSImages, and
resizing of those imply allocation and scaling when recached or drawn.
2. What is the relationship between a 1x1 square of NSView area and 1
screen pixel--are they the same or is one supposed to look up some
device-dependent (monitor) data for the answer? In short, how does
one write code that displays things in a nearly identical dimensions
regardless of specific monitor used?
By "nearly identical dimensions" do mean as seen on screen physical
dimensions? As in the length of say a line on one screen is the same as
on a different screen.
It would be helpful if someone could also point to a detailed
reference to learn about the overall drawing system architecture (I've
searched but must've missed them if there are any). I am simply
trying to learn the cost of various calls, data structures used, etc.
so I can consider a balanced structure for an applications before I've
actually written and tested any code for performance, memory use, and
so on.
The core drawing and windowing environment on Mac OS X is called Quartz
[1]. A basic primer on Quartz exists on the Apple developer site [2] as
well as a more detailed description of drawing using Quartz 2D [3].
Quartz is closely modeled after the concepts of PDF and PostScript
drawing so documentation related to those can be of assistance. The
Cocoa framework (like the other Mac OS X development frameworks) is
build on Quartz. Cocoa is the one that most closely follows the design
and methods of Quartz 2D (well some of Java's JDK does as well). For
more information on Cocoa's drawing constructs you can view the
documents in the graphics and imaging section [4] in particular [5].
-Shawn
[1]
<
http://developer.apple.com/documentation/GraphicsImaging/Quartz-
date.html>
[2]
<
http://developer.apple.com/documentation/GraphicsImaging/Conceptual/
QuartzPrimer/index.html>
[3]
<
http://developer.apple.com/documentation/GraphicsImaging/Conceptual/
drawingwithquartz2d/index.html>
[4]
<
http://developer.apple.com/documentation/GraphicsImaging/Cocoa-
date.html>
[5]
<
http://developer.apple.com/documentation/Cocoa/Conceptual/DrawViews/
index.html>
_______________________________________________
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.