Re: NSCopyBits and expose events
Re: NSCopyBits and expose events
- Subject: Re: NSCopyBits and expose events
- From: Allan Odgaard <email@hidden>
- Date: Tue, 2 Jul 2002 10:39:21 +0200
On mandag, juli 1, 2002, at 06:44 , Paul Fox wrote:
2 million items??? Assuming each take up 100 bytes (which I'd say is
rather optimistic with Cocoa) then that's 200 MB [...]
Oh heck. I've told you a thousand times not to exaggerate :-)
Actually, for the editing window, 2 million lines is not unreasonable
(and the memory usage is significantly less than 100 bytes for reasons
that are too much to go into).
Okay -- but if this is allocated as seperate records then even if your
record is e.g. 8 bytes then you may experience that the system rounds up
that allocation to match the size of a cache line -- but of course you
could do your own alloc from a heap that doesn't cache and boundary
align...
I must confess, I'm really curious to what it is you store in these
tableviews! :-)
I tried adding 2.000.000 items to a tableview [...]
That useful to know. How big was your process memory image then?
I didn't check -- but I did check that it had loaded one gigabyte from
my swapfile (normally it doesn't need to touch this, I have 384 MB).
Though you can't really compare this to your custom stuff, cause each
NSTableView record was an NSDictionary with two NSString entries --
hopefully you'll be able to do better for your zillion items! :-)
Its not the issue of floats thats important. A float is only a 32-bit
qty
so from what you are saying up to about 4 billion different numeric
values
can be represented. Which is fine and I would be happy with.
Okay -- but keep in mind that flaots are composed of an exponent and a
number, like 2.3 * 10^7, each part has a number of bits dedicated to it,
and so, you can't represent all numbers in the range of zero to 4 gig
(but instead you can actually store numbers larger than 4 billion).
[...] doesnt it create a backing bitmap buffer
equal to the size of the view? So memory costs might be high?)
I certainly would not hope so!!! And I think one proof is [...]
Yep - but here we are talking about the implementation of Cocoa's
table/clipview etc.
Well, I still think it's safe to assume that they have not done it this
way -- it would really be insane, and all the signs do speak against it
(at least drawRect is called for my NSView each time I scroll, and this
is with the new portion) -- there's really no need for speculation
here...
There are tradeoffs. Rendering to a bitmap can be faster when a lot
of scrolling is going on. But more expensive if no scrolling
takes place but the cells keep on updating.
Well -- the bitmap solution really doesn't have any real advantages.
First of all, it would take up a lot of memory, and running out of mem
really makes the machine slow.
Furthermore, the new areas drawn are mostly done so by copying graphics
from other places, like fonts, filling backgrounds etc. -- if this was
done with the on-board blitter (which can move at least 1 GB/s) then
there is no real difference about wether you do one copy from a bitmap
or multiple smaller copies (both complete faster than you can initiate
the operation itself ;-) )...
Try to overload isOpaque for your NSView and return YES [...]
Yes I did that. I had set it to return NO and got some bizarre/horrible
effects
so now it returns YES.
Well -- opaque means non-transparent :-)
> > [...] I can send you some example code both using NSScrollView
but also doing custom scroll without adjusting bounds (but also without
the NSView having any child NSViews, I never found out if this was
important for you)...
Yes that would be interesting. See if I can learn something from it.
Okay, I'll send it off-list later today.
Btw: is there no file archive where e.g. sample code could be uploaded
to? (not including sample code from Apple, where users can't submit
stuff). This would really be handy, together with some sort of
knowledge base, maybe administrated using something like Wicki, cause I
think the state of Apples documentation is in some regard really awfull
(i.e. no info about hotkeys with Cocoa, how to do online help, mention
of the NSUIElement property etc. etc.).
I now that currently one just search this mailinglist, but it's really
not a satisfying solution -- often one finds a dozen letters concerning
the subject, but it's very much inconclusive (for example, try to figure
out how to convert unicode to glypgs, the proper way of custom text
layout etc.) -- but perhaps this is just a mirror of the fact that in
real life these subjects are really "inconclusive"...
I have access to a server where I could setup a knowledge base, though
it's on a shared 2 Mb ADSL, so it should be re-hosted if it turns out to
be a succes...
_______________________________________________
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.