Re: NSCopyBits and expose events
Re: NSCopyBits and expose events
- Subject: Re: NSCopyBits and expose events
- From: Paul Fox <email@hidden>
- Date: Tue, 2 Jul 2002 16:13:15 +0100
>
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...
No - clusters. Instead of one block per line, have a bunch, say 100
per malloced block and then swap out or discard when not needed (because
they can be recreated as needed).
>
I must confess, I'm really curious to what it is you store in these
>
tableviews! :-)
We are talking about two things. Millions of rows is for the edit window
(this is a programmers editor we are talking about). The table and tree
views typically used for showing files/directories or class hierarchies.
But the same 'rule' applies - having a window sized per the amount
of data to show will fall over on some platforms (obviously not
our beloved Cocoa)!
>
>> 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! :-)
I'm impressed you got to 2m entries and only used a gig of store for it!
>
>>> [...] 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...
Ok - my bad. The backing store is for the window - not each individual view
so that would put an upper limit on the size of the window (or does it).
If I can be bothered I'll try and crash my machine :-)
>
>> 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 :-)
Look - you dont expect me to know what I am doing - do you? :-)
(When nothing works get the hammer out and smash everything to bits :-) )
>
> > [...] 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 downloaded the entire apple mail list archive to my iPaq and spend odd
moments working thru the entire posted articles. (10% of the way thru). By
the time I have finished reading it all (about 2 years from now!) I will
be an expert...in peoples mailing habits - if nothing else.
I was surprised to find a size limit to postings on this list.
This list contains enormous amounts of nuggets of information (enough
to make a good book).
>
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"...
The web search is horrible. What I have is the entire archive on disk.
Simple bit of editing to remove some redundancy and join all the
postings into one big file. Now I just use my editor to search for keywords -
superfast and usually accurate. (Of course searching for "a AND b AND c" type
searches is more problemattical.
FYI - the mailing list todate comes to about 70MB - not a huge amount
so simple free text searching or grepping is fine.
I also have a script which can reorder the subjects. If anyone
is interested in what I mean I can post or put up a small sample of the
mailing list (yes - I know I am probably not suposed to say this), but
a lot of us are stuck in the same quagmire and I am happy to help out
one way or another.
BTW - I just about got my exposed-region library code to work and
performance is now much better and copable with than before.
2 days of driving myself insane and now its something useful (not
perfect by any means - but sufficient for the bad cases I have suffered).
>
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...
regards all
>
+-------------------------------------------------------------------------+
| CRiSP - Flexible editor | CRiSP, syn. for BRIEF |#
| | Internet: email@hidden |#
| If you get no reply for | WWW: (mine)
http://www.crisp.demon.co.uk |#
| support, please check your | WWW:
http://www.crisp.com |#
| Reply-To: email address. | WWW:
http://www.pacemaker.co.uk |#
+-------------------------------------------------------------------------+#
###########################################################################
_______________________________________________
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.