I'm reading up on SurfaceView and how to use it, and I've come across some information that states that a SurfaceView has View#willNotDraw() set to false by default, and that it's up to you to call SurfaceView#onDraw(). I also read that RomainGuy said that this is done by default because it is more efficient. My question now is, when should you handle calling SurfaceView#onDraw() in a separate thread, and when should you just set View#willNotDraw() to true, and just call SurfaceView#invalidate(). Is there a difference between the two, and does one improve performance more than the other?
See:
http://developer.android.com/reference/android/view/View.html#setWillNotDraw(boolean)
I'm not sure where you got your information, but at least the javadoc says that most users will set this to false to get Android to send it onDraw events itself. As for your question about when you should do this, I would say it comes down to why you're using a SurfaceView.
If your view is displaying something dynamic (e.g. for a game or something that has a tight event loop), you'll want to be controlling exactly when updates happen, especially if you'll have the information to use one of the more detailed forms of invalidate to save redrawing the entire View. You won't want Android to call invalidate for you, and that's why the flag is there.
If, on the other hand, you are simply drawing something static, it makes sense to let Android's UI stack control the invalidations.
By the way, invalidate only posts a request to re-draw the View, so be aware of this if you intend to use the event-loop style (onDraw will be called sometime after you call it).
Edit: some clarifications.
Using SurfaceView.onDraw() and SurfaceView.invalidate() will make SurfaceView behave like a normal View and you will pay for the extra overhead associated with SurfaceView. If you want to draw from the UI thread, use a regular View instead. It's easier and cheaper.
Related
From Activity lifecycle we know, that in onResume the UI is visible. But if I set a breakpoint on onResume, I still don't see it, only after that. I heard there's some method which can check it, but I can't remind how it calls. We used it to make better animation. So how can I be fully sured that UI is ready?
Add global layout listener on view you want to check. Also please make sure that you remove listener once your work is done else it will keep getting called multiple times.
#onik shared a good link that should solve your problem
This ensures lay-outing. Drawing happens continuously and frame are refreshed according to sys clock.
I recommend watching: https://www.youtube.com/watch?v=Q8m9sHdyXnE
This will give you good idea on android drawing and layouting
I am targeting mobile using FlashBuilder, I am using TileLayout to view items of data, I am setting useVirtualLayout to "true"
I have some questions please:
Is item renderer resued by default? or shall I set it to true my self?
How can I control the range of items being virtualized?
Is there any tips on boosting performance of building child items of TileLayout ?
If native TileLayout is slow, is there alternative control to use? if building my own would be better, is there any example to build custom layout?
It is set to true by default. There are a few instances where they are not virtualized, however. If you have the list sizing to fit its contents, I don't believe virtualization occurs. If I am not mistaken, virtualization only occurs when an ItemRenderer leaves the viewport of the parent List control. So if you have a list on a page and that page is controlling the scrolling and not the list, I don't believe virutalization occurs. That is what I have seen in the past. Not sure if that is how it actually works, but that is the impression I have gotten. Easy way to find out is to throw a trace statement in your DataChange handler. If it traces out after initialization, you know virtualization is working
I'm not sure you can control this. You may be able to write a custom layout that does it, but that is likely more trouble than it is worth
The TileLayout itself is likely not the issue you are having, it is the ItemRenderer.
On mobile, do not extend any ItemRenderer class except LabelItemRenderer and IconItemRenderer.
Do not write a renderer in MXML. Write in AS3.
Utilize the proper renderer life-cycle. This means you should do very little in your constructor. Maybe set a few properties, but do not instantiate any DisplayObject. Instead, override createChildren() and do it there. Override layoutContents() for positioning and sizing. Override drawBackground() for handling the background. I highly suggest reading this post from Flextras (you'll see him going by Reboog77 on SO) about writing mobile item renderers. https://www.flextras.com/blog/index.cfm/2011/6/24/Building-a-Mobile-ItemRenderer-in-Flex
Keep the renderers as simple as possible. If you can get away with drawing directly into the object using the Graphics class, do that instead of using a Rect or similar.
Text is slow to render. Do not change it often and keep the text seen in the renderer to a minimum
Use ContentCache for any images outside of the iconDisplay in IconItemRenderer. ContentCache will negate the need for reloading images every single time.(iconDisplay/icon already utilizes this by default)
I'm curious guys,
What are the exact cases doTraversal -> performTraversals is called? Since I have pretty heavy Activity, I want the application to call onDraw or the sort. performTraversals is pretty heavy, it is trying/measuring if it should resize views, stuff like that I guess. And I don't need it when I'm making some view, that no other view is dependent on, GONE, but I guess I can't skip that. So before digging into the source of Android, I want to ask. If you know it, please feel free to share :)
Thanks,
Danail
performTraversals() has many jobs but its three main roles are:
Measure views
Layout views
Draw views
Every time Android needs to redraw a window, performTraversals() is invoked. It does not mean however that measure/layout happens every time performTraversals() executes. You cannot skip performTraversals() if you are using a standard views (only SurfaceView lets you bypass this when drawing.)
My answer to this question was just accepted but I started to wonder when exactly one needs to invalidate() a View and when it is not necessary?
After a bit of thinking I came to realization that it should work more or less like this:
actual drawing of "everything" occurs after onResume()
in "free" time parts of the screen can be redrawn but only those that were invalidated (and everything underneath)
Therefore, it would seem, if I change something after onResume() (e.g. as a response to a button click, I should invalidate() the changed View).
However, from what scana in this question says, it must be more complex then that and it depends somethimes on what method one uses.
E.g. on whether one uses
lastClicked.setImageBitmap();
or
lastClicked.setImageResource();
So, when it's necessary to execute invalidate() on a View and how does it really work ?
(Do consider accepting some answers)
Generally, invalidate() means 'redraw on screen' and results to a call of the view's onDraw() method. So if something changes and it needs to be reflected on screen, you need to call invalidate(). However, for built-in widgets you rarely, if ever, need to call it yourself. When you change the state of a widget, internal code will call invalidate() as necessary and your change will be reflected on screen. For example, if you call TextView.setText(), after doing a lot of internal processing (will the text fit on screen, does it need to be ellipsised, etc.), TextView will call invalidate() before setText() returns. Similarly for other widgets.
If you implement a custom view, you will need to call invalidate() whenever the backing model changes and you need to redraw your view. It can also be used to create simple animations, where you change state, then call invalidate(), change state again, etc.
Usually, the system handles resizing, hiding, showing and a ton of other things for your widgets automatically but it sometimes has issues if the underlying buffer for drawn pixels or backing data has changed or is stale (you swap the image resource on a View or the raw dataset changes). This occurs because there is no way that the OS can know that the data changed in the specific manner that it did.
In these cases where you are dealing with drawing, you have to tell the system that its underlying data is not in a good state with Widget.invalidate() and the re-drawing gets queued on the main thread just as you mentioned. Depending on the system implementation and Android version what is tracked for changes by the system varies but what I normally do is assume that system resources (byte arrays, char arrays, resource indexes, manual drawing on the context) are not tracked and need an invalidate and everything else will be handled by the system.
Please remember that drawing on the screen is frequent process, whenever you update a view, that change should be propogated and redrawn to notify such change right. invalidate() is a trigger method,that signals force reDrawing of any view you wish to show changes for.
I had this problem when I wanted to draw a textPaint!
My code was
canvas.drawPaint(textPaintNumber)
canvas.drawText("MyText", 30F, 63F, textPaintNumber)
I cleared the first lint and the problem was solved
canvas.drawText("MyText", 30F, 63F, textPaintNumber)
On android we have onDraw(). What is the equivalent in iOS ?
You probably want drawRect:, though depending on what you want in your view there might be other options of interest (subviews & Core Animation layers). See the View Programming Guide.
If you're writing a custom view, it's basically -drawRect: which gets called on the view every time the system wants to redraw (e.g., every time the runloop turns and -setNeedsDisplay flag is set.
you override the -drawRect method of a UIView to do direct drawing to the screen. However this isn't commonly needed for lots of use cases. If you want, provide more detail about what you want to achieve. There may be a more iOS way.