Overlaying views to optimise drawing
Overlaying views to optimise drawing
- Subject: Overlaying views to optimise drawing
- From: Ken Tabb <email@hidden>
- Date: Tue, 27 Jul 2004 19:11:33 +0100
Hi folks,
I have a custom view that is heavily populated (potentially tens of
thousands) of graphical objects, with interconnecting lines etc. The
objects themselves rarely change appearance (in terms of shape / colour
etc., although it does happen), but the user's selection of those
objects changes frequently. The user then changes values for the
selected objects in an info palette.
Selected graphics objects draw bounding rects and selection handles
around themself, as per most drawing apps (eg. so that a selected
circular object appears as a circle inside a square).
I'm looking at optimising the drawSelf related methods in the view (eg.
to do rectangle checks as per 10.3 amongst other things), but obviously
it'd be nice to limit the number of times I have to redraw this in the
first place, aside from how expensive it is to draw.
At the moment the bounds rects and handles are drawn, for the selected
objects only, at the end of the view's drawSelf (etc.) methods, so that
all rects and handles appear in front of everything else, aside from
whether the corresponding object is near the front or back of the view
(otherwise if an object is eclipsed by another object, so are its
selection handles). However this means that each time the user clicks
(or shift clicks) on objects in the view, the view needs to redraw
(part of) itself.
I'm considering offloading this "meta-drawing" (selection handles,
bounding boxes, and the rubber band rectangle when drag-selecting
multiple objects) to another view which is drawn over the view
containing the graphics objects. This would mean, if the user is only
selecting / deselecting objects, that the main view wouldn't need a
redraw, I'd only need to redraw the "meta-drawing" view, which is a
much more lightweight thing to have to do.
Bearing in mind the app will be destined for 10.4 and later only (in
order to use CoreImage and Automator), do you think I should expect to
find significant drawing improvements by separating the view for
"meta-drawing"? All the macs expected to run this software would have
CoreImage compatible GPUs on board, if that makes a difference to the
answer. I'm aware that having transparent views isn't necessarily
renowned for gaining performance, but it's not that I need FPS
performance, just that single redraws in the graphics view require an
amount of computation, so I'd rather do it as infrequently as possible.
Secondly, if I go down the overlaid-view approach, then when the
original view (containing shapes) is zoomed/resized, I want the
overlaid view to also be zoomed/resized etc. - I'm thinking an easy way
to do this would be to bind the origin, bounds and frame size of the
"overlay" view to the corresponding values in the "graphics" view... is
this a nasty hack or elegant programming?!
Finally, if I use an "overlay view", then bearing in mind it will
always need to have the same dimensions as the "graphics" view, would I
be better off with 2x NSViews, or 2x CGLayers inside a single NSView?
Are there any performance benchmarks that I can refer to? I've searched
ADC but couldn't see anything.
Thanks in advance for any wisdom you can shed,
Ken
- - - - - - - - - -
Dr. Ken Tabb
Mac & UNIX Technical bloke (C, C++, Obj-C, Java) - Health & Human
Sciences
Machine Vision & Neural Network researcher bloke - Computer Science Dept
University of Hertfordshire, UK
http://www.health.herts.ac.uk/ken/
Certified non-Microsoft Solution Provider
_______________________________________________
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.