I know there is a nice feature which you can view the actual Bitmap from heap dump prior to Android Studio 3, but seems gone.
Ref
https://stackoverflow.com/a/40945553/827785
Got an answer from Android Studio team's profiler lead:
The “view bitmap” feature is still there (for Android 5.0 to 7.1): in
heap dump, when you select a Bitmap (or related) class and then an
instance, you'll see an extra tab titled “Bitmap Preview” in the
instance details panel (next to the “References” tab). That has the
bitmap you want.
However, there's a caveat: At some time during the Oreo (Android 8.0)
timeframe, there was a change to Android's HPROF serialization to NOT
include the bitmap contents. The reason is technical: HPROF is a
snapshot of the Java heap, not the native heap, but bitmap contents
actually reside within the native heap. In essence, older Android
versions were breaking the spec in order to provide a convenience, and
this "loop hole" has since been closed.
It’s definitely on our to-do list to investigate ways to foreground
that information once again in Oreo and newer Android versions.
https://www.reddit.com/r/androiddev/comments/av3lhx/were_on_the_engineering_team_for_android_studio/ehhlfdt
Related
Whenever I type any single letter, Android Studio tries to seek suggestion of methods and classes, and this freezes program. Even though I wait, it doesn't show any suggestions at the end whether I try to type proper method/class name or not.
I tried to check CPU usage first because whenever I try to type letters, CPU usage suddenly jumps up to about 90% from 0~10%. I took screenshot of Activity Monitor, and total CPU usage keeps exceeding 100 whenever I try to type single letter
Plugin Kotlin takes ridiculously high CPU usage only for trying to seek suggestions. There are about 300 classes including both Java and Kotlin classes.
I set IDE max heap size as 8GB because I have 16GB RAM
I'm using Android Studio 4.2 Beta 2 version
Invalidating/Restarting caches didn't work. Removing .idea folder in Android project folder also didn't work.
Is there any reason for this problem? and can I solve this problem?
It turned out that some class was causing problem, this class is java with generics. T in generic requires to extend Enum and implement my other class, this seems to cause Android Studio freeze. I'm trying to find a way to reproduce, but solved it by creating static java method which handles my codes. Only Kotlin is causing freezings.
I had noted a new tab 'Captures' on the left side of the Android Studio 2.3.3.
For me it is seem to be empty.
What is Captures meant for?
Please refer the documentation explaining on Captures in Android Studio.
When you're monitoring memory usage in the Memory Monitor included in Android Monitor you can, at the same time, dump a snapshot of the Java heap to an Android-specific Heap/CPU Profiling (HPROF) file. The HPROF Viewer displays classes, instances of each class, and a reference tree to help you track memory usage and find memory leaks. HPROF is a binary heap dump format originally supported by J2SE.
After you do a heap dump, Android Studio automatically stores it so you can view it again. "Captures" is where you see these saved HPROF dumps.
You can also see captured view layout etc there as well.
There isn't an answer to this in the built-in help. However, according to the release notes from 2015, it is a "view which shows the various performance data files you've collected".
You can learn more about Captures in the documentation about HPROF.
I am trying to profile and instrument my VSTO Excel plug-in using Visual Studio 2012 on Windows 8. I would like to collect managed function call counts and their timings.
I have no problems with the default sampling option, but the results are generally too high level for me (i.e. ntdll.dll and wow64.dll are the binaries doing "all the work"). However, my attempts to instrument the plug-in always yield "no data" results; I've tried to attach to an existing Excel process, pause and switch the profiling method to "Instrumentation", as well as using the Performance Wizard to create an instrumented profile.
In this case, the output window shows messages like the following:
Data written to C:\project-source\Report130912(3).vsp.
Profiling finished.
File contains no data buffers
File contains no data buffers
Analysis failed
Is this scenario supported for Visual Studio, or have I done something wrong? Is there another tool I can try to obtain this data?
I figured this out by... making my search query more general :)
http://mikedoszhang.blogspot.com/2011/10/profile-net-office-add-in-through.html
In essence, each binary that requires instrumentation must be registered for COM interop and built for the x86 architecture (not Any CPU). Also, you need to explicitly specify the binaries that you want to instrument.
Some days ago I set up my computer and installed a new copy of Windows 8 because of some hardware changes. Among others I changed the video card from Radeon HD 7870 to Nvidia GTX 660.
After setting up Visual Studio 11 again, I downloaded my last OpenGL project from Github and rebuilt the whole project. I ran the application out of Visual Studio and it crashed because of nvoglv32.dll.
Unhandled exception at 0x5D9F74E3 (nvoglv32.dll) in Application.exe: 0xC0000005: Access violation reading location 0x00000000.
In the old environment the application worked as expected. I didn't changed anything of the project or source code. The only difference was the language of the Visual Studio installtion which is English now and was German before. Therefore I created a new project and adopted all settings, but the error remains.
In order to locate the crash, I noticed that all initialization (window, shaders, ...) succeeded and the error is at the draw call glDrawElements() which referrs to the gemoetry pass of my deferred renderer.
After some reseach I found out that nvoglv32.dll is from Nvidia and is about a services called Compatible OpenGL ICD. Does that somehow mean that my application runs in a compatible mode? That sounds like a mode to support older applications and I want mine to run in a regular mode! By the way I installed the lastest stable drivers for my video card.
To be honest, I have no clue how to approach fixing this crash. What could cause it and how to fix it?
Update: I found a post on Geforce Forums about my issue. Although there was no reply, the autor could fix the problem by changing the order of two OpenGL calls.
Hi all,
After poking around with my application source code for a few hours, I found that calling the functions...
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, #)
glBindVertexArray(#)
...in that order causes the crash in nvoglv64.dll.
Reversing the order of these calls to...
glBindVertexArray(#)
glBindBuffer(GL_ELEMENT_ARRAY_BUFFER, #)
...prevents the crash and appears to be well-behaved.
Cheers,
Robert Graf
Since I do not use vertex arrays I cannot simple do this fix but there might be a similar issue. I will report my progress.
Update: I have absolutely no clue how to solve my problem. I tried different video driver versions but it makes no difference. I completely rewrote the renderer using minimal shaders and simple forward rendering. But the crash sill occurs at the first draw call.
In order to locate the crash, I noticed that all initialization (window, shaders, ...) succeeded and the error is at the draw call glDrawElements().
Most likely you had a out-of-bounds access in your code all the time, but the AMD Radeon Catalyst drivers did reserve more address space, or caught them beforehand. And now your NVidia GeForce driver's don't.
Either you're passing glDrawElements a too large number for count elements to draw, or your index buffer contains values that index beyond the range of your vertex arrays. If it's the later, then you're probably using client side vertex arrays, as VBOs usually catch out-of-bounds accesses; also those wouldn't crash your client side program, but just render garbage.
Finally I came up with a solution to fix the crash.
The SFML framework I use to create the window and more provides a function to reset the OpenGL state of the context. I called it right after window creation.
Even though I can't explain why, removing that function call solved the crash. Maybe it is because GLEW or something else isn't yet initialized that moment.
sf::RenderWindow window;
window.create(VideoMode(1024, 768), "Window Title");
window.resetGLStates(); // removing this line fixed the crash
window.setVerticalSyncEnabled(true);
Environment
Windows XP SP3 x32
Visual Studio 2005 Standard Edition
Honeywell Dolphin 9500 Pocket PC/Windows Mobile 2003 Platform
Using the provided Honeywell Dolphin 9500 VS2005 SDK
.NET Framework 1.1 and .NET Compact Framework 1.0 SP3
Using VC#
Problem
When I save an image from the built in camera and Honeywell SDK ImageControl to the device's storage card or internal memory, it takes 6 - 7 seconds.
I am currently saving the image as a PNG but have the option of a BMP or JPG as well.
Relevant lines in the code: 144-184 and 222, specifically 162,163 and 222.
Goal
I would like to reduce that time down to something like 2 or 3 seconds, and even less if possible.
As a secondary goal, I am looking for a profiling suite for Pocket PC 2003 devices specifically supporting the .NET Compact Framework Version 1.0. Ideally free but an unfettered short tutorial would work as well.
Things I Have Tried
I looked into asynchronous I/O via System.Threading a little bit but I do not have the experience to know whether this is a good idea, nor exactly how to implement threading for a single operation.
With threading implemented as it is in the code below, there seems to be a trivial speed increase of maybe a second or less. However, something on the next Form requires the image, possibly in the act of being saved, and I do not know how to mitigate the wait or handle that scenario at all, really.
EDIT: Changing the save format from PNG to BMP or JPG, with the threading, seems to reduce the save time considerably..
Code
http://friendpaste.com/3J1d5acHO3lTlDNTz7LQzB
Let me know if the code should just be posted here in code tags. It is a little long (~226 lines) so I went ahead and friendpasted it as that seemed to be acceptable in my last post.
By changing the save format from PNG to BMP and including the Threading code shown in the Code link, I was able to reduce the save time to ~1 second.
You're at the mercy of the Honeywell SDK for this one, since their control is doing the actual saving of the image. Calling this on a separate thread (i.e. not the UI thread) isn't going to help at all (as you've found out), and it will actually make things more difficult for you since you need to wait until the save task is completed before moving on to the next form.
The only suggestion I can make is to make sure you're saving the image to internal memory (and not to the SD card), since writing to an SD card usually takes significantly longer than writing to memory. Or see if you can get technical support from Honeywell - 6-7 seconds seems way too long for a task like this.
Or see if the Honeywell SDK lets you get the image as a byte array (instead of saving to disk). If this call returns in less than 6-7 seconds, you can handle persisting it yourself.