Re: NSCopyBits and expose events
Re: NSCopyBits and expose events
- Subject: Re: NSCopyBits and expose events
- From: Paul Fox <email@hidden>
- Date: Mon, 1 Jul 2002 17:44:25 +0100
>
On mandag, juli 1, 2002, at 02:21 , Paul Fox wrote:
>
>
>> I'd assume you could just call setNeedsDisplayInRect on self with these
>
>> two rectangles, and that will take care of propagating them to the
>
>> children (with appropriate coordinate transformations).
>
> Yes - this is a cheaper special case which will (probably) work. I will
>
> try that out.
>
>
As far as I can understand from your example then this is exactly what
>
you need (and the *only* special case, hence more correctly referred to
>
as the general case :-) ).
Well - yes. But remember I am coming in to a 'generic subroutine' which
doesnt specifically know about the hsb and vsb's. So actually
I am finding it better to write a generic algorithm rather than the
special case.
>
>> What? Are you saying that the contents of your NSView is larger than
>
>> the
>
>> bounds of the view?
>
> No (Or yes!). Maybe I misunderstand things. I want to display, for
>
> example, a list
>
> of 2,000,000 items. The window(view) co-ordinates cannot represent the
>
>
2 million items??? Assuming each take up 100 bytes (which I'd say is
>
rather optimistic with Cocoa) then that's 200 MB just to have the items
>
in memory... is this really useful for the user? wouldn't it make sense
>
to group this information and present top level groups? If the items
>
fall in no logical groups then perhaps just have A-Z buttons to toggle
>
which letter should be shown...
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).
>
I tried adding 2.000.000 items to a tableview, albeit it took a minute
>
or so, then it did display -- however, the precision (the coordinates
>
use floats) started to get bad at item 1.6xx.xxx -- but until that item
>
they were positioned correctly (and after that, it seemed that a gap was
>
introduced between every second item -- that's floating point math for
>
you ;-) ).
That useful to know. How big was your process memory image then?
>
> My 'app' in this contents is either a table-view control or tree-view
>
> control (all custom implemented). Nothing 'fancy' in that by itself.
>
> But I know if I just size my 'view' to the size of the data, I wont fit
>
> more than about 32,000/font_size items in the window on X or Win32.
>
>
Arg... sounds like someone is using a *signed* short int to hold the
>
dimensions. I find it hard to believe that this should be an OS
>
limitation, cause I have seen webpages that was higher than 64K pixels,
>
and they used (what looked like) normal scrollbars.
Win32 on the 16-bit OS's, e.g. Win95/98/ME have 16-bit co-ords. I think
NT has 32-bits (but I may be wrong). But in any case, somewhere the magic
constants 16,000 or 32,000 appear in my mind as having possible
problems somewhere.
But then the number of items in the list is limited to max-size/font_size
as I say, and scrollbar behavour does become problematic.
>
> Not sure what the max-coords in MacOS is, but the same rule applies.
>
> (Even
>
>
Well, they are a lot higher than 32K/font_height I can ensure you! Mac
>
OS uses floats for all dimensions, so the question is when the precision
>
of these floats start to get too imprecise, and as stated above, that
>
seemed to happen around 1.600.000*font_height.
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.
>
> if there were no limit in MacOS, 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!!! Abd I think one proof is that complex
>
tables scroll much slower than simple ones, that would not be the case
>
if it was just all rendered to a bitmap (another proof would be that
>
drawRect is invoked on the NSView each time scrolling happens (with the
>
newly visible rect set as clipping).
Yep - but here we are talking about the implementation of Cocoa's
table/clipview etc.
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.
>
>> Does that mean you call setNeedDisplayInRect with a wrong ractangle? or
>
>> that the system somehow gets it wrong?
>
> A bit of both. I may well be doing the wrong thing. But what I am
>
> finding is that if I call setNeedsDisplayInRect for a NSView, all
>
> superviews get called with the same rectangle to redraw - which
>
> is expensive beyond belief. Someone (maybe you) mentioned that
>
> there are bugs in setDisplay and this will be fixed in Jaguar.
>
>
Try to overload isOpaque for your NSView and return YES -- that should
>
prevent it from redrawing backgrounds behind your NSView when you need
>
refreshing.
Yes I did that. I had set it to return NO and got some bizarre/horrible effects
so now it returns YES.
>
> So I am digging a nice big hole to get myself in. Its quite possible
>
> that silly little errors on my behalf are causing me a lot of
>
> frustration, but after numerous experiments, I have to give up the
>
> "One True Way" and find a resolution irrespective.
>
>
My advice would be to stick with NSScrollView -- set drawsBackground:YES
>
for the NSClipview and overlaod isOpaque for the NSView being
>
contained -- 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.
>
One more thing: if you do custom scrolling and draw contents
>
independently of the bounds of your NSView, then why would you need to
>
call setNeedsDisplay:forRect? can't you just set an instance variable
>
like dx or dy (to indicate that scrolling should take place) and then
>
call setNeedsDisplay, and in this method you'd copy the contents and
>
redraw the newly exposed portions? This is how I did in my custom sroll
>
thingie...
Yes this is possible. My understanding is that calling setNeedsDisplayInRect
means the system can coalesce drawing regions and then do a 'big'
update when it gets a chance. Your way (and to an extent - my way also) is
to control the rectangles and redrawing myself - replicating in fact
what Cocoa does, but in a way in which I can understand.
My region manipulation library is getting close to being able to plug
in to my app and then I can see if I am happy. I am trying to keep
it as a generic 'region' manipulation library (like the CG Rect functions)
so that it is independent of any windowing system. This in itself
could prove useful for things I havent thought of yet (e.g. the character
mode version of my app could have done with this a long time ago!)
regards
+-------------------------------------------------------------------------+
| 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.