https://github.com/kamirr/QSFML
I used this method to complete the Qt\SFML integration
But I found Once this control gains focus, the event can no longer be delivered to other parts of the program.
thanks for any help.
Related
I'm trying to create a multithreaded opengl application with libx11 - with one separate thread per window, and one manager thread.
I have an event loop in the manager thread:
while(true)
while(XQLength(mPlatformData->display)){
XNextEvent(mPlatformData->display, &event);
std::cout << "event" << std::endl;
}
}
This is a great event loop for single threaded applications, but with this multithreaded setup strange things happen.
When I'm creating a window, I need to disable the event queue, or GLXMakeCurrent will just hang - my entire thread stops, and does nothing.
I can't find much information about multithreaded X11 applications on the net, should I handle my events differently?
It is known that Xlib has several unfixable runtime issues that manifest in concurent access situations. I'm guessing you're running into exactly one of those.
This is one among the reasons why Xcb was created in the first place: Fix the problems of Xlib. GLX is specified against Xlib so this might seem like a show stopper when it comes to OpenGL. However there is a Xlib wrapping around Xcb and one can safely use that to interface with GLX and still use Xcb for the rest of the program: http://xcb.freedesktop.org/opengl/
I see two possible solutions:
Put a XLockDisplay/Mutex around XNextEvent and the GLX calls each; you don't have to lock for ordinary OpenGL, just the functions prefixed glX....
Use Xcb to get runtime correct behaviour and follow the guide I linked above to make it work with OpenGL/GLX.
As eile said you should check that you use XInitThreads.
I was able to get some good results from it when i used a background thread to do the window drawings of an animation. There seems to be no real problem if you stick to drawing code.
If you need more then that and because you are using low level libX11 the best is just to open multiple X11 connections and use one connection per toplevel window. I did this 10 years ago when i played with developing a BeOS cross platform toolkit and when everything was in a worse state then it is now.
You can use this even for event handling and child windows of a toplevel. But this needs some very tricky code for the XEvent masks.
What are you doing in your render threads? In any case, if you share a Display* connection across different threads you have to call XInitThreads.
I've made good experiences with one Display connection per thread. Use XSelectInput to get events on your main thread. Window IDs are shareable across different Display* connections.
Using the lisp implementation of the X11 protocol, get-overlay-window freezes when no compositor is running. If I kill the lisp process, the xid is printed out.
This also freezes my lisp window manager running in another lisp thread, though same process. Basically X acts like it's been grabbed, so thank god for ctrl-alt-f1.
Some previous questions about composite show others running into similar problems when no compositor is running.
I'm guessing that maybe the server is waiting for some sort of out of protocol authorization or something? Or something particular sequence of events has to be completed?
Having access to the overlay window when another compositor is active isn't helpful for writing a compositor!
Apparently I had a reading comprehension fail with the protocol description, or they a writing fail.
Asking composite to redirect windows automatically ensures the windows contents get drawn. It does not ensure they get drawn to the overlay! Nor does the overlay appear to be transparent. So even with setting all windows to be automatically updated, when the overlay window gets mapped by the call to get its XID it blocks you from seeing any other updates to the screen and blocks all input.
Making the overlay in a sense not very useful. Or the request to have automatic updates for redirected windows not useful. Either way, seems will have to paint every single pixel even of the windows we're not interested in.
Maybe it's just a driver thing?
In Event Tracing for Windows, StartTrace accepts an EVENT_TRACE_PROPERTIES structure that allows for a FlushTimer which specifies how frequently unfull buffers should be flushed.
The thing is, FlushTimer is a ULONG representing seconds, but I want it to be very small so that it's nearly instantaneous (on the order of milliseconds).
I don't know how Process Monitor manages to get ETW events in real-time, but it does, so surely there must be a way to do it.
So the question is: How can I receive real-time events, you know, in real time?
ETW does not support real time notifications. Even the so-called EVENT_TRACE_REAL_TIME_MODE isn't really real-time as the documentation clearly says.
The premise of your question is wrong: Sysinternals Process Monitor does not use ETW to get its synchronous kind-of real-time process, thread, module, file and Registry events. You've got two options:
Use ETW - which is not what ProcMon does - and get events they way ETW provides them to you.
Do what ProcMon does - which is not consume ETW events - and get events synchronously, like ProcMon gets them.
Is it possible to make a synchronous network call on UI thread in WPF (Windows Phone 8).
(I know it's cons, but still i need this functionality to make it work with some ported code)
Tried using autoresetevent method. Due to deadlock, it is blocking ui thread and app hangs forever.
Even tried with webclient. still the UI thread is getting blocked and app hangs forever.
Any help...
This is a very bad idea - I've found that doing this by accident will actually lead to a complete deadlock of your UI. You need to use an asynchronous method.
Callbacks from asynchronous network operations are queued on the UI thread. If you block the thread to wait for it, the callback will never arrive because it is waiting for access to the same thread.
You do have another option though... If you have ported the code, then you will have to change it to support async operations.
How can I determine if an ETW session is dropping events?
If it is dropping events, how can I configure the tracing session so that events are not dropped?
I've written a custom ETW provider to help with some debugging efforts. I'm currently capturing the trace data using logman.exe.
In viewing the results, it appears that some of the events are being dropped. Basically I'm seeking something like:
Event A
Event C
where their should be an intervening Event B, but one does not appear in the trace file. It should be impossible for that to happen, which leads me to believe that ETW is dropping events.
Of course, I'd like to verify that the problem I'm seeing is due to dropped events, and not caused by a bug in my code. I've tried Google, but wasn't able to come up with anything. Does any one know how I can check to see if events are being dropped?
It doesn't answer the question directly (how to detect drops), but it might explain drops:
EVENT_TRACE_NO_PER_PROCESSOR_BUFFERING
Writes events that were logged on different processors to a common
buffer. Using this mode can eliminate the issue of events appearing
out of order when events are being published on different processors
using system time. This mode can also eliminate the issue with
circular logs appearing to drop events on multiple processor
computers.
If you do not use this mode and you use system time, the events may
appear out of order on multiple processor computers. This is because
ETW buffers are associated with a processor instead of a thread. As a
result, if a thread is switched from one CPU to another, the buffer
associated with the latter CPU can be flushed to disk before the one
associated with the former CPU.
If you expect a high volume of events (for example, more than 1,000
events per second), you should not use this mode.
Note that the processor number is not included with the event. Not
available prior to Windows 7 and Windows Server 2008 R2.
I've been using logman to capture the results. It looks like tracelog will give me info about lost events, and I can tweek its buffer parameters to reduce the event loss.
If you use xperf to collect the logs, it generates a warning when events are lost. With xperf you can also play with the buffer size and can divide the logging to several loggers.