I need to have a few buttons in my iPhone app (which may be then ported to iPad). I know at least 2 methods for making such buttons:
1. Using usual UIButton with an image as a background which can be drawn in any graphics editor.
2. Subclassing UIButton and implementing own drawRect: method using CoreGraphics tools.
I don't know why, but I tend to use the second one, since it seems to be more difficult and lower performing.
Am I right thinking that when implementing the button drawing programmatically, it becomes "cross platform" so that you don't need several icons for different resolutions?
If that is really simple icon, some bezier curve or circle filled with color. Will it still preform slower than an image-button?
And does somebody know any tool which has a graphical interface for drawing a vector image, and than converts it to the CoreGraphics code which one can paste into the drawRect: method?
Thank you.
Don't worry for using drawRect. Unlike Windows, iOS caches the results into a bitmap and will only redraw it when the dimensions of the view change (which is what you actually want - since you want to scale it again).
As for a vector app, you can use Opacity. It has an option to export the icon into CoreGraphics source code: http://likethought.com/opacity/
Related
I want to give a effect for UILabel text that will look exactly same like we are writing on a paper using pen. I searched for it but not getting any related suggestion/solutions, there are solutions like typing effect but not as I need.
The only way to accomplish this is to manually draw the stroked for the inserted letters via a graphics API (Core Graphics, OpenGL, etc.). You cannot accomplish this without manual drawing. It is possible that there's a 3rd party library that can help you with this. You can use a tool like PaintCode to extract the bezier paths and what not to help you manually drag glyphs for each letter in an alphabet and then animate those paths using Core Animation or another graphical drawing mechanism.
I'm considering building an app that would make heavy use of a flood fill / paint bucket feature. The images I'd be coloring are simply like coloring book pages; white background, black borders. I'm debating which is better to use UIImage (by manipulating pixel data) or drawing the images with Core Graphics and changing the fill color on touch.
With UIImage, I'm unable to account for retina images properly; it destroys the image when I write the context into a new UIImage, but I can probably figure out. I open to tips though...
With CoreGraphics, I have no idea how to calculate which shape to fill when a user touches an area and then actually filling that area. I've looked but I have not turned up a successful search.
Overall, I believe the optimal solution is using CoreGraphics, since it'll be lighter overall and I won't have to keep several copies of the same image for different sizes.
Thoughts? Go easy on me! It's my first app and first SO question ;)
I'd suggest using Core Graphics.
Instead of images, define the shapes using CGPath or NSBezierPath, and use Core Graphics to stroke and/or fill the shapes. Filling shapes is then as easy as switching drawing mode from just stroking to stroking and filling.
Creating even more complex shapes is made much easier with the "PaintCode" app (which lets you draw and creates the path code for you).
As your first app, I would suggest something with a little less custom graphics fiddling, though.
I'm using GLKit to create a game on the iPhone. setting up the GLKit context and drawing sprites on it isn't that hard but when I try to add text to it, it seems impossible to do.
I have searched around for an answer but all the solutions I tried to find can't be mixed in GLKView.
What is the best practice to render text in the GLKView?
"the best" in a sense of easiest would be to make an UILabel, set all the text and background parameters you want and then create UIImage from label's layer to create or update the texture.
The simplest answer is sometimes the best. While the documentation has some words discouraging compositing between GLES and Quartz, it can work quite well to overlay a GLKView with a standard UIKit view, such as a UITextView. You will, of course, want to confirm the performance impact on your least capable supported hardware / software configuration, but on a newer configuration, total rendering time remained below 1ms for an animating model while scrolling an overlaid UITextView with a clear background, set to be non-opaque.
As far as I know we can use core graphic such as CGContextSetShadowWithColor to draw a shadow. However, we can also use CALayer to show the shadow as well.
Question :
what are the differences between 2 of them. Are there any rules to determine when we use core graphic to draw a or when we use CALayer to do the job
I would have to say that using CoreAnimation is always preferred over CoreGraphics, since it's more high level, and abstracts the low-level details of drawing the shadow. (It may also allow apple to optimize the shadow drawing without hurting your code syntax).
However, there are times where you are overriding drawRect: anyways, and you have very specific use for the shadow, not the whole view's layer. You might wanna use CoreGraphics shadows here.
One last note, CoreAnimation gradients are much faster when rendering, take my word for it. I used it on UITableViewCell, and the scroll performance significantly increased, as opposed to using CoreGraphics Gradients. That comes at a price, though. It's a bit worse-looking.
I'm looking for ideas on how to draw a skinnable "button" in a game application. If I use a fixed sprite non-vector image for the button background, then I can't size the button easily. If I write code to draw a resizable button (like Windows buttons are drawn), then the programmer has to get involved -- and it makes skinning difficult. Another option is to break the button into 9 smaller images (3x3) and stretch them all -- kindof like rounded corners are done in HTML.
Is there another "easier" way? What's the best approach?
If you really want to accomplish this, the way to do it is with texture coordinates. Much like you would make a stretchable button/panel design in HTML with a table, you simply define the UV coordinates for the corners, the top stretchable area, the bottom stretchable area, the side stretchable areas, and then the middle.
For an example of this being implemented in an XNA engine (though it's a closed source engine), see this:
http://www.flatredball.com/frb/docs/index.php?title=SpriteFrame_Tutorial
Yes. I am working on an Editor. It's a XAML-like language (or OpenLaszlo-like, if you prefer) for XNA. So the buttons can be resized by the editor. The buttons might also be resized by a style sheet.
I guess you're right that it's likely that the buttons will all be the same size in a real design. But even in a window's app, you sometimes need to make a button wider to accomodate text.
It should be possible with shaders. You would probably have to do texel lookups, but it would cut down on the number of triangles in a complex UI.