When decoded output buffer is available and you want to render it onto the screen. With MediaCodec NDK APIs, you have an option to call AMediaCodec_releaseOutputBufferAtTime() if you have a native window registered already to render.
My question is what is the code flow once you have called AMediaCodec_releaseOutputBufferAtTime() until the frame gets displayed onto the screen. I know little-little about the flow. Like the function mentioned here calls queueBuffer() with the timestamp and queues the buffer on Native Window. Then this gets acquired on the next VSYNC event, and displayed on the next-next VSYNC event. Is my understanding right?
Also, I want to know what happens once queueBuffer() is called on ANativeWindow until the frame gets displayed onto the screen.
Related
I'm working in a legacy application using MFC.
We have a mechanism to enable/disable controls depending on some business logic.
This mechanism is implemented in the CView-derived class. The way it works is all the views in the application derived from a common CView-derived class (CBaseView) and on the PreTranslateMessage all controls of the view are enabled/disabled.
This worked fine so far because all controls send at least WM_PAINT message when they need to be painted. So the system worked without the user having to move the mouse or anything. I recently added some drawing features and I had to use WS_EX_COMPOSITE to get ride of some flickering. With this flag activated my CView-derived class is not getting any called to PreTranslateMessage when creating the view....so the controls are not disabled until the user moves the mouse over the control.
I understand there is no way to send WM_PAINT using WS_EX_COMPOSITE but is there other message I can use to get the same behaviour???
Edited:
I am currently using the OnIdle approach but it has a big drawback, the windows doesn't become idle until after drawing all the controls...so when you enter the screen al controls are enabled and inmediately they are disabled...this makes a quite ugly effect!
More solutions???
Thanks in advance...
The logical place to enable/disable controls would be CView::OnUpdate, it is called by the framework after the view's document has been modified and from OnInitialUpdate(); you can also call this function if there is some change that would trigger re-evaluation of your business logic.
EDIT
After reading the question a bit more closely, what you could also do is to post a private message at the end of OnInitialUpdate and "catch" it in your PreTranslateMessage:
PostMessage(WM_APP, 0, 0);
Calling InvalidateRect followed by UpdateWindow against the window in question will mark the entire client area as dirty and force an immediate repaint. Remember that WM_PAINT is not really a message, in the queue in the usual sense, it is pushed out after all other messages have been processed for that window, which would include any invalidations of the area being drawn. No message is generated at all if there are no invalid segments of the active window display.
I want to minimize my app and after the timer end get it back.
I use code below.
To minimize application use following line of code:
Display.getDisplay (MIDLET_CLASS_NAME).setCurrent (null);
To get the screen back use the following:
Display.getDisplay (MIDLET_CLASS_NAME).setCurrent (myCanvas);
But when phone display is dismissed and going to clock mode my midlet display isn't shown until press any button.
any idea?
From your question it sounds that you expect setCurrent to somehow "force" device to immediately display your screen or maybe return only after screen gets visible.
This is not so, as clearly explained in the API documentation for Display.setCurrent:
Requests that a different Displayable object be made visible on the display. The change will typically not take effect immediately. It may be delayed so that it occurs between event delivery method calls, although it is not guaranteed to occur before the next event delivery method is called. The setCurrent method returns immediately, without waiting for the change to take place...
...if the application is in the background, passing a non-null reference to setCurrent may be interpreted by the application management software as a request that the application is requesting to be brought to the foreground... These are only requests, and there is no requirement that the application management software comply with these requests in a timely fashion if at all...
Consider redesigning your MIDlet to adjust to specified behavior.
If myCanvas is an instance of Canvas, one can use showNotify() events.
For a generic Displayable screen isShown() method checks if the it is actually visible on the display.
Sometimes it could even make sense to let user explicitly confirm return from background, like
display.setCurrent(new Alert("back to foreground", "dismiss to continue...",
null, AlertType.INFO), myCanvas);
How do I prevent my GUI from redraw when it comes back from lock screen after receiving a UILocalNotification? In didReceiveLocalNotification I present a modal view, but the old state of my view controllers is shown for a moment before that. How do I prevent this?
Also the order of events I get when I come back on local notification from background is as following:
1. UIApplicationWillEnterForegroundNotification
2. UIApplicationDidBecomeActiveNotification
3. didReceiveLocalNotification
When I come from lock screen:
1. didReceiveLocalNotification
2. UIApplicationDidBecomeActiveNotification
Why is this difference and whether there is something else I'm missing?
Thanks
Here's how it was solved. May be it's not the way, but it worked for me. Since my application is voip/audio, it doesn't come to didFinishLaunchingWithOptions... I found out, that iOS uses a cached image from a previous state for animation when it resumes from background or from sleep mode. So the solution is basically to exchange this cached image with my default.png image. I do it in applicationWillResignActive delegate. There I add a modal view with a Default.png picture and dismiss it in applicationDidBecomeActive. This is really in short. Hopefully it will help somebody else with the same problem.
You can provide a custom image that is displayed when launching/resuming from a local notification. Simply set the alertLaunchImage property on your local notification to the name of the correct image.
From the Docs:
The string is a filename of an image file in the application bundle. This image is a launching image specified for a given notification; when the user taps the action button (for example, “View”) or moves the action slider, the image is used in place of the default launching image. If the value of this property is nil (the default), the system either uses the previous snapshot, uses the image identified by the UILaunchImageFile key in the application’s Info.plist file, or falls back to Default.png.
alertLaunchImage
How do I prevent my GUI from redraw when it comes back from lock screen after receiving a UILocalNotification? In didReceiveLocalNotification I present a modal view, but the old state of my view controllers is shown for a moment before that. How do I prevent this?
Also the order of events I get when I come back on local notification from background is as following:
1. UIApplicationWillEnterForegroundNotification
2. UIApplicationDidBecomeActiveNotification
3. didReceiveLocalNotification
When I come from lock screen:
1. didReceiveLocalNotification
2. UIApplicationDidBecomeActiveNotification
Why is this difference and whether there is something else I'm missing?
Thanks
Here's how it was solved. May be it's not the way, but it worked for me. Since my application is voip/audio, it doesn't come to didFinishLaunchingWithOptions... I found out, that iOS uses a cached image from a previous state for animation when it resumes from background or from sleep mode. So the solution is basically to exchange this cached image with my default.png image. I do it in applicationWillResignActive delegate. There I add a modal view with a Default.png picture and dismiss it in applicationDidBecomeActive. This is really in short. Hopefully it will help somebody else with the same problem.
You can provide a custom image that is displayed when launching/resuming from a local notification. Simply set the alertLaunchImage property on your local notification to the name of the correct image.
From the Docs:
The string is a filename of an image file in the application bundle. This image is a launching image specified for a given notification; when the user taps the action button (for example, “View”) or moves the action slider, the image is used in place of the default launching image. If the value of this property is nil (the default), the system either uses the previous snapshot, uses the image identified by the UILaunchImageFile key in the application’s Info.plist file, or falls back to Default.png.
alertLaunchImage
I am coding up a program for automated testing which randomly clicks an open application window using various User32.dll library calls. My current problem is this, if a click would open a dialog, using Process.WaitForInputIdle() does not wait long enough for that dialog to be detected the next trip around the loop, which means several clicks get cued and if those clicks happen to be on something in the dialog I want to avoid (say an exit button) there is no way of telling that in advance. My question is this. Is there a way of waiting for the process or thread to finish all processing and only be waiting in the message loop again?
I hope that made sense.
Cheers
Ross
EDIT
Failing this, would it be somehow possible to set the process / threads of the target program and my program to both use the same processor and adjust the prioritorys of each so that the target program gets preference?
WaitForInputIdle will unfortunately return as soon as the app is in a message loop with no input messages waiting.
If you own the code to the dialog, you could have the dialog call SetEvent in its WM_INITDIALOG to signal your automation that it is ready for testing. Alternatively, you could look at using SetWinEventHook on the process and wait for the dialog to actually be created before sending input events to it.
The way around this it seems is to use the SendMessage API instead of the mouse_event or SendInput API. The reason for this is that SendMessage blocks until it has been processed. Just make sure you always get the handle of the window immediatly under where you want to click (using WindowFromPoint) and convert the mouse coordinates from screen to client coords using ScreenToClient. Pack the coordinates into the lParam parameter by using ((pt.Y << 16) + pt.X). This will block until processed and so any modal dialogs shown will block this call.