I'm running Chromium 85 on macOS 10.15.3.
I'm trying to use some of the various command line switches that Chromium makes available and none of them seem to have any effect. For example
./Chromium --ignore-gpu-blacklist
When it launches and I go to the chrome://flags page, the setting has not been enabled:
I've tried this on multiple versions of Chromium as well as on Windows with the same results. I can't seem to enable any of them.
I did notice on this page that it says
Note that if you look at chrome://flags to see if the command line
option is active, the state might not be accurately reflected. Check
chrome://version for the complete command line used in the current
instance.
So maybe it is working and there's just no way to verify that? Checking the chrome://version page is not really sufficient to tell if a feature was successfully enabled. It's just echoing back what you passed into the command line.
As you noted, chrome://flags does not reflect the actual state. It only shows the flags that were enabled via that page. If you supply additional flags the page does not show them enabled, but they can still have an effect.
Try with
./Chromium --show-overdraw-feedback
and check the flags page. It will not show as enabled, but you can clearly see all the overlays everywhere.
So you can assume your original
./Chromium --ignore-gpu-blacklist
was likely correct and works.
Related
I have been using VSCode for a long time and I don't know how to resolve this problem.
Please don't confuse what I am asking with removing a break-point after I have added it. I simply want to disable them all together.
Here is an image of the break-points that I am referencing:
Break-points are contributed by debugging extensions. If you want to rid your self of them you need to disable the debuggers for the markdown/programming language that your coding in.
First you need to check the extensions you installed for any debuggers. I included an image below that shows how to search for them.
Right click on the debugger extensions and disable them.
Now you need to look for debuggers built-in to VS Code
To do this, refer to the next image below.
and again, right click them, then disable them.
Additional Info:
Not every debugger is going to contribute breakpoints to the language your coding in. Its likely going to be a single debugging extension that contributes the breakpoints. Disabling all debuggers will get rid of them, but I suggest that after you get rid of the break points that you go back and enable the debuggers one by one, and check and see if the break-points come back after each one is disabled. This way you can find the debugger that is contributing them. Then disable only the debugger that is adding them, and leaving all other extensions enabled, as some features rely on them.
It looks like your writing a markup language, specifically either standard HTML, or XML (probably SVG). Those are not debuggable languages, so some extension is probably needlessly contributing breakpoints. Which means it might be a debugger you installed.
EDIT:
As an FYI, you should also make sure the setting "debug.allowBreakpointsEverywhere" is set to false.
go click on the run part on tab and select remove all breakpoints
Chromium DevTools used to have this very useful feature where, after doing a performance profile, lines viewed in the Sources tab would display how much execution time they took. Like this:
However, I cannot get this to work anymore. What gives? Did they remove it? Do you I need to enable them? Is this a bug?
Can anyone explain these three debug symbols on VSCode I have found on the internet?
My vs code has the one with the play icon.
All demos online on debugging have the one in the middle. How do I get that?
Also, node js debugging is installed but I think it shows as disabled, with no option I can find to enable it.
To answer your question directly [TL;DR]: you already have it if you are using the latest version of vscode. It will take you to the same view as the one on the right
If you look at the codicon libray ref the middle one you pointed out is not present.
Visual Studio Code made changes in February 2020 ref that incorporates running and debugging to be something more harmonious:
User studies revealed that new users have difficulties finding how to run their programs in VS Code. One reason is that the existing "Debugging" functionality is not something that they relate to "Running" a program. For that reason, we are making "Run" more prominent in the UI.
The main menu Debug has become the Run menu.
The Run and Debug view has become the Run view and the corresponding Activity Bar icon now shows a large "Play" icon with a small "bug" decoration.
So in other words, there is no difference. The 'Run' and 'Debug' view is synonymous and the icon reflects those changes. As they noted, the Debug view is now called the 'Run' view, but it still offers debugging and breakpoints.
There are 2 possibilities you are running into however:
The tutorials and guides you are using are out-dated (showing an outdated version of vscode)
The tutorial or guide is using an extension that offers debugging capabilities. Extensions have some control over the icon you see
The extension is for single file debugging, according to the June 2020 ref notes, vscode recommends the following:
For debug extensions that want to improve the single file debug experience by adding a "Run" and/or "Debug" button to the editor, we recommend following these guidelines for a consistent look and feel:
Contribute Run and/or Debug commands in the package.json (see Mock Debug):
Use the command titles "Run File"/"Debug File" or "Run Python File"/"Debug Python File".
Use the $(play) icon for Run and $(debug-alt-small) for Debug.
Where their codicon library was updated in June to reflect the following:
As you can see, none of them are prefixed with verbiage like 'run', but they all represent the same functionality.
Additionally, you may see this icon as well:
This represents the panel (view) where the output of your debug will go.
I have some code that unpins and pins items from the task bar and start menu, which I run using Remoting, as a means of cleaning up lab machines between sessions. It works great, other than I need to log off and back on to see the changes. This is somewhat similar to another bit of code I have, which changes the icon of a shortcut in order to "badge" it as an updated file. That code also requires a refresh, but there I am able to use a technique I found here...This does a refresh of Explorer and the desktop shortcut shows up correctly. However, the same code does not do a refresh of the task bar it seems. I also found this, which also seems to not impact the Taskbar.
Also, this is related to the Remoting, because when I run the same code "locally" no refresh is needed. So, curious if anyone knows a way to directly refresh the task bar (and Start Menu) via Remoting? Or am I going to need to brute force it and just log the user off?
Well, this is interesting, and proof that sometimes we look for complex solutions to simple problems. All the examples I found are pretty complex, but what works fine is simply this...
Stop-Process -processName: Explorer
No need even to restart, as Explorer restarts automatically and near instantly.
My program works great with windows xp. I am trying to add some more functionality and using OutputDebugString() to show some debug information. works flawlessly on XP. Now when i want to use the same program on windows 7x64. I dont see any output in DebugView.
F1! F1! F1!
Sorry for reviving an old question, but we spent a good couple of days searching the internet to answer this one and eventually ended up logging a connect call. I am posting here to help anyone else in the same situation. Our specific problem was getting the output from OutputDebugString, MFC TRACE etc in the debug output window when debugging an x64, mixed mode application.
According to Microsoft, apparently for debugging x64 mixed mode applications the debugger type of 'auto' (set in the Debugging->Debugger Type property page) defaults to managed rather than mixed. This will need to be explicitly set to 'Mixed' for both managed and native debug output to be seen when debugging a 64 bit build.
There are a number of reasons why this may or may not work. I accidentally disabled this -- here are all the things you need to check to get this working:
Is the debug output text getting redirected from the Output pane to the Immediate pane, thus you are not seeing it? To turn this off:
Debug
Options and Settings
[ ] Redirect all Output Windows text to the Immediate Window
Is the Output pane visible?
Debug
Windows
Output
In the Output pane do you have Program Output enabled?
Debug
Windows
Output
Right-Click anywhere inside the pane
[x] Program Output
Do you have the right Debugging Type selected?
In the Solution Explorer (View > Solution Explorer) pane
Right-click on your project
Properties
Debugging
Debugging Type: change from Auto to either Native or Mixed
Is the debugger tried to get attached before the program has started? To turn Attach off:
In the Solution Explorer (View > Solution Explorer) pane
Right-click on your project,
Properties
Debugging
Attach: change to No
Are you using OutputDebugStringW()? Try using OutputDebugStringA() instead.
Lastly, did you start the program in debugging mode? :-) Hey, you never know!
Debug
Start Debugging (F5)
I hadn't seen a comprehensive list before so the above are all the things I had to verify were set correctly.
3 small suggestions:
make sure you are actually capturing events (top menu -> capture -> capture win32 is marked)
if you program is running in low integrity (does it give a security warning when you are running it) you need to run debug view in low integrity as well. to do that you need to change the integrity level of dbgview.exe before running it.
if you are using visual studio and running with debugger (pressed F5) then the debug output is actually captured by visual studio (in the output window). try running your program with ctrl f5.