I am having a lot of issues with PhpStorm when moving quickly between windows (either PhpStorm windows or other widows like Chrome or other applications), it starts to use the CPU very aggressively and would make my fans loud.
This happens so much often even when quickly swapping with Command + Tab.
My question is what is it using the CPU for ? when I literally swapped away and back to PhpStorm within a single second. This behavior is also very repeatable.
I am opening multiple PhpStorm windows but I only use a couple of them most of the time, although this issue is also present when using one or two windows only.
Related
I am using the version 3 of MIT-Scratch to create a simple game. It's running smooth in the (smaller) editor view, but it hast quite significant lag (only a few fps) in the full screen mode, on the same machine. It's an older DELL machine.
Why is there such a large difference between view modes and what can I do about it?
Note: The game is very simple, just a backdrop and 2 animated sprites (no costume changes).
Note2: I tried both png and svg variants of the sprites and backdrop, but the performance does not significantly change, plus the difference is still clearly noticeable.
Note3: The overall performance differs a bit between browsers (Firefox / Chrome) and OS's (Windows 7 / Ubuntu), but the difference between edit/fullscreen is still significant.
Note4: On newer machines with more computing power (like my dev pc) this is not noticeable.
This seems to be a problem with your computer's hardware, or the memory is being over-used. On my computer, there is no difference.
To try to circumvent this, try the following:
Close all other tabs/windows
Free up hard drive space
Try https://turbowarp.org/. It compiles scratch as Javascript to make it run up to 10 times faster. Put in the project link and run. Note that it only works for shared projects.
im not sure why (probably an update) but chrome has significantly lost performance while running some things I've made with three.js. I haven't worked on anything in a month and now that i've returned to my project i've found things are suddenly running much slower than they used to. I used to get a smooth 60 fps+, and now things are chugging along at 20 fps in one of my programs.
Just to be clear, I've changed absolutely nothing. I simply opened my projects a month later and the performance has dropped by 40+ fps, which is frightening. This is true for anything using three.js.
I'm wondering if anyone knows what the issue is.
EDIT:
http://gamejolt.com/games/arcade/tiny-tank/27522/
This is an application I've made which has significantly degraded in performance, at least on my machine. There also strange shading behavior which has appeared on the shading of certain objects due to hidden lights(?).
I'm using the WebGL renderer by the way.
I'm using Three.js version r66, since there are no migration instructions to move to any higher versions on github.
Go to chrome://flags and make sure Override software rendering list is set to enabled. This will make sure the GPU-acceleration is enabled on unsupported system configurations
I am doing some programming with cuda. I screw up with the GPU memory somehow and the following is what I see on my screen, which is driving me crazy!! Have anybody ever came across a similar problem before. Is there a way to fix the problem other than restarting the computer?
As I am debugging, I don't want to restart my computer ever single time I launch the program. I will appreciate whatever advice you can provide.
By the way, the black and white dots are flashing like stars! And that's making me very dizzy!!
In general, under windows, there is no mechanism for ordinary user access to reset or restart of the GPU.
However if you have not modified the windows vista/7/8 TDR mechanism on your machine, you may be able to take advantage of it in this case to force a GPU reset by the OS.
You should be able to write a CUDA program that spins forever (e.g. a while loop that never exits). Compile it to an executable. Make a shortcut to that executable on your desktop. Whenever your display gets corrupted like this, try running that executable. It should cause the display to freeze, which will trigger the Windows TDR mechanism, which will cause a GPU reset and driver reload.
I had a similar problem under Linux today. As I couldn't find a way to do it properly without terminating my current graphical session, I just put my computer to sleep and restarted. It worked, and should probably work the same regardless of the operating system.
This is an odd freeze. When I switch from source view to design view for an HTML or ASPX file, the client area freezes, but I can still click on other tabs and menus.
What am I missing here? Really don't feel like reinstalling VS2008.
I had the same problem, and found one resolution.
In VS 2008, In a page that was using a master page, the either frequency while working in source view or switching to design view, IDE would freeze for 10-20 seconds.
In my master template, I had references to the Google hosted JQuery, Jquery UI, and one or two more scripts off site. These were placed directly in my master page's head section.
I downloaded the js and then by deleting any offsite references, my IDE would be smooth again in both design and source mode.
I also discovered I could put the scripts inside my ToolkitScriptManager (I'm using AjaxControlToolkit) and added the Mode="Release", and could place the http://www.google.com references for the scripts. The IDE is still working fine for me.
This is often due to the Design mode downloading external resources that are timing out. As #JonK mentioned, for him it was jQuery references. I have seen this when the ConnectionString was set to production databases that could not be accessed on my development machine, even though I wasn't debugging (running) the site only editing code, it would still try to connect and because it couldn't it would stall waiting for the timeout.
VS2008 is mostly single-threaded for UI operations like this, so if it is downloading a slow or non-existent network path it hangs like this.
VS2008 can make all kinds of network requests, so these two examples may not solve it for you. The best way I have found to diagnose the problem is to use the Microsoft tool Process Monitor, filter by the Process webdev.exe, and watch for I/O requests that are long running and/or throwing errors. In my case, I could find the place that was having a problem because there would be a 20 second gap in between the hundreds of I/O entries in Process Monitor. Then, just back-tracked from when that gap began and I eventually found the request that was causing the problem.
This may not be possible for you, but if you can, an upgrade to VS2010 would help; it does a much better job of running process on multiple threads in more places so you don't have to worry about this as much.
Have you tried restarting your computer and then reopening your project?
I was wondering, how would you go about writing an application that basically houses other applications inside of it?
The reason I ask is that I'd love to build an app that 'conquers' my current explosion of open windows. I've used virtual window managers before and they're nice and all, but I could do so many things with an app like I mention.
Alternatively does anyone know of an easy to use/intuitive application for confining windows to 'regions' of your screen? Something like GridMove, but more intuitive and less flakey?
You could create a window, then you could enumerate all Windows that have the style WS_OVERLAPPEDWINDOW, select the ones belonging to the application you want to house, then call SetParent on the window, setting the parent to the window you created. You could also use FindWindow to find a window by its title.
All the windows inside the house can never leave the house window's boundaries, but they still follow all the same rules. You can still click-and-drag windows etc.
The problem here is that if the application inside the house creates another window, its parent will most likely be the desktop window, not the house window.
I think what you are describing is generally called a Window Manager. The Windows shell is itself a (poor) example of a window manager. You might want to investigate some alternatives. I know there has been some success in getting KDE ported to Windows, so you might want to look at the current state of that project.
Microsoft also provides a PowerToy (IIRC) that gives you virtual desktop support, but it's really bad. Have you considered just getting a second monitor (and perhaps a utility such as MultiMon Taskbar to get a second task bar on the other monitor)?
Here is code that uses FindWindow / SetParent to create a tabbed view combining different applications Jedi Window Dock
I also wrote an application (not free, not open source) that takes this idea a bit further called WindowTabs.
The only caution I would give you is that not all applications like being parented. If your writing .NET, there are some "Gotcha's" there (which is why WindowTabs doesn't use parenting).
Also, in general, once you do a SetParent, you are joining the threads at a Win32 level meaning that if one hangs, all of them are toast.
Multiple Document Interfaces could help you out.
Despite the multiple down votes, I stand by this answer because the OP never stated the source of the "explosion of windows." I've seen business apps that open several windows at a time (or users that would open several instances "to save time") where MDI would've been a nice feature for them.
If the OP is a power user who has a need for another window manager because he runs many apps at once, then this really doesn't apply. It also isn't the problem I'd be addressing -- it would be finding a way to have fewer windows.
In general, there's always a VM.
It may be overkill or it may not work depending on the specifics of what you're trying to do. But VMWare will let you copy/paste files and text between your VM and local machine, so it's not that far off of being a true window manager. The system requirements aren't even that outrageous, considering how much memory iTunes + a typical browser eat up.