Re: NSView; size, memory, performance issues
Re: NSView; size, memory, performance issues
- Subject: Re: NSView; size, memory, performance issues
- From: Ivan Kourtev <email@hidden>
- Date: Sat, 10 Apr 2004 19:18:02 -0400
Thanks everyone for the answers.
On Apr 10, 2004, at 6:48 PM, Allan Odgaard wrote:
On 10. Apr 2004, at 20:29, Ivan Kourtev wrote:
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?
The buffer is held by the window.
This is what I had suspected after observing how the memory usage of an
application changes as NSView's are resized. Just wanted to make sure
because I didn't find an explicit statement about it in the
documentation.
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?
The relationship depends on your bounds. By default, there is a
one-to-one mapping in size, but there is a translation of half a
pixel.
In short, how does one write code that displays things in a nearly
identical dimensions regardless of specific monitor used?
What do you mean by that? Do you refer to the aspect ratio of the
things you are drawing?
Yes, I meant things such as aspect ratio and approximate sizes of
things. I believe I had read in the Cocoa book that 1 pixel == 1 unit
of NSView but that this correspondence is not strictly guaranteed and
may change in the future. So I was curious if there is a technique
that one can use to programmatically tell the correspondence.
I think you'd get better help/insight if you instead describe what you
are planning to do, or just wrote a prototype -- I don't spot any
obvious design choices to be made based on how NSView's allocate
buffers or similar... ;)
In our application, we have a view of a large rectangular grid where
the user can move and position shapes on the grid. We want to have a
zoom capability and we were wondering how to implement it most
efficiently (best performance and least amount of most elegant and
light code possible). The approach we are considering was:
1. Write drawing code that makes things appear reasonably well in a
default NSView size (pixels for NSView units, as I know now), this
corresponds to zoom factor of (1.0).
2. When the user zooms in/out, only resize the NSView and change the
current transformation matrix.
I felt uncomfortable doing the above because I wasn't sure whether
NSView resizing changes some internal memory buffer used by NSView
itself; I wanted to avoid constant memory for this buffer being re- and
de-allocated as the user zooms around. If I understand correctly the
answers I received to my questions, the above approach should work
great with no memory or drawing calculations performance penalty
whatsoever (because everything drawn gets run through the default unit
CTM anyway).
Thank you everyone again.
-- ivan
_______________________________________________
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.