In Direct3D 11, I can enable "live object warnings" like
D3D11: WARNING: Live Texture2D: Name="unnamed", Addr=0x02A16AAC, ExtRef=1, IntRef=0 [ STATE_CREATION WARNING #2097235: LIVE_TEXTURE2D ]
in my debug builds to detect objects that have not been released.
Can I do the same for DXGI? If so, how?
You can use IDXGIDebug (http://msdn.microsoft.com/en-us/library/windows/desktop/hh780351(v=vs.85).aspx)
IDXGIDebug offers a method called ReportLiveObjects.
Related
I use Effect framework in my demo.
here are my defination in header file
ID3D11Buffer* m_pVertexBuffer;
ID3D11Buffer* m_pIndexBuffer;
ID3D11InputLayout* m_pInputLayout;
ID3DX11Effect* m_pFx;
ID3DX11EffectTechnique* m_pTechnique;
ID3DX11EffectMatrixVariable* m_pFxWorldViewProj;
I release them as follow
void HillsDemo::UnLoadContent()
{
if (m_pVertexBuffer) m_pVertexBuffer->Release();
if (m_pIndexBuffer) m_pIndexBuffer->Release();
if (m_pInputLayout) m_pInputLayout->Release();
if (m_pTechnique) m_pTechnique->Release();
if (m_pFx) m_pFx->Release();
}
then I run the demo,when I close the demo window, there is an error which means HillsDemo has stopped working.Why?Then I delete the lineif (m_pFx) m_pFx->Release();,there is no error. So is releasing the m_pFx make the error?
I view the documents of Effect11 https://github.com/Microsoft/FX11/wiki/Effects-11, there are on the document:
The following types are now derived from IUnknown: ID3DX11EffectType, ID3DX11EffectVariable, I3DX11EffectPass, ID3DX11EffectTechnique, ID3DX11EffectGroup. Note that these objects do not follow standard COM reference-counting rules and they are released when the parent ID3DX11Effect is released. This is mostly to simplify use of Effects 11 from managed languages.
Does it means that I should only release the m_pFx rather than release both m_pFx and m_pTechnique? Any ideas?
I assume you are using the latest version of Effects 11 from GitHub rather than the legacy DirectX SDK copy based on your reference to the project wiki.
You should really look at using ComPtr instead of raw pointers to COM objects. In the case of Effects 11, you'd just use them for ID3DX11Effect instances. You should stick with 'raw pointers' for ID3DX11EffectType, ID3DX11EffectVariable, I3DX11EffectPass, ID3DX11EffectTechnique, and ID3DX11EffectGroup. Don't bother calling Release on these raw pointers as the lifetime controlled by the ID3DX11Effect.
Something like:
Microsoft::WRL::ComPtr<ID3D11Buffer> m_pVertexBuffer;
Microsoft::WRL::ComPtr<ID3D11Buffer> m_pIndexBuffer;
Microsoft::WRL::ComPtr<ID3D11InputLayout> m_pInputLayout;
Microsoft::WRL::ComPtr<ID3DX11Effect> m_pFx;
ID3DX11EffectTechnique* m_pTechnique;
ID3DX11EffectMatrixVariable* m_pFxWorldViewProj;
void HillsDemo::UnLoadContent()
{
m_pVertexBuffer.Reset();
m_pIndexBuffer.Reset();
m_pInputLayout.Reset();
m_pFx.Reset();
m_pTechnique = nullptr;
pFxWorldViewProj = nullptr;
}
I write JSCript and run it with the WindowsScriptHost.However, it seems to be missing Array.forEach().
['a', 'b'].forEach(function(e) {
WSH.Echo(e);
});
Fails with "test.js(66, 2) Microsoft JScript runtime error: Object doesn't support this property or method".
That can't be right? Does it really lack Array.forEach()? Do I really have to use one of the for-loop-variants?
JScript uses the JavaScript feature set as it existed in IE8. Even in Windows 10, the Windows Script Host is limited to JScript 5.7. This MSDN documentation explains:
Starting with JScript 5.8, by default, the JScript scripting engine supports the language feature set as it existed in version 5.7. This is to maintain compatibility with the earlier versions of the engine. To use the complete language feature set of version 5.8, the Windows Script interface host has to invoke IActiveScriptProperty::SetProperty.
... which ultimately means, since cscript.exe and wscript.exe have no switches allowing you to invoke that method, Microsoft advises you to write your own script host to unlock the Chakra engine.
There is a workaround, though. You can invoke the htmlfile COM object, force it to IE9 (or 10 or 11 or Edge) compatibility, then import whatever methods you wish -- including Array.forEach(), JSON methods, and so on. Here's a brief example:
var htmlfile = WSH.CreateObject('htmlfile');
htmlfile.write('<meta http-equiv="x-ua-compatible" content="IE=9" />');
// And now you can use htmlfile.parentWindow to expose methods not
// natively supported by JScript 5.7.
Array.prototype.forEach = htmlfile.parentWindow.Array.prototype.forEach;
Object.keys = htmlfile.parentWindow.Object.keys;
htmlfile.close(); // no longer needed
// test object
var obj = {
"line1" : "The quick brown fox",
"line2" : "jumps over the lazy dog."
}
// test methods exposed from htmlfile
Object.keys(obj).forEach(function(key) {
WSH.Echo(obj[key]);
});
Output:
The quick brown fox
jumps over the lazy dog.
There are a few other methods demonstrated in this answer -- JSON.parse(), String.trim(), and Array.indexOf().
I notice Debug.Assert does not trigger in Metro apps, however, if the project is a traditional one like Console or WinForm, it does trigger. And yes, I am in Debug mode.
Is it a setting not properly set in Visual Studio (11 Beta)? Or Debug.Assert is intended to be disabled in metro apps?
I know many exceptions are swallowed during the execution of Metro apps, but Debug.Assert is so handy that I can't think of a reason why it should be disabled.
Seems like a bug. I would roll out my own assert method. Something like:
[Conditional("DEBUG")]
public static void Assert(bool condition)
{
if (!condition)
System.Diagnostics.Debugger.Break();
}
It does trigger, look in the Output window. It just doesn't automatically prompt you to ask if you want a debugger break and thus just keeps motoring.
The DefaultTraceListener.AssertUIEnabled property is false. That's an implementation problem, can't display a message box on top of Metro UI. Which does actually work but the monitor switches to the desktop, pretty undesirable when you would have liked to click No. Hard to solve and no doubt on the todo list. You can't easily get to the property to set it to true, it is inaccessible from the metadata. Filip's workaround sounds half-decent.
There is the same problem with F# in WinRT, in VS2013. The assert statement, which is an alias for System.Diagnostics.Debug.Assert, does not raise an exception, so unless you are watching the Output window then your assertions can fail without being noticed. Even if you are watching, it is hard to find the spot where the assertion was raised.
I followed Filip's suggestion and wrote a short utility, as follows:
namespace MyProj.Infrastructure
module Diagnostics =
let Assert condition = if not condition then
System.Diagnostics.Debugger.Break()
I chose Debugger.Break over raising an exception because it stops the debugger at the place the assertion fails. However, raising an exception is an acceptable alternative.
I didn't have any suitable global projects or modules already in my solution, so I had to create them just for this, which was quite annoying.
I have an Android NDK application that is doing all of its rendering in software.
Now I want to use Open GL ES to do the rendering.
I've got unit tests running by calling EGL and creating a PBuffer.
Now I want to do everything in a window instead of a PBuffer.
I adapted the code from the hello-gl2 example.
I created a new java file that uses a GLSurfaceView instead of a SurfaceView.
I have created a few native functions for GLSurfaceView.
I have successfully called C from Java, and have successfully called Java from C.
Still, no pictures.
I traced through with Eclipse and got an error that says that GL calls are being made without having a current context. I am doing
setEGLContextFactory(new ContextFactory());
setEGLConfigChooser( translucent ? new ConfigChooser(8, 8, 8, 8, 0, 0) :
new ConfigChooser(5, 6, 5, 0, 0, 0) );
setRenderer(new Renderer());
However,
ConfigChooser.chooseConfig()
never gets called. Who is supposed to call this? The sample code gives no clue.
Do I also need to make some change in an XML file?
Please give me some ideas of paths to pursue. I'm only running into dead ends.
It turns out that there was a problem with threads: the GL rendering thread and the graphics database thread were deadlocking. Here is how I solved it. I reduced the number of threads by one, and managed GL myself:
derive MyGLSurfaceView from SurfaceView instead of GLSurfaceView.
When MyGLSurfaceView.surfaceCreated() is called, squirrel away the ANativeWindow (from the main thread) in a global.
initialize EGL in the database thread using the ANativeWindow to create an EGLContext.
I have an OpenSL ES function call that causes no problems in one application, but causes a problem in another application, both run on the same device.
The line is:
result = slCreateEngine(&engineObject, 0, NULL, 0, NULL, NULL);
Where result is of the type SLresult, engineObject is of the type SLObjectItf
The error I seem to get is:
05-19 11:56:27.007: ERROR/libOpenSLES(1425): slCreateEngine while another engine 0x299fa0 is active
It seems this is not logged from my code, but maybe it is caused by it? So what could cause this line to produce an error in one app, but not in the other?
As it happens to be, it was partly Android's Activity life-cycle which caused the error, but mostly my own fault. It was caused by the onCreate() and onResume() methods Android provides for an Activity. I never thought of the fact that onResume() also get's called when an Activity is started. Because of this, I never realized that I had a 2nd call to the slCreateEngine function.....
According to the docs "OpenSL ES for Android supports a single engine per application". I had a quick check of the source for OpenSL an I can see this is enforced by a global storing the current active engine.
So if you want to call slCreateEngine, you must make sure all other engines have been destroyed first. This includes the possibility of any 3rd party code you are linking in too (incase you are linking in something else that is creating an OpenSL engine object before you do).