Re: NSScrollView bug or misunderstood behavior?
Re: NSScrollView bug or misunderstood behavior?
- Subject: Re: NSScrollView bug or misunderstood behavior?
- From: Ivan Kourtev <email@hidden>
- Date: Sat, 11 Nov 2006 17:40:51 -0500
Thanks for the exhaustive reply. I understand that my problems arose
mainly because of my incorrect assumption that there is a similar
backing store for the views as for the windows (by the way, I read
the docs exhaustively and own every single Cocoa book in print but
it's just a little hard making sense of it sometimes).
Back to my particular problem -- what I want drawn behind my custom
view is not a watermark but some complex grid structure that changes
occasionally (only when zooming but not when scrolling). I've tried
most approaches you recommended with various success:
On Nov 11, 2006, at 3:01 PM, Erik Buck wrote:
There are several ways you can improve behavior:
1) Triple buffer: Have your document view draw into a bitmap
image. When the document view is asked to draw, just composite
from the bitmap image rather than redrawing from scratch. Disable
copy on scroll. This approach requires more memory because there
will be three buffers total: Your custom image, the window's
backing store, and the frame buffer. However, it should be as fast
as copy on scroll while enabling you to do "strange" things with
expensive_to_draw views.
This I tried in a bit of a haste and couldn't get to work--I suppose
reading a little further on how to draw into a bitmap image would help.
2) Use an overlay window (child window): Let the Window Server do
the work for you by using an additional window and therefore an
additional backing store. Put whatever transparent drawing you
want in a child window that is layered correctly. The Window
Server will composite from both layered windows to produce the
final result in the frame buffer. You can have a transparent
document view layered above the child window or visa versa. It's
all good to the Window Server. I use this technique to layer Cocoa
controls over pure OpenGL drawing all the time.
I did several versions of this and was able to get them to work
nicely for stuff above the main drawing in the document view -- I am
using an overlay transparent view (a subview of my custom view) all
the time. In your suggestion above, if I create a child window and
order it below the window with the document view, then how will I
make the content of this child window seen through the document view
(enclosed in a scroll view) in the main window? Even if the scroll
view doesn't draw its background, wouldn't the main window (above the
child window) be in the way? I think this would be the most
attractive option for me, if it can be made to work.
4) Add a non-opaque subview to the scroll view and tell the subview
-setNeedsDisplay:YES every time the scroll view's -tile method is
called. I suspect having a non-opaque subview will defeat the copy
on scroll behavior anyway, but it should produce the correct
results on screen.
I tried this too and got it to work but without copy on scroll as you
pointed out. I couldn't get rid of some jittering during scrolling
-- stuff was getting drawn where it had to be but it was jittery as I
scrolled.
Thanks,
--
ivan
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden