Re: NSCopyBits and expose events
Re: NSCopyBits and expose events
- Subject: Re: NSCopyBits and expose events
- From: Allan Odgaard <email@hidden>
- Date: Mon, 1 Jul 2002 16:37:39 +0200
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 :-) ).
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...
number of items I might want to display. So I cannot just change
the origin co-ords to force a redraw. So the frame and bounds co-ords
stay
the same and I manage the drawing myself.
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 ;-) ).
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.
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.
I know there have previously been postings with example code that did
text layout, and where a large constant was given to the text-view, and
that constant was calculated to be as large as possible without loosing
precision. You can try to search the archive, but it was really big ;-)
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).
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.
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)...
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...
_______________________________________________
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.