Re: How can I implement labels without the overhead of an NSTextField?
Re: How can I implement labels without the overhead of an NSTextField?
- Subject: Re: How can I implement labels without the overhead of an NSTextField?
- From: Henry McGilton <email@hidden>
- Date: Mon, 13 Dec 2004 10:09:17 -0800
On Dec 13, 2004, at 9:21 AM, Guy English wrote:
On Mon, 13 Dec 2004 08:35:55 -0800, Henry McGilton
<email@hidden> wrote:
I just performed a simple experiment . . .
Cool, I was going to try it out myself this evening. :)
I think it can still be improved a little though ...
I think you can eliminate the background buffer:
In the init:
Load the original background, make a copy.
(if you need the original you can keep it otherwise release it)
Generate all the strings. I'd use NSAttributedStrings, and draw those
directly into the copy.
Lock the image once, draw all your strings, then unlock it.
In your NIB you would have a scroll view with an NSImageView inside it.
Set the imageView size to the size of your background.
Set the imageView image to the image you've just generated.
You're all done.
I think this will be a little faster because it eliminates an extra
copy during scrolling. (you don't need to copy from the backbuffer, to
the view, then to the screen)
It also moves the initial rendering hit to the init method and, by
locking only once, and using the attributed strings directly, I think
it'll be a little faster.
Yes, very good. If the original person's requirements are as
you described, this would be a much better way to go about it.
As I said, my code was flanged up quickly just as a proof of
concept.
As another demonstration of buffering, one of my Protractors
applications
in one of its view modes, draws 160 string labels around the periphery
of a circle. So not only are the labels being drawn at specific points,
but the label origins are being translated and rotated as well. The
double buffering makes any redrawing un-noticeable.
I think this method does fall apart at some point - I seem to remember
there is a cap on the usable size of an NSImage. It's big but it is
there.
You are correct, but I could not figire out (even via Google
and Mamasam) what the limits are. There are some image cache
limitations I believe. Windows appear to limit sizes to around
16,000 pixels on a side. A full-colour view of this size would
be around 128 megabytes.
Cheers,
........ Henry
===============================+============================
Henry McGilton, Boulevardier | Trilithon Software
Objective-C/Java Composer | Seroia Research
-------------------------------+----------------------------
mailto:email@hidden | http://www.trilithon.com
|
===============================+============================
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden