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 09:28:31 +0100
>
On sxndag, juni 30, 2002, at 12:28 , Paul Fox wrote:
>
>
> [...] the bits which should have been copied, but couldnt be, will
>
> result in ExposureEvents being sent to the client [...] NSCopyBits
>
> [...] doesnt do automatic exposures for the uncovered regions.
>
>
All rendering happens in an off-screen buffer, so your window will never
>
be obscured by other windows, which is why there is no need to calculate
>
exposure events.
Oh yeah .. I forgot, AppKit knows what I want and what I dont want.
Silly me :-)
>
However, if the view scrolled contain sub-views, and these are partly
>
outside the visible area, then you would need to send a drawRect to
>
these views for the new portions -- but this calculation is rather
>
simple (the intersection of the new area with that of the child to be
>
redrawn, could be done using NSBezierPath) -- however, I don't really
>
understand what you're doing: if you scroll the contents of a view that
>
have childviews, then you'd need to adjust bound rectangles as well for
>
proper coordinate transformations, and surely you'd have it a lot easier
>
if you used NSClipView/NSScrollView.
Yes - 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.
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.
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.
>
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). If I had full blown region manipulation primitives
available to me then I could do what I want. I wiill re-read the
CG docs to see if there is enough there rather than doing the
complex region library I am embarking on. (Its driving me mad
with the two-dimensional complexity, and that implies I am
over my head!)
thanx
>
>
+-------------------------------------------------------------------------+
| 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.