> The window overlay sounds like it could work. Hoverer, a NSView overlay would > be preferred since I'm inserting > the overlay in the WebView's scroll view (and matching the documents view > size via bounds change > notifications). This works very well when scrolling both the web and overlay > view at the same time (and is also > efficient).
A layer-backed (or layer-hosted) view matching the bounds of a large web page would use a lot of memory (bounds.width * bounds.height * 4 bytes, probably). I would handle scrolling in the overlay window yourself by offsetting the content view's bounds in the way that a scrollview does for its document view. Flipping the view's coordinates might help with the maths. It looks like listening for NSViewBoundsDidChangeNotification will let you track the scroll position of the webview and you need only draw those rectanges which are visible, of course. Kyle, I rather liked your stack of 'bees'. Regards, Paul Sanders. _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
