I'm drawing some custom shapes behind a textview to make it appear it's a notepad. It draws a repeating bitmap across the top, as well as a white background under the text, and a secondary "note" page under the rest to add a little dimension and layering. See the screenshot:
Now, this is with setDrawingCacheEnabled(true) for the TextView this drawable is applied to. With this method call applied, the scrolling is VERY smooth, exactly what I want. Without it, the black background disappears, but the scrolling is very choppy. Any idea on how to cache this view so that scrolling is smooth without destroying my UI?
Seems this function only works with solid colors, as defined in the documentation which I should have read before posting. I find it hard to believe there's nothing that caches complex views and drawables to work as well as that function does, but, whatevs. Live 'n learn.
Related
I am creating an app for practice that is a simple drawing app. The user drags his/her finger along the screen and it colors in a 100px x 100px square.
I currently achieve this by creating a new colored UIView where the user taps, and that is working. But, after a little time coloring in, there is substantial lag, which I believe is down to there being too many UIViews as a subview of the main view.
How can I, and others who similarly create UIViews on dragging a finger reduce the lag to none at all, no matter how many UIViews there are. I also think that perhaps this is an impossible task, so how else can someone like me color a cube of the size stated above in the main view on a finger dragged along the screen?
I know that this may seem like a specific question, but I believe that it could help others understand how to reduce lag if there are a very large amount of UIViews where a less performance reducing option is available.
One approach is to draw each square into an image and display that image, rather than keeping around an UIView for each square.
If your drawing is simple enough, though, you can use OpenGL to do this, which is much faster. You should look at Apple's GL Paint Sample Code which shows how to do this in OpenGL.
If your drawing is too complex for OpenGL, you could create, for example, a CGBitmapContext, and draw each square into that context when the user drags their finger. Whenever you draw a new square into that bitmap, you can turn the bitmap into an image (via CGBitmapConxtextCreateImage) and display that image an a UIImageView.
There are two things that come to my mind:
1- Use Instruments tool to check if you are leaking any memory
2- If you are just coloring the views than instead of creating images for each of them, either set the background color property of UIView or override the drawRect method to do custom drawing
I think what you are looking for is the drawRect: method of UIView. You could create your custom UIView (you propably have that already) and override the drawRect method and do your drawing there! You will have to save your drawings in an array or another container and call the setNeedsDisplay method whenever the array content is changed.
I'm using a webview to display a PDF.
The webview displays the PDF at it's actual size which is a little smaller than the size of the webvieww itself, revealing the scroll view underneath it.
I've tried setting the Webview to opaque and setting it's background color to another color, which works fine and dandy in the simulator, but fails to change the color on the device. On the device it changes the color of the background of the view behind the scroll view, this can be seen when the PDF is pulled all the way down.
I've also tried setting all the UIView's backgrounds, by iterating through the subviews but to no avail.
I've updated a diagram to help illustrate which area I'd like to color.
Uploaded Diagram
You really shouldn't mess around with UIWebView's internals.
They can change anytime and your code might just crash on the next version of iOS.
If you need more control about pdf display, you might wanna take a look at other possibilities to show pdf, like using the CGPDFDrawPage* functions. Of course they are pretty low-level and it's a lot of work required until you can get fast page display, zooming, etc all right.
I'm currently working on an app which needs to draw s.th. like a network graph. Unfortunately this graph can become very big with thousands of movable objects.
I tried to put a giant UIView inside a UIScrollView but soon noticed this won't work because of memory limitations.
So I tried another approach: currently I have a UIView which has exactly the size of the visible part of the UIScrollView. The scrollview is set to not handle the scrolling (only the pinching). Instead I handle the scrolling in the UIView. Everytime a user scrolls, all graphic objects (those graphic objects are currently just subclasses of NSObject, which contain custom drawing code) are moved, so it seems like the view is scrolling. In the drawRect I only draw the graphics that are currently visible.
Also I constantly add and remove sublayers if they are moved out/in the visible frame
This works very smooth even with thousands of objects.
Unfortunately this approach has some drawbacks:
I can't zoom out to see all the objects in the graph, instead the user can only see a part of it
I don't get the inertial scrolling the UIScrollView offers
Other approaches I tried, like the CATiledLayer, don't work either because all the objects in the graph are draggable by the user and it looks really ugly if I use a CATiledLayer...
Swapping out the UIView with other UIViews while the user scrolls may help with the inertial scrolling, but it makes everything more complicated and zooming out completely still won't work :-(
Do you know of any best practices to draw graphs that can be very big?
//edit: I ended up with a uiscrollview which has a subview which has a cascrolllayer which has many sublayers. While zooming in and out the frame of the uiscrollviews subview is constantly changed to the uiscrollviews bounds by view.frame = scrollview.bounds. While dragging the scrollview the cascrolllayer is always forced to scroll to the current offset of the scrollview.
I needed to subclass the uiscrollview and hack around in order to make the zooming work nicely, but it's working well now. This approach works very well and allows very big graphs with lots of draggable elements.
//edit: see my other answer below, the approach above didn't work out as well as I initially thought, especially the zooming part
CATiledLayer is definitely what you should use here—there’s not really another solution that’ll let you use Quartz/UIKit drawing on a huge zoomable canvas. For anything that needs to be interactive (dragged or animated or whatever), you can disable its display in the main tiled layer and overlay another view or layer on top of it that just contains the object being interacted with.
I want to create a simple application which performs some calculations and then draws some images on view. I use NSBezierPath. Then I must resize the view and allow people scroll the finished picture. But i don't know how.If I also try to draw an image on an invisible part of canvas then it becomes invisible or isn't drawn (I couldn't know the future canvas size).
Check out the Apple sample code called BezierPathLab. I think that will get you started. There's lot of other sample code for Quartz 2D drawing too.
Being able to scroll and resize the view should be as simple as putting the view that you will be using to draw inside an NSScrollView.
I have an UITableView in my application, which is in an UIView that has it's background colour to the Scroll View Texture thing. This is all in an UIViewController. It works all nicely and stuff, but I get these fugly black corners around my table view edges:
The Background colour of the table view is set to the clear colour, and those squares even appear in Interface Builder. Any ideas on how to eradicate these evil UI blemishes? They make my UI look like something that was thrown together in 3 minutes, even when I spent more than a week designing my entire UI. It makes me want to punch UITableView in the face, too.
Quite strangely, setting the background to clear in code seemed to solve it for me. It is a really weird issue, and I submitteda bug report to Apple about this, although their bug reporter needs it's own bug reporter.
Also make sure the background color is not just clear color, but that opaque is NO.