I've noticed my whiteboard app becomes 'dormant' after a few seconds of no interaction, so that when something is newly drawn, there is horrible lag. This is without switching away from the app at all - I run it, it's there, I can draw and undo. But if I don't use it for 10 seconds and then try and draw a circle, there can be a second or so of wait before it updates and I get a straight line from start point to current position. So the code to start drawing is instant when the view is touched, but the updates aren't happening for a good while yet.
The code is effectively the Fingerpaint demo drawing onto a custom bitmap, and I copy this bitmap to the view. I undo by copying the bitmap just before drawing starts. I have disabled the undo code to see if that was the issue, but the delay is still there, only far less pronounced. I notice the same lag sometimes happens in the Fingerpaint API demo.
Anyone know why this is? Is there some odd setting I don't know about which causes an active app to go to sleep?
I have looked at some threads concerning real-time line drawing (for items like ECG traces) and all solutions are based upon the idea that the graph is the main activity. What I need is a popup situation where the line graph is drawn only when it is needed.
Can one attach a 'surface' to a PopupWindow? Right now I use an AlertDialog and invalidate() of a Canvas and that stinks as first it is not real time (the entire set of data is drawn then updated so one gets 'flashes' each update) and second the AlertDialog appears impossible to control the size of (same size both orientations) BUT I do see data displayed in the background behind the Dialog box in a scrolled ListView which is the main activity of the application.
I would even be happy if I could get real time drawing in the AlertDialog without this ugly invalidate() though the inability to specify its size is frustrating!
I am doing translation of imageviews in android 2.3.3 using translation animation and disabling/enabling cards accoridngly. Due to the heavyness of this, it seems that there are some "stale" drawing left on the screen (as if the rendering is leaving some random black spots).
Is there a function that I can call which redraws the whole screen as I want my final view (after all the animations are completed) to be clear with no black spots?
Thank you
What is a Window in Android?
I thought the top-most level in Android is called Activity, which is the screen you see.
Can someone tell me what a Window in Android is? do we just have one or multiple of them.
[UPDATE] (Let me share what I've learned about Window after original answer)
In one sentence, A Window is a rectangular area which has one view hierarchy. Colored rectangles in below image are windows.
As you can see, there can be multiple windows in one screen, and WindowManager manages them. Window list in current screen can be obtained via Hierarchy Viewer, or adb shell dumpsys window.
Window list in Hierarchy Viewer example :
(Below is original answer)
I had the same question, and I hope this could help you guys.
According to Android Developer Documentation,
"Each activity is given a window in which to draw its user interface."
and, Dianne Hackborn, who is a Android framework engineer, gave some definitions here. She said,
A window is basically like you think of a window on the desktop. It has a single Surface in which the contents of the window is rendered. An application interacts with the Window Manager to create windows; the Window Manager creates a Surface for each window and gives it to the application for drawing. The application can draw whatever it wants in the Surface; to the Window Manager it is just an opaque rectangle.
A Surface is an object holding pixels that are being composited to the screen. Every window you see on the screen (a dialog, your full-screen activity, the status bar) has its own surface that it draws in to, and Surface Flinger renders these to the final display in their correct Z-order. A surface typically has more than one buffer (usually two) to do double-buffered rendering: the application can be drawing its next UI state while the surface flinger is compositing the screen using the last buffer, without needing to wait for the application to finish drawing.
A View is an interactive UI element inside of a window. A window has a single view hierarchy attached to it, which provides all of the behavior of the window. Whenever the window needs to be redrawn (such as because a view has invalidated itself), this is done into the window's Surface. The Surface is locked, which returns a Canvas that can be used to draw into it. A draw traversal is done down the hierarchy, handing the Canvas down for each view to draw its part of the UI. Once done, the Surface is unlocked and posted so that the just drawn buffer is swapped to the foreground to then be composited to the screen by Surface Flinger.
Also, I found some other info from Romain Guy's presentation(You can watch his talk at San Francisco Android user group from here, and download full slides from here)
So, in a nutshell:
An Activity has a window (in which it draws its user interface),
a Window has a single Surface and a single view hierarchy attached to it,
a Surface include ViewGroup which holds views.
I'd like to say in brief:
Application --->
Activity --->
Window Manager --->
Window --->
Surface --->
Canvas --->
View Root --->
View Group --->
View --->
Bitmap/Open GL panel --->
Current Surface Buffer --->
Surface Flinger --->
Screen
Here is a very basic and simple conceptual overview of how interaction happens among the Window, Surface, Canvas, and Bitmap.
The Activity is what you would call a Window.
Technically speaking, the Activity creates the Window for you.
You can have many of them, but normally not synchronously. To ask for additional information you can call a Dialog, or fire an Intent to another Activity.
For more information visit this link.
After getting so much help from Stack-Overflow I'd like to share back some of my experience:
I spent hour of debugging with one special
09-18 08:11:37.177: DEBUG/SEC_Overlay(128): overlay_setPosition(-1) 03,680,90,120 => 503,680,90,120
09-18 08:11:37.177: INFO/SEC_Overlay(128): Nothing to do!
This is logged each time the GLSurfaceview is updating. But only when the GLSurfaceview is used in combination with a relative Layout and a camera preview. This is combination is essential for the AndroAngelo App. On the main screen I have the radial OnScreenMenu overlayed onto the GLSurface view and on the calibration screen I put the result of the image detection onto the preview.
It decreases the performance essentially.
What to do?
I really did not went to the ground of it. It appeared two times. The second time it just disappeared after a restart of the eclipse. The first time maybe also, but I played around with camera parameters. And then it disappeared.
It comes back from time to time. It seems to be something in the phone. Each time it appears, i simple reboot the Android device and it is gone afterwards.