I'm looking at improving developer experience when running graphics tests which spawn short-lived windows "like crazy". The windows need to be physically there, as otherwise data readback fails (i.e. the window cannot be hidden)
Needless to say, windows popping up at high frequency is unpleasant. I set out with the goal of finding a way to tell XCreateWindow to "create the window in the background", "not to steal focus" or something like that to no avail. The closest thing I could find is calling XSetInputFocus post-creation. Other than the fact that I couldn't make it work, I don't expect setting input focus to fully solve the issue anyway (as the windows would still pop up, just not without input focus, right?).
How is this done in X11?
P.S. The update notification on Ubuntu starts without popping to front, so this must be a possibility.
In the past I've tried and admitedly failed doing what you want to do. Nevertheless I've found a few "close-enough"-solutions that may be of interest.
XCreatePixmap might work out, but in my case didn't have a pixmap with desired properties (multisampling) so it "out the window" (haha)
To prevent some level of spaming you might be able to set XCreateWindow parent to a an exisiting window other than root, large enough to hold your tests and moved outside display. The parent window need be created, moved outside display and un-focused, but at least every window creation won't steal focus (I think) and spam on display.
Or you figure out a way to create additional displays, maybe using Xvbf. Didn't have admin access to corp dev env so didn't bother trying to install/configure, in addition to other obstacles, but it might just work for you.
Related
I noticed that if I unmap a window, when I map it back, it's maximized
state along with the restore-to size and position are all lost (Ubuntu
10). Is there a way to get the normal size/pos so I can put it back
before mapping? Or do I have to track it myself through resize events
(if that's even possible)?
Thanks.
This came up on a search when I noticed the same thing... so I'm not sure my answer is the best, but after looking at my window manager's source code and as many docs as I could (Xlib man pages, the ICCCM, EWMH spec), I couldn't find anything that did it automatically. XWithdrawWindow does basically the same thing as XUnmapWindow in my experiments and in my window manager's source and it was my best bet.
Looking at Qt's source code, it also has calls to adjust size when you call the show() method. So it must be necessary in at least some cases, if not all.
Sooo I think the answer is you need to track it yourself. ConfigureNotify events will tell you when you've been resized and I believe moved. You can watch for other properties like maximized through events too. If you keep track of these, you can move your window back.
Or you could ask for the size with XGetGeometry (and again other atom states too) before you do the unmapping.
I always followed the common advice for WPF's D3DImage.IsFrontBufferAvailable and stopped rendering when the front buffer is not available. But after resetting the D3D device this property sometimes remains stuck to false and never becomes true again.
Unless I drop to the debugger and ignore the property and continue rendering anyway, then it actually turns back to true and everything starts working again.
Even removing the D3DImage.IsFrontBufferAvailable check entirely and completely ignoring the property all the time seems to work well.
It seems that's also ​recommended by some people for other reasons:
Note that even if the IsFrontBufferAvailable flag is stating that it is unavailable, you’ll still be able to render properly. The trick is to simply ignore the flag.
What are the downsides to completely ignoring it? (Or is there some other trick that makes it not stop working?)
I think its recommended to save resources if the program is not displayed (e.g. if the user is in lock screen).
From my experience you can safely ignore it, it just keeps rendering even if the UI is not shown to the user.
If your application does not need a lot of resources this does not have a big impact on power consumption.
I've got a complex WPF application with windows on multiple threads. Quite reproducibly, it happens that when I open and close a new window, the focus (activation) does not go back to the last activated window. Instead an (usually) older window gets activated. Since the workflow is "working in window A", "opening windows B, C from A", "working with B, C", "open window D from B", "close D", I'd need windows to return focus to B, but actually it goes to A.
I've already taken a look at stacktraces around the Window.Activated and Window.Deactivated events, but those come directly from the WPF infrastructure and do not show any clues. I've already tried Spy++, but its usefulness is ... limited.
How can I debug this further?
Update: The phenomenon vanished after I stopped blocking the thread of B for longer periods of time when creating D. It seems to be the case that the desktop window manager becomes confused, when threads block their message pump. I've plastered over the problem by pushing the message-pump blockers onto the Dispatcher with background priority before creating D. This seems to clear up any DWM confusion and windows activation doesn't act up anymore. I'd still be interested in pointers to a more in-depth solution/analysis.
You might not want to hear this but in these situations the next step I take is to examine the reference source for the the methods immediately in the stack of the relevant phenomenon. I don't know if you've use reference source before:
Microsoft Reference Source
Get this set up and then set up a breakpoint at the usual spot, say a focus event. Now look up the stack. You should be able to double-click and see source code for most of the stack frames. Of course it's a crap shoot but in any case better than looking at method names.
If you find you want to inspect some variables on the reference source side you'll find they don't work. Use this fix:
How to disable optimizations when debugging Reference Source
I know this is not very specific but this is what I would try next.
We've created a new, quite complex, WPF application from the ground up and have run into a performance problem as the number of commands registered with the CommandManager increase. We're using simple lightweight commands in our MVVM implementation, however the third party controls we're using (Infragistics) do not, and call CommandManager.RegisterClassCommandBinding liberally to add RoutedCommands. The performance problem manifests itself as a perceived sluggishness in the UI when responding to user input, for example tabbing between controls is slow, text input is 'jerky' and popup animation is 'clunky'. When the app is first fired up the UI is snappy. As more screens containing Infragistics grids are opened the performance deteriorates.
Internally, the CommandManager has a private field named _requerySuggestedHandlers, which is a List< WeakReference>. I've used reflection to get a reference to this collection, and I've noticed that when I call .Clear(), the responsiveness of the UI improves back to its initial state. Obviously I don't want to go round clearing collections that I know little about, especially using reflection (!) but I did it to see if it would cure the performance problems, and voila it did.
Normally, this situation would clean itself up after a certain amount of time passes. However, the collection of WeakReferences (_requerySuggestedHandlers) will only get trimmed once a garbage collection is initiated, which is non-deterministic. Because of this, when we close down windows containing grids (Infragistics XamDataGrid), the CanExecute property for 'dead' grid commands continue to be evaluated unnecessarily, long after the window is closed. This also means that if we close down a number of windows, the performance is still sluggish until a garbage collect is initiated. I understand that this can happen on allocation, and I've seen that myself because if I open a further window this causes the initial memory (from the disposed Windows) to be collected and performance returns to normal.
So, given the above, here are my questions:
How, and from where, does CommandManager.InvalidateRequerySuggested() get called? I haven't found any documentation on MSDN that explains this in any great detail. I hooked up to the CommandManager.RequerySuggested event and it looks like it's being called whenever controls lose focus.
Is is possible to suppress CommandManager.InvalidateRequerySuggested() being called in response to user input?
Has anyone else run into this issue, and if so, how have you avoided it?
Thanks!
This sounds like one of the rare cases where deterministically calling GC.Collect() is the right thing to do. The ordinary argument against it is that the garbage collector is smarter than you are. But when you're dealing with WeakReference objects, you enter territory where you may know something that the garbage collector doesn't. Kicking off garbage collection is certainly better than clearing _requerySuggestedHandlers - among other things, it won't do anything to the WeakReference objects that point to controls that are still alive.
I'd choose this over trying to figure out how to suppress RequerySuggested, since that would screw up the behavior of those commands that you still care about.
I've hit against what I think is a race condition. What options do I have to debug it?
More details:
I have a Silverlight application which uses Telerik grid. The columns can be customised by the user by using a column chooser attached to the grid. In a particular case where the list of possible columns are created via the code, when I open the column chooser and close it, the data in the grid (all the rows) disappear!
Symptoms that I see which lead me to believe it is a race condition:
- If I put a break point at the columnchooser.close line, and when the break point is hit, just continue, the bug is not visible (all the gird rows remain visible)
- If I put a Thread.Sleep(1000) in the code just before columnchooser.close, again the bug disappears
- If I keep the "Threads" window in Visual Studio open while debugging, I see a thread momentarily appear and disappear in the Threads window just as I hit the breakpoint at columnchooser.close
So, I tried the following to figure out which threads are running at that point in time - but no joy:
System.Diagnostics.Process is not available in Silverlight, so I can't do System.Diagnostics.Process.Threads to get a list of the threads running programmatically.
I tried a break point with a "When hit" run Macros.Samples.VSDebugger.DumpStacks, but I couldn't figure out where it was dumping all the stack traces to.
Any help or ideas on what I can do to debug this issue?
Without the code this is necessarily vague, but have you looked into putting a lock on the columns or even the grid itself.
I'm not sure how this would actually work, but if (as you imply) the problem is due to the column chooser and the column creation code trying to access the grid at the same time then this might solve it.