On 19.10.2009, at 23:58, Ben Haller wrote:
On 19-Oct-09, at 5:27 PM, Dave Keck wrote:
Would NSView's -getRectsBeingDrawn:count: help?
Well, I'm already using it in my own code where appropriate. (Or
actually I'm using -needsToDrawRect:). But the problem is that a
whole bunch of
On 20.10.2009, at 03:02, Ben Haller wrote:
As for NSTableView, it does appear to be doing minimal drawing. So
I guess all the string-drawing overhead I see in Sampler is just
from the single column that is updating, which is unfortunate since
it means I have no room for optimization. I
On 20-Oct-09, at 6:54 AM, Uli Kusterer wrote:
On 19.10.2009, at 23:58, Ben Haller wrote:
On 19-Oct-09, at 5:27 PM, Dave Keck wrote:
Would NSView's -getRectsBeingDrawn:count: help?
Well, I'm already using it in my own code where appropriate. (Or
actually I'm using -needsToDrawRect:).
On 20/10/2009, at 10:42 PM, Ben Haller wrote:
So whether -needsToDrawRect or -getRectsBeingDrawn:count: is a
better solution depends mostly upon taste, and a little bit on how
many tests you intend to do in your draw method (i.e. efficiency to
testing). For my purposes, doing a total of
On 20-Oct-09, at 6:59 AM, Uli Kusterer wrote:
On 20.10.2009, at 03:02, Ben Haller wrote:
As for NSTableView, it does appear to be doing minimal drawing. So
I guess all the string-drawing overhead I see in Sampler is just
from the single column that is updating, which is unfortunate since
On 20/10/2009, at 11:03 PM, Ben Haller wrote:
AFAIK even -[NSAttributedString drawWithRect:options:] doesn't let
you draw a string centered or right-aligned in the rect, which seems
like a big oversight. I've just logged 7318495 on that.
That's not the case - NSAttributedString takes
On 20.10.2009, at 13:42, Ben Haller wrote:
So whether -needsToDrawRect or -getRectsBeingDrawn:count: is a
better solution depends mostly upon taste, and a little bit on how
many tests you intend to do in your draw method (i.e. efficiency to
testing). For my purposes, doing a total of two
On 20.10.2009, at 14:03, Ben Haller wrote:
implying that doing things this way is faster than NSStringDrawing.
Is that actually true? Why would that be? NSStringDrawing does
more or less exactly this, doesn't it, using cached a cached
textstorage/layout/container set? If NSStringDrawing
On 20-Oct-09, at 8:15 AM, Graham Cox wrote:
On 20/10/2009, at 11:03 PM, Ben Haller wrote:
AFAIK even -[NSAttributedString drawWithRect:options:] doesn't let
you draw a string centered or right-aligned in the rect, which
seems like a big oversight. I've just logged 7318495 on that.
Hi all. I expected this to be an FAQ, but my searches have turned
up nothing relevant, so here goes.
I've got a window with a view hierarchy like this:
1. Superview that does no drawing and is not opaque
A. Subview #1: a tableview that is opaque
B. Subview #2: a graph
Would NSView's -getRectsBeingDrawn:count: help?
___
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
Ben Haller wrote:
1. Superview that does no drawing and is not opaque
A. Subview #1: a tableview that is opaque
B. Subview #2: a graph view that is opaque
C. Subview #3: another graph view that is opaque
Obvious experiment: set the superview to be opaque.
-- GG
On 19-Oct-09, at 5:27 PM, Dave Keck wrote:
Would NSView's -getRectsBeingDrawn:count: help?
Well, I'm already using it in my own code where appropriate. (Or
actually I'm using -needsToDrawRect:). But the problem is that a
whole bunch of NSTableView cells are getting drawn that never
On Monday, October 19, 2009, at 05:58PM, Ben Haller
bhcocoa...@sticksoftware.com wrote:
On 19-Oct-09, at 5:27 PM, Dave Keck wrote:
Would NSView's -getRectsBeingDrawn:count: help?
Well, I'm already using it in my own code where appropriate. (Or
actually I'm using -needsToDrawRect:). But
On 19-Oct-09, at 5:58 PM, Greg Guerin wrote:
Ben Haller wrote:
1. Superview that does no drawing and is not opaque
A. Subview #1: a tableview that is opaque
B. Subview #2: a graph view that is opaque
C. Subview #3: another graph view that is opaque
Obvious
On 20/10/2009, at 8:58 AM, Ben Haller wrote:
I think the problem is deeper (based upon what flashes under Quartz
Debug): I think the dirty rects are actually getting consolidated
such that NSTableView no longer has the information it needs to do
minimal drawing. I could be mistaken
On 19-Oct-09, at 6:53 PM, Andy Lee wrote:
On Monday, October 19, 2009, at 05:58PM, Ben Haller bhcocoa...@sticksoftware.com
wrote:
I think the problem is deeper (based upon what flashes under Quartz
Debug): I think the dirty rects are actually getting consolidated
such
that NSTableView no
Come to think of it, another experiment would have been to add logging
to the cells used for the other table columns, to see if their drawing
code was actually being called.q
Sorry if I missed this, but is the string-drawing overhead noticeable
to the user? If so, and it's because you're
On 19-Oct-09, at 10:40 PM, Andy Lee wrote:
Come to think of it, another experiment would have been to add
logging to the cells used for the other table columns, to see if
their drawing code was actually being called.
Yeah, I did that. See my previous post. The upshot is that the
On Oct 19, 2009, at 11:00 PM, Ben Haller wrote:
Well, I'm curious about the coalesced update thing. The only ref I
find through Google is here:
http://developer.apple.com/mac/library/documentation/Performance/Conceptual/Drawing/Articles/CocoaDrawingTips.html
and I don't think that's what
20 matches
Mail list logo
