Re: Best way to do static overlay over scrolling content?
Re: Best way to do static overlay over scrolling content?
- Subject: Re: Best way to do static overlay over scrolling content?
- From: Lee Ann Rucker <email@hidden>
- Date: Wed, 20 Jul 2011 02:00:43 -0700 (PDT)
NSScrollViews aren't terribly happy with having extra subviews that aren't children of the contentView, but a separate view that's a sibling of the scrollview should work.
But actually the first thing I'd do is profile it to see if the drawing really is that inefficient. I've got an app that draws tide charts; when it "scrolls" it recomputes and redraws everything, but it's still fast enough you don't notice.
----- Original Message -----
From: "Daniel Vollmer" <email@hidden>
To: email@hidden
Sent: Wednesday, July 20, 2011 12:55:46 AM
Subject: Best way to do static overlay over scrolling content?
Hello,
I have a visualisation application that displays multiple graphs (currently using NSCollectionView, but possibly switching to an NSView-based NSTableView in the future) that looks like this: http://www.maven.de/code/wowplot/example_chains.png
When you scroll sideways, the "title" of each graph stays in place, whereas the rest of the content scrolls as usual. Currently, I simply redraw the whole graph (well, the visible bit). This strikes me as rather inefficient, because I essentially need to redraw the complete visible portion onScroll instead of only the freshly revealed bit.
There are some things I can think of, but I'm unsure on which would be the most appropriate way:
- Put an NSTextLabel inside the NSScrollView's contentView and dynamically reposition it into the visibleRect.
- Add a largely transparent subview to the NSScrollView (so it's the same size as the visible portion) and draw all titles in there, transforming coordinates as needed.
Preferably, the compositing would only happen once when the visibleRect changes, not each frame (so the transparent blend doesn't each too much graphics memory bandwidth).
Has anyone got any experience with this or suggestions on which way would be most appropriate?
Thanks,
Daniel._______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden