I need to perform efficient hit testing against a (potentially huge) number of components so I've represented all my primitives as NSBezierPath instances. All working great so far.
Now I'm having trouble converting NSString objects, in particular reflecting their position in the view:
I'm using the NSString (BezierConversions) category from Apple's SpeedometerView example to convert strings into bezier paths.
The bezier path created for strings looks great but positioning it to match the position of the NSString instances location in the view doesn't quite work so I suppose this question is really about
NSBezierPath and transformUsingAffineTransform: vs.
a combination of NSAffineTransform applied to a view and NSString drawAtPoint:
In my test project even the trivial case fails:
Grey bezier representation of string drawn using:
NSAffineTransform *moveFinal = [NSAffineTransform transform];
[moveFinal translateXBy:x yBy:y];
[textBezier transformUsingAffineTransform:moveFinal];
and the purple string via
[testString drawAtPoint:NSMakePoint(x, y)
withAttributes:attributes];
Same attributes, same input positions, different location in view.
And it just gets worse with rotated text.
UPDATE #1
Looks like it's boiling down to different bounding boxes returned by
NSString sizeWithAttributes:
NSBezierPath bounds
Now experimenting with NSString boundingRectWithSize
FWIW - Working now.
Using boundingRectWithSize:options:attributes: with the NSStringDrawingUsesDeviceMetrics option gives some good text dimensions to work with, including the actual bounding box occupied by the string when drawn and the offset of the first glyph.
Offset the NSBezierPath returned from bezierWithFont: by that amount and you're good to go..
Related
I'm doing some text analysis and have run into an annoying performance bump that I can't seem to find how to optimize. I start with the text from a UITextView and split the text into an array of sentences, splitting on characters in ".?!".
Then I loop over each sentence, splitting the sentence into an array of words, and pulling the first and last word from the sentence. With the NSRange of the sentence text in hand, I find the range of the first and last word in the UITextView's text.
The following part is where I get nailed with performance drains. This is how I find the bounding CGRect of the first and last word:
// the from range is increased each iteration
// so i'm not searching the entirety of the text each pass
NSRange range = [textView.text rangeOfString:firstWord options:kNilOptions range:fromRange];
UITextPosition *beginning = textView.beginningOfDocument;
UITextPosition *start = [textView positionFromPosition:beginning offset:range.location];
UITextPosition *end = [textView positionFromPosition:start offset:range.length];
UITextRange *textRange = [textView textRangeFromPosition:start toPosition:end];
firstRect = [textView firstRectForRange:textRange];
I perform this twice, once for the first word and once for the last word.
This works well on smaller text, but approaching 5+ paragraphs Instruments tells me that the UITextView -positionFromPosition: operation is eating up 492ms of clock time, locking up the UI and CPU at 100%.
The thing is I need the CGRect surrounding the first and last words so I can build a CGPath to highlight the sentence. The entire thing works and looks really great, but its the hang while the rects are found that is killing me. I'm fairly new to using UITextView's, so if there is something I can do, either optimizing my searches with ranges or somehow placing my operations on a background thread, I'd be much obliged.
You'll be better off using UITextView's attributedText property, which takes an NSAttributedString. With that, you can set the NSBackgroundColorAttributeName to a colour over a specific range.
Just note the attributed text methods only work in iOS 6+.
In Cocos2D, I would like a sprite placed on a screen coordinate, not a map coordinate. I thought I could get by using convertToNodeSpace, but it doesn't seem to do what I want.
I thought this should place a sprite in the middle of my iPad screen:
selectionScreenOverlaySprite.position = [self convertToNodeSpace:CGPointMake(512, 384)];
But it doesn't. It also places it in a different place depending on the size of my map. Does anyone know what I should be using? I've also tried: convertToWorldSpace, convertToNodeSpaceAR, and convertToWorldSpaceAR.
Try this:
CGSize wins = [[CCDirector sharedDirector] winSize];
[yourSprite setPosition:CGPointMake(wins.width / 2, wins.height / 2)];
This is better than using hard-coded values because it will work regardless of resolution.
I'm using -[NSString sizeWithFont] to get the text height. The character 't' is clearly taller than 'm', but -sizeWithFont returns the same height for both these strings. Here's the code:
UIFont* myFont = [UIFont fontWithName:#"Helvetica" size:1000.0];
NSString* myStr = #"m";
CGSize mySize = [myStr sizeWithFont:myFont];
With 'm' as shown, it returns {834, 1151}. With myStr = #"t" instead, it's {278, 1151}. The smaller width shows up as expected, but not the height.
Does some other function wrap the text tightly? I'm ideally looking for something equivalent to Android's Paint.getTextBounds().
The information you get back from this method is basically the line height for the font (i.e., it's the ascent plus the descent for the font you've chosen). It's not based on individual characters, it's based on specific font metrics. You can get most of the information about a font's metrics from the UIFont class (e.g., the method -ascender gives you the height of the ascender for the font). Mostly, you will be dealing with the total amount of vertical space needed to draw the glyphs with the heights ascenders and the lowest descenders for that font. There is no way to get information about individual glyphs from UIFont. If you need this information, you'll have to look at the CoreText framework, which gives you a lot more flexibility in how you draw and arrange glyphs but is far, far more complicated to use.
For more information on dealing with text in your app, please se the Drawing and Managing Text section of the Text, Web, and Editing Programming Guide. It is also a good launching point for most of the frameworks and classes you'll need to deal with whether you go the UIKit or the CoreText route.
Hmmm... I assume you're only going to be working with individual characters then. sizeWithFont, as noted above, returns the height of the largest character of that font as the text field is going to be that height no matter what you do. You would be able to get the LARGEST height values (UIFont's CGFloat capHeight) however it looks like you're going to be working with all kinds of text
I would take a look at the CoreText framework. Start here and read away. Inevitably you're going to end up with something along the lines of this:
CGFloat GetLineHeightForFont(CTFontRef iFont)
{
CGFloat lineHeight = 0.0;
check(iFont != NULL);
lineHeight += CTFontGetLeading(iFont);
return lineHeight;
}
how to generate an end screen when two images collide. I am making an app with a stickman you move with a very sensitive acceremeter. SO if it hits these spikes, (UIImages) it will generate the end screen. How do I make the app detect this collision and then generate an end screen.
I'm sure you know the rect of the two images because you need to draw them so you can use
bool CGRectIntersectsRect (
CGRect rect1,
CGRect rect2
);
It returns YES if the two rects have a shared point
The fact that you haven't declared any rects doesn't matter. You need rects for collision detection. I assume that you at least have x and y coordinates for the stickman and you should have some kind of idea of his height and width. Judging from the question title it seems like you're using images to draw the objects you want to check for collision, so you should know the height and width of the images you're using. If you don't have this info you can't draw the objects in the right place and you certainly can't check for collisions.
You basically want to use the same rects that you use for drawing the objects.
Some code examples:
If your coordinates point to the middle of the stickman you would use something like the following:
if (CGRectIntersectsRect(CGRectMake(stickman.x-stickman.width/2,
stickman.y-stickman.height/2,
stickman.width,
stickman.height),
CGRectMake(spikes.x-spikes.width/2,
spikes.y-spikes.height/2,
spikes.width,
spikes.height))) {
// Do whatever it is you need to do. For instance:
[self showEndScreen];
}
If your coordinates point to the top left corner of your stickman you would use:
if (CGRectIntersectsRect(CGRectMake(stickman.x,
stickman.y,
stickman.width,
stickman.height),
CGRectMake(spikes.x,
spikes.y,
spikes.width,
spikes.height))) {
// Do whatever it is you need to do. For instance:
[self showEndScreen];
}
If I might give you a suggestion, I would suggest storing the coordinates and sizes in a CGRect, so that you don't have to create a new CGRect every time you're checking for collision.
in a simple drawing application I have a model which has a NSMutableArray curvedPaths holding all the lines the user has drawn. A line itself is also a NSMutableArray, containing the point objects. As I draw curved NSBezier paths, my point array has the following structure: linePoint, controlPoint, controlPoint, linePoint, controlPoint, controlPoint, etc... I thought having one array holding all the points plus control points would be more efficient than dealing with 2 or 3 different arrays.
Obviously my view draws the paths it gets from the model, which leads to the actual question: Is there a way to optimize the following code (inside the view's drawRect method) in terms of speed?
int lineCount = [[model curvedPaths] count];
// Go through paths
for (int i=0; i < lineCount; i++)
{
// Get the Color
NSColor *theColor = [model getColorOfPath:[[model curvedPaths] objectAtIndex:i]];
// Get the points
NSArray *thePoints = [model getPointsOfPath:[[model curvedPaths] objectAtIndex:i]];
// Create a new path for performance reasons
NSBezierPath *path = [[NSBezierPath alloc] init];
// Set the color
[theColor set];
// Move to first point without drawing
[path moveToPoint:[[thePoints objectAtIndex:0] myNSPoint]];
int pointCount = [thePoints count] - 3;
// Go through points
for (int j=0; j < pointCount; j+=3)
{
[path curveToPoint:[[thePoints objectAtIndex:j+3] myNSPoint]
controlPoint1:[[thePoints objectAtIndex:j+1] myNSPoint]
controlPoint2:[[thePoints objectAtIndex:j+2] myNSPoint]];
}
// Draw the path
[path stroke];
// Bye stuff
[path release];
[theColor release];
}
Thanks,
xonic
Hey xon1c, the code looks good. In general it is impossible to optimize without measuring performance in specific cases.
For example, lets say the code above is only ever called once. It draws a picture in a view and it never needs redrawing. Say the code above takes 50 milliseconds to run. You could rewrite it in openGL and do every optimisation under the sun and get that time down to 20 milliseconds and realistically the 30 milliseconds that you have saved makes no difference to anyone and you pretty much just wasted your time and added a load of code-bloat that is going to be more difficult to maintain.
However, if the code above is called 50 times a second and most of those times it is drawing the same thing then you could meaningfully optimise it.
When it comes to drawing the best way to optimise is to is to eliminate unnecessary drawing.
Each time you draw you recreate the NSBezierPaths - are they always different? You may want to maintain the list of NSBezier paths to draw, keep that in sync with your model, and keep drawrect solely for drawing the paths.
Are you drawing to areas of your view which don't need redrawing? The argument to drawrect is the area of the view that needs redrawing - you could test against that (or getRectsBeingDrawn:count:), but it may be in your case that you know that the entire view needs to be redrawn.
If the paths themselves don't change often, but the view needs redrawing often - eg when the shapes of the paths aren't changing but their positions are animating and they overlap in different ways, you could draw the paths to images (textures) and then inside drawrect you would draw the texture to the view instead of drawing the path to the view. This can be faster because the texture is only created once and uploaded to video memory which is faster to draw to the screen. You should look at Core Animation if this is what you need todo.
If you find that drawing the paths is too slow you could look at CGPath
So, on the whole, it really does depend on what you are doing. The best advice is, as ever, not to get sucked into premature optimisation. If your app isn't actually too slow for your users, your code is just fine.