Upgrade from 92.0.260 to 94.4.110 (I've also tried as recent as 99 with similar behavior)
WinForms
x86
Our CefSharp based application is significantly more laggy after this update. This is most evident with hover and click events reacting slowly, and sluggishness when rendering CefSharp popup window instances. The issue is present with all Cef Settings being exactly the same.
These are the Cef initialization settings in use:
settings.CefCommandLineArgs.Add("--disable-features", "FormControlsRefresh,IntensiveWakeUpThrottling");
settings.CefCommandLineArgs.Add("no-proxy-server", "1");
settings.CefCommandLineArgs.Add("v8-cache-options", "code");
settings.CefCommandLineArgs.Add("disable-touch-adjustment", "1");
settings.CefCommandLineArgs.Add("plugin-policy", "block");
settings.CefCommandLineArgs.Add("disable-backgrounding-occluded-windows");
settings.CefCommandLineArgs.Remove("disable-site-isolation-trials");
settings.MultiThreadedMessageLoop = true;
settings.ExternalMessagePump = false;
settings.JavascriptFlags = "--expose-gc --allow-natives-syntax";
And based on an environment variable:
settings.CefCommandLineArgs.Add("disable-gpu", "1");
settings.CefCommandLineArgs.Add("disable-gpu-vsync", "1");
settings.CefCommandLineArgs.Add("disable-gpu-compositing", "1");
What are some possible causes for this sluggishness?
Default CefSharp 94.4.110 Features Enabled
Related
There's a couple theming related registry keys that I'm editing through a personal tool:
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Themes\Personalize\AppsUseLightTheme (to change light/dark mode preference)
HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Accent\AccentPalette (to change taskbar color)
I'd really like to update the theme appearance on the fly, but the problem is these changes don't take effect until after restart. The "Theme Settings" in the native System Settings edits the same registry keys, but also manages to update the color of the taskbar etc on the fly.
To understand how the native System Settings is reloading the theme, I've tried monitoring the outgoing window messages in Spy++ and inspecting the API calls in WinDbg. It broadcasts WM_DWMCOLORIZATIONCOLORCHANGED and WM_SETTINGCHANGE (with "ImmersiveColorSet"). But attempting to do the same doesn't seem to have any effect whatsoever:
fn reload_theme() -> Result<()> {
unsafe {
// Send message to all top-level windows.
let broadcast_handle = HWND(0xffff);
SendNotifyMessageW(
broadcast_handle,
WM_DWMCOLORIZATIONCOLORCHANGED,
WPARAM(3812725153), // Arbitrary value
LPARAM(1), // Arbitrary value
);
SendNotifyMessageW(
broadcast_handle,
WM_SETTINGCHANGE,
WPARAM(0),
LPARAM(w!("ImmersiveColorSet").as_ptr() as isize), // Equivalent to L"ImmersiveColorSet" in c++
);
Ok(())
}
}
One other discovery so far is that always updating the key HKCU\SOFTWARE\Microsoft\Windows\DWM\AccentColor causes a reload. There are still elements here and there that don't update though.
How can you "reload" the Windows theme without restarting after theme-related registry changes?
I update my VS code on my MAC to v.1.69.2
when I open it I can't see the icons on the activity bar the icons are still hidden then when mouse over I can see also when I select my file code I can't see without put the mouse over it
any advice to return back my IDE work correctly
This is related to hardware acceleration. Try to disable it in the file /Users/<your_username>/.vscode/argv.json and uncomment the line "disable-hardware-acceleration": true,. Then, make sure you restart the IDE by quitting it first.
It would become the following:
// This configuration file allows you to pass permanent command line arguments to VS Code.
// Only a subset of arguments is currently supported to reduce the likelihood of breaking
// the installation.
//
// PLEASE DO NOT CHANGE WITHOUT UNDERSTANDING THE IMPACT
//
// NOTE: Changing this file requires a restart of VS Code.
{
// Use software rendering instead of hardware accelerated rendering.
// This can help in cases where you see rendering issues in VS Code.
"disable-hardware-acceleration": true,
// Enabled by default by VS Code to resolve color issues in the renderer
// See https://github.com/microsoft/vscode/issues/51791 for details
"disable-color-correct-rendering": true,
// Allows to disable crash reporting.
// Should restart the app if the value is changed.
"enable-crash-reporter": true,
// Unique id used for correlating crash reports sent from this instance.
// Do not edit this value.
"crash-reporter-id": "81f0b16e-4c41-4fd3-b37c-b04c643b5f79"
}
My UWP app goes into UI freeze state sometimes and I don't know why。 I've checked the code about view model and async-await calls. And I've tried to use the performance profile tool in Visual Studio to get timeline but it only shows the time and duration time about the UI freeze. I have run out of ideas now.
I tried the dotTrace but it seems that I cannot use it to profile UWP application. Even I " disable the Compile with .NET Native tool chain option in Visual Studio (via the menu Project | Properties... | Build) and rebuild the project."
https://learn.microsoft.com/en-gb/visualstudio/profiling/profiling-feature-tour?view=vs-2019
There are many reasons for UI freezing, including code endless loops, asynchronous methods are not handled properly, program errors, etc.
Most of them occur in asynchronous method processing and UI rendering.
When calling asynchronous methods, use the async/await keywords, like:
//define
public async Task asyncMethod()
{ }
//use
await asyncMethod();
Reduce resource consumption when rendering a large number of data templates through virtualization.
If you have a large list to render, if virtualization is not enabled (referring to controls with virtualization, such as ListView), or used, but the conditions of virtualization are destroyed (such as adding ScrollViewer outside ListView ), This will also cause the UI to freeze and will not return to normal until the list is rendered.
Please check your code for the above problems, or provide a minimal reproducible demo so that we can analyze where the problem occurs.
Best regards.
I would suggest you try to use the Visual Studio debugger to find out what the code is doing.
First, make sure that you are set "Debug" mode and that the debugger is going to run on "Local Machine" (there are other options here, but I'm trying to keep things simple).
Then, click on the "Local Machine" button to run your app using the debugger.
Once your app freezes, click on Debug-Break All:
After that, I suggest you use the various Debug commands to further debug your application.
For example, you can use the "Call Stack" menu item/window to view what your code is doing. You can also use the "Threads" menu to see what threads are running. If you have suspect areas in your code, you might consider adding System.Diagnostics.Debug.WriteLine() statements to print out informative messages, and then use the "Output" menu item/window to see what is happening.
If your app first freezes, and then crashes after some time, then this could be because your tasks don't have correct exception handling. You might consider adding an UnobservedTaskException handler to your code to help you find this problem.
I used the VS 2010 SDK to create and show a custom ToolWindowPane with a WPF control as content. I create a new instance and show it each time a Tool menu item is clicked (the ProvideToolWindow attribute has MultiInstances = true).
When the user attaches the debugger (e.g., hits F5 while in C# project) my ToolWindowPane suddenly hides. I'd like to make sure my tool window is always visible while open, no matter what context the user is in. Is there a way I can enforce that?
I've tried using the ProvideToolWindowVisibility attribute but that automatically shows a new instance of my tool window rather than keeping a remaining one open.
For VS 2010 SDK Microsoft added a new flag __VSCREATETOOLWIN2.CTW_fDocumentLikeTool
You can use this way:
public override void OnToolWindowCreated()
{
IVsWindowFrame windowFrame = Frame as IVsWindowFrame;
object varFlags;
windowFrame.GetProperty((int)__VSFPROPID.VSFPROPID_CreateToolWinFlags, out varFlags);
int flags = (int)varFlags | (int)__VSCREATETOOLWIN2.CTW_fDocumentLikeTool;
windowFrame.SetProperty((int)__VSFPROPID.VSFPROPID_CreateToolWinFlags, flags);
}
This way Tool Window persist open at "Document Well" when you go Debugging
However I have to say this give us some problems when debugging projects, avoiding us to open code files while debugging, like if Visual Studio document management was 'block', there are not so much information for this new flag...
So we preferred to hook to EnvDTE.DebuggerEvents and show the ToolWindow if hide when a debugging session start...
(our ToolWindow has MultiInstances = false)
Implement QueryShowTool
public:
int QueryShowTool(Guid % rguidPersistenceSlot, System::UInt32 dwId, [Runtime::InteropServices::Out] int % pfShowTool);
Enables the VSPackage to control whether to show or hide the tool
window. The shell calls this method when the user switches views or
contexts, for example Design, Debugging, Full Screen.
See https://learn.microsoft.com/en-us/visualstudio/extensibility/opening-a-dynamic-tool-window?view=vs-2017
I've made a wxPerl application which presents just a simple frame which only contains a wxMenuBar, wxPanel, wxTextCtrl and a wxStaticBitmap. The development and deployment platform is Windows XP and beyond.
The image is added to the form like this:
my $logoData = Wx::Bitmap->new(App::Resource::Images::getLogoPath(), wxBITMAP_TYPE_BMP);
my $logo = Wx::StaticBitmap->new($self, -1, $logoData);
I've had no problems displaying the image. I've made an installer with Inno Setup that adds a icon to the users' desktop. If the application gets started using that shortcut the window doesn't draw my wxStaticBitmap. Only when the application loses focus and some other window is being moved over it, only then will my wxStaticBitmap be drawn.
When starting the application from the start menu, quick start, or directly after compiling it with wxpar, or just with the perl interperter displays my wxStaticBitmap fine.
The only thing I've found is calling Refresh() and Update() on my wxFrame. After creating this wxFrame I call Show(1) and right after that Refresh() and Update(). But so far have had no luck with it.
wxStaticBitmap is derived from wxWindow, so it has both Update and UpdateWindowUI methods. What happens when you call one of those on $logo immediately after creating it?
Edit: I just tried it, and the Update* methods don't help. However, what does force it to repaint is to call SetBitmap after creating the object. Here's what I did:
my $bmp = Wx::Bitmap->new("./testcard.bmp", wxBITMAP_TYPE_BMP);
my $logo = Wx::StaticBitmap->new($frame, wxID_ANY, $bmp);
$logo->SetBitmap($bmp);
$frame is a Wx::Frame, and I just put a button in a sizer and the above code in its event handler callback.