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 13:21:34 +0100
>
On mandag, juli 1, 2002, at 10:28 , Paul Fox wrote:
>
>
> es - the calculation is almost trivial, but turns out to be _very_
>
> complicated in the general case. I am busy routing through the region
>
> calculation code in the X11 server (miregion.c if anyone is interested).
>
> This is not trivial in any sense of the word.
>
>
I have written a full layers library myself, so I know all about it ;-)
>
but I really don't see why you'd need such a thing for a Cocoa
>
application.
Because I dont want to change the high level part of my app. So
I need to emulate X11 behaviour. And this functionality is very
useful and important.
>
> The reason is its not simple is we need to find the intersection of
>
> the bitblt region against the children. Then relocate this complex
>
> region to take account of where we are going to end up, and then
>
> subtract
>
> the region from the original window to find out what is affected.
>
>
Maybe you should tell me again what it is you want to do!?!
Ok heres a (bad) picture:
__________________
| | | XXX = 500,800 400x100
| | |
| | |
| | |<- scrollbar
| | |
| =========|
| ! | |
| ! | |
| ! | |
| !XXXXXX| |
|-------!--------|
| ! |
------------------
^scrollbar
Suppose I create windows like this (pseudo code):
w1 = win_create(NULL, 0, 0, 1000, 1000);
w2 = win_create(w1, 900, 0, 100, 900);
w3 = win_create(w1, 0, 900, 1000, 100);
/* arg1 is the parent window, remainder are x, y, width, height);
w2/w3 correspond to the scrollbars or whatever, ie direct children of the
main view (w1).
Now I do XCopyArea of the bottom right quadrant of the window, say
co-ords 500,500 width 500 height 500.
Not the bottom scrollbar (w3) obscures some of my src rect. When the
copy is done the bottom 100 pixels just above the scrollbar either
are wrong or a copy of the scrollbar itself (depending on clipping
regions). In either case its wrong.
Under X, I get sent an ExposureEvent to tell me the part
of the source rectangle(s) which couldnt be blt'ed, and I can correct
the display.
MacOS doesnt have this idea so you have to do it yourself. (Easiest hack
is to invalidate the whole window, but that is _expensive_). If I can
compute the rectangle(s) myself then drawing speed will be acceptable.
>
If we want to scroll a rectangle (x, y, w, h) by dx, dy then we need to
>
update two new rectangles, namely:
>
>
(dx > 0 ? x : x+w, y, dx, h) and (x, dy > 0 ? y : y+h, w, dy) -- these
>
may overlap slightly.
>
>
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.
>
> Once again, I dont want to use NSClipView/NSScrollView as they assume
>
> the
>
> underlying window is big enough to contain the data, and this is not
>
> the case for my implementation.
>
>
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
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.
>
Maybe if you tell me what the application does I'll better understand
>
the problem... my own app has NSViews which are many thousand pixels
>
high, but there shouldn't be any assumptions about any window holding
>
all that content, it's generated dynamically...
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. Not
sure what the max-coords in MacOS is, but the same rule applies. (Even
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?)
>
>> For the records, there is (unfortunately?) no real speed gained by
>
>> rolling your own bitmap copy/scroll thing (I tested that ;-) ).
>
>
>
> The problem i am having is that when i do my NSCopyBits, the
>
> newly exposed areas are not repainted. Sending setNeedDisplayInRect
>
> ends up redrawing the whole window (because the region calculation is
>
> not trivial).
>
>
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.
I am not waiting or relying on difficult to debug behaviour of MacOS.
I lost my life and soul when trying to debug window layout problems in Motif
(Why did that happen? How do I debug it?) I went through a lot of
pain in Windows (Windows is easier to debug). I am not going thru the
same thing again in MacOSX. If I cannot get it to work the
way the docs lead me to believe then I have no choice but to do hard
work myself. (And this is not so bad, as it may just make the next
window system port a lot easier).
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.
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.