2 frames are sharing global variables
the second frame display depends on the variables set by the the php script of first frame
Most of time it works .. but if the second frame is faster it's mess up
how can i synchronize them ?
the second php script of one frame will wait till the other finishes
actually sleep(1) in the beginning improved things a lot but it's not very reliable since the first frame accesses db and the result depends on execution time
finally i have done it using javascript. The first script generates
top.frames[1].location = ....
with parameter exec=1
initially the frame is called with different parameter exec=0
if ($_GET['exec'] == '0') return; // in the beginning of second php
Related
I checked the video stream displayed well in qml video surface. now I want to get the video frame data to do something not bad thing. but, It seems not doing well until now... I made a simple pipeline like below for focus on a test.
nvarguscamerasrc - appsink
I used QGst::Utils::ApplicationSink to get a frame data. I referenced an example "appsink-src"
/* making pipeline */
QGst::ElementPtr source, sink;
SubClassApplicationSink *appsink;
source = QGst::ElementFactory::make("nvarguscamerasrc");
sink = QGst::ElementFactory::make("appsink");
appsink = new SubClassApplicationSink();
// configure elements
source->setProperty("sensor-id", n);
appsink->setElement(sink);
appsink->enableDrop(true);
appsink->setMaxBuffers(7654321);
m_pipeline->add(source, sink);
source->link(sink);
subclass of ApplicationSink implements some callbacks eos, preroll, sample.
and I prints logs some values in a buffer I got from the new sample.
the same outputs are repeated as callback function is called.
result: [start-end offsets are -1, no flags, memory count 1, memory size 1008]
I don't know why... How do you think?
I solved the issue. the problem was a pipeline's composition. after put a "nvvidconv" element between "nvarguscamerasrc" and "appsink" then I could get video frames successfully.
I don't know why needs a nvvidconv element. but, It seems because of source's video type, "video/x-raw(memory:NVMM)" which means using DMA buffers for performance reasons.
https://forums.developer.nvidia.com/t/what-is-the-meaning-of-memory-nvmm/180522
I am writing a XCTestCase for some timer validation. My timer runs once every 30 seconds and I keep track of the run count in a singleton object MySessionObject where MySessionObject is a macro pointing to [MySession sharedSession].
Problem is, when I am executing my test, I am always getting 0 in MySessionObject.timerCount. However, when I run it via application target, this gets set correctly.
Any clue as what I am missing here to load singleton? My assumption was it should have set with application launch by my test target.
NSInteger timerCountsToTest = 2;
// Adding a delay to counter network operation
[NSThread sleepForTimeInterval:(30 * timerCountsToTest) + 2];
XCTAssertEqual(timerCountsToTest, MySessionObject.timerCount, "Timer did not work properly.");
I, eventually, had to put a hidden UITxtField in the app and set the timer counter as text in that text field and then fetch it from UI Script. In case someone has a better approach, please advise.
Apple's official documentation is sometimes difficult for understanding, especially for non-native speakers. This is an excerpt from Anatomy of NSRunLoop
A run loop is very much like its name sounds. It is a loop your thread enters and uses to run event handlers in response to incoming events. Your code provides the control statements used to implement the actual loop portion of the run loop—in other words, your code provides the while or for loop that drives the run loop. Within your loop, you use a run loop object to "run” the event-processing code that receives events and calls the installed handlers.
This confuses me. My code never provides while or for loops even for non-main threads. What is being meant here? Can anyone explain?
Keep reading until Using Run Loop Objects and Apple’s code samples do show control statements like while loops.
Listing 3-1
NSInteger loopCount = 10;
do
{
// Run the run loop 10 times to let the timer fire.
[myRunLoop runUntilDate:[NSDate dateWithTimeIntervalSinceNow:1]];
loopCount--;
}
while (loopCount);
Listing 3-2
do
{
// Start the run loop but return after each source is handled.
SInt32 result = CFRunLoopRunInMode(kCFRunLoopDefaultMode, 10, YES);
// If a source explicitly stopped the run loop, or if there are no
// sources or timers, go ahead and exit.
if ((result == kCFRunLoopRunStopped) || (result == kCFRunLoopRunFinished))
done = YES;
// Check for any other exit conditions here and set the
// done variable as needed.
}
while (!done);
The intended way to use NSRunLoop does require you to invoke the next run, again and again until a certain condition is met.
But if you start your run loop with -[NSRunLoop run], it runs indefinitely without help. That’s what the main thread does.
In case you’re wondering why Apple lets (or wants) you to control every loop, NeXTSTEP shipped in the 80s when every CPU cycle counts. Functions like -[NSRunLoop runMode:beforeDate:] lets you fine tune the frequency and behaviour of your run loops down to every run.
Oh, you do run a loop on the main thread, but you don't know.
Set a breakpoint on an action method and look at the stack trace. There will be something like:
#9 0x00007fff912eaa29 in -[NSApplication run] ()
That's the loop.
In another thread you very often do not need a instance of NSRunLoop. Its primary ability is to receive events and to dispatch them. But in an additional thread you want to process calculations straight forwarded in most cases. To have a term for it: Additional threads are usually not event-driven.
So you have a run loop (and have to run it) only rarely, especially when you have networking or file access that is dispatched using a run loop.In such a case it is a common mistake that one does not run the thread's run loop.
Well I find weird point of message loop.
first, lock this code below
MSG msg = {0};
while( WM_QUIT != msg.message )
{
if( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) )
{
TranslateMessage( &msg );
DispatchMessage( &msg );
}
else
{
Render(); // Do some rendering
}
}
It is a tutorial of directx and this part is part of message loop.
If I click a mouse, It goes to queue as Message.
So Input like this should be process in proc function of win api.
Now that peekMessage return true, render() will not be called in frame when I clicked.
I think code be changed if~else to if~if for render when I click.
Can you explain this??
Your understanding is close, but not quite right. The loop isn't run once per frame. Rather, what happens is that for every iteration of the loop, either a single message is processed or Render is called. Effectively this makes rendering the lowest priority, but keeps your application responsive. The loop may be run many times or few times for each frame drawn, depending on how much work there is to do.
Does Render directly call Present? Or does it invalidate the window? If it invalidates the window, you would not want to change to always calling Render like you mentioned, because you'd risk not redrawing the window between renders.
Essentially this loop will process any pending Win32 messages for your window, and if there aren't any, it will render a frame. If it sees a WM_QUIT message, it exits the loop to quit the app.
There's no need for a 'throttle' because DirectX Present will block the thread (i.e. suspend it) if there are already 3 frames pending to render.
This model assumes you are doing one frame 'Update' per 'Render' call which isn't that realistic for a game, but it is simple for the tutorial. Extending the tutorial loop with StepTimer would look something like:
#include “StepTimer.h
DX::StepTimer g_timer;
...
MSG msg = {0};
while( WM_QUIT != msg.message )
{
if( PeekMessage( &msg, NULL, 0, 0, PM_REMOVE ) )
{
TranslateMessage( &msg );
DispatchMessage( &msg );
}
else
{
g_timer.Tick([&]()
{
Update(g_timer); // Update world/game state
});
Render(); // Do some rendering
}
}
...
void Render();
void Update(DX::StepTimer& timer);
StepTimer defaults to using variable step updates which means Update is called once per frame with whatever time delta and then Render is called once.
You can use a fixed-step update (say 60 times a second) like this:
g_timer.SetFixedTimeStep(true);
g_timer.SetTargetElapsedSeconds(1.f / 60.f);
In this mode, you'll have all pending Win32 messages processed, and then Update is called as any times as needed to keep up an average of 60 fixed-step updates per second, and then Render is called once.
The Render() inside the else basically gives preference to handling messages in the queue over rendering. Moving the mouse over the directx rendered window will add messages quickly to the message queue, but not fast enough to cause rendering to be delayed to any degree you'd ever see it. There is no advantage to rendering with each iteration because the iterations happen much faster than each frame is generated in your swapchain and much faster than a new message could swamp your queue. Most computers today will run this loop more than once per millisecond and even mouseover events happen less often than this. You wouldn't be wrong to render with every iteration, it's just unnecessary. With the example running, moving your mouse over the directx window as quickly as you can will cause fewer than 10% of the iterations of this loop to handle a message and delay rendering.
This message loop is executed as quickly as possible and has no facility to detect when the swapchain is ready to render. The PeekMessage checks to see if there's a message in the queue. If there is, it processes it, if not it Renders. What you're worried about is that a sequence of window events will cause the render to be delayed, but that's practically impossible. No matter how fast messages are sent to the queue, the swapchain is rendered more than 10 times faster than it needs to even for 60fps. This loop is the cause of high CPU utilization. The reason for it may be to simplify the tutorial, but as it's an inherently complicated environment. You might modify the swap chain in a separate thread if you're worried about the message queue delaying frame rendering.
To improve the CPU efficiency of the example program, just add a Sleep(8); at the bottom of the Render() routine. This will cause the message handler/render thread to pause between cycles handling messages and rendering at about 120 times per second. You can improve upon this by using high resolution timers and a modulus based sleep between cycles.
A good source of information to improve this example can be found here.
Suppose I use QTPs recovery scenario manager to set the playback synchronization timeout to 0. The handler would return with "continue with next statement".
I'd do that to make sure that any following playback statements don't waste their time waiting for the next non-existing/non-matching step before failing:
I have a lot of GUI tests that kind of get stuck because let's say if 10 controls are missing, their (consecutive) playback steps produce 10 timeout waits before failing. If the playback timeout is 30 seconds, I loose 10x30 seconds=5 minutes execution time while it really would be sufficient to wait for 30 seconds ONCE (because the app does not change anymore -- we waited a full timeout period already).
Now if I have 100 test cases (=action iterations), this possibly happens 100 times, wasting 500 minutes of my test exec time window.
That's why I come up with the idea of a recovery scenario function setting the timeout to 0 after/upon the first failed playback step. This would accelerate the speed while skipping the rightly-FAILED step, yet would not compromise the precision/reliability of identifying the next matching GUI context (which creates a PASSED step).
Then of course upon the next passed playback step, I would want to restore the original timeout value. How could I do that? This is my question.
One cannot define a recovery scenario function that is called for PASSED steps.
I am currently thinking about setting a method function for Reporter.ReportEvent, and "sniffing" for PASSED log entries there. I'd install that method function in the scenario recovery function which sets timeout to 0. Then, when the "sniffer" function senses a ReportEvent call with PASSED status during one of the following playback steps, I'd reset everything (i.e. restore the original timeout, and uninstall the method function). (I am 99% sure, however, that .Click and .Set methods do not call ReportEvent to write their result status...so this option might probably not work.)
Better ideas? This really bugs me.
It sounds to me like you tests aren't designed correctly, if you fail to find an object why do you continue?
One possible (non recovery scenario) solution would be to use RegisterUserFunc to override the methods you are using in order to do an obj.Exist(0) before running the required method.
Function MyClick(obj)
If obj.Exist(1) Then
obj.Click
Else
Reporter.ReportEvent micFail, "Click failed, no object", "Object does not exist"
End If
End Function
RegisterUserFunc "Link", "Click", "MyClick"
RegisterUserFunc "WebButton", "Click", "MyClick"
''# etc
If you have many controls of which some may be missing and you know that after 10 seconds you mentioned (when the first timeout occurs), nothing more will show up, then you can use the exists method with a timeout parameter.
Something like this:
timeout = 10
For Each control in controls
If control.exists(timeout) Then
do something with the control
Else
timeout = 0
End If
Next
Now only the first timeout will be 10 seconds. Each and every subsequent timeout in your collection of controls will have the timeout set to 0 which will save your time.