I'm using Direct2D to render my user interface.
What I would like is to be more easily able to profile my ui rendering (since I'm using several panels using Graphics debugger is a bit cumbersome).
Since I know that Direct2D uses a Direct3D device (exactly d3d11 device using 10_0 feature level) under the hood, I'd like to know if it is possible to retrieve either a ID310Device or ID3D11Device instance from ID2D1RenderTarget or ID2D1Factory object.
In that case I would easily be able to attach a timestamp query on the BeginDraw/EndDraw calls.
I tried several QueryInterface calls, but none of them have been sucessful so far.
An interesting undocumented secret is that any ID2D1RenderTarget you get from ID2D1Factory will also be an ID2D1DeviceContext (it seems to be intentional from what I've gathered, just accidentally undocumented?). Just call IUnknown::QueryInterface() to snag it. From there you can toy around with methods like GetDevice() and GetTarget(). If you can get the target then you may be able to weasel your way to obtaining the IDXGISurface which supports IDXGIDeviceSubObject::GetDevice() https://msdn.microsoft.com/en-us/library/windows/desktop/bb174529(v=vs.85).aspx (I haven't verified this part)
And in Win10 it looks like ID2D1Device2 gives you precisely what you want: GetDxgiDevice() https://msdn.microsoft.com/en-us/library/windows/desktop/dn917489(v=vs.85).aspx . So in that case, your ID2D1RenderTarget is cast to an ID2D1DeviceContext via IUnknown::QueryInterface(), and then you get an ID2D1Device via ID2D1DeviceContext::GetDevice() and then cast it to an ID2D1Device2 via another call to IUnknown::QueryInterface().
Related
Omniture's basic page tracking function, s.t(), was not crafted for AJAX implementation. Unlike the onclick s.tl() function which has some gating instructions with s.linkTrackVars and s.linkTrackEvents, the s.t() function just perpetuates every cached property through to the next call and beyond.
I used to be able to use a ClearVars function to empty out all of the s object's attributes, but now that I am using AppMeasurement and letting DTM manage my implementation with the most updated version of that library—which I want to keep doing—I can't call the s object. I get the same "ReferenceError: s is not defined" that another person asked about here!.
I tried following Crayon Violent's instructions within that post, but I can't seem to find where DTM is stashing the cached values in between Adobe calls. This code:
window.s = new AppMeasurement();
lets me change/clear the attributes of s, but it's not the s I'm looking for. When I call the next AJAX s.t() function, all of the cached values are still there.
In my experience working with DTM and AA, there has been no end to bugs and caveats and workarounds with DTM's "native integration" of AA. This is why I have more or less decided that the best thing I can do is to either manage the lib myself or else treat AA as a 3rd party script (100% implement it through rules, just ignore that it's available as a tool).
As mentioned in my answer you linked, that line of code only works to expose the AA object in the window namespace if you are managing the library yourself. When you configure DTM to manage the library, it will instantiate AA object itself, and it will be buried within its own code (Honestly, I don't know why DTM did this, considering AA puts a number of other variables in the global namespace that DTM does nothing about).
AFAIK there is no documented way to reference it, but one thing I have found that seems to work for me - which as a disclaimer to cover my own arse I do NOT officially endorse: use at your own risk - is to use the following to get a reference of it:
var s = _satellite.getToolsByType('sc')[0].getS();
This uses getToolsByType method to get an array of the SiteCatalyst (Adobe Analytics) objects setup as tools in DTM. It does this by looping through _satellite.tools and comparing _satellite.tools[n].settings.engine to what you passed to getToolsByType.
Then I use [0] to get the first one in the array, under the assumption that there's only one configured (most people only do one). Then the getS() object pulls together the s object based on the settings in DTM. So from there, you can do things with it, including making use of s.clearVars()
I'm trying to set the Visitor ID in Adobe Analytics through DTM.
Above the s_code I have:
var visitor = new Visitor("xxxx")
visitor.trackingServer = "xxx.xx.xx.omtrdc.net"
I've created a data element where the legacy code used to call the
Visitor.getInstance("xxxx");
and set the Visitor ID to %Visitor ID%
That's not working however, and my visitor ID is always just set to %Visitor ID% and obviously not reading any values. I'd really appreciate any input that someone can give me.
Thanks,
Mike
The Visitor ID pops s.visitorID and is in general related to visitor id, but is not the same as s.visitor which is what gets popped for the VisitorAPI integration. DTM does not currently have a built-in field for the s.visitor variable, so you will have to set it yourself within the config, either in the Library Management code editor (assuming you are opting to c/p the core lib and not the "Managed by Adobe" option) or else in the Custom Page Code section.
Since you are popping it in a data layer first, you can reference the data layer like this:
s.visitor = _satellite.getVar('Visitor ID');
NOTE: A separate potential issue you may have is with whether or not the Visitor object is available for your data element. Since data elements are the first thing to be evaluated by DTM, you will need to ensure that the VisitorAPI.js library is output before your top page DTM script include.
If this is a problem for you, or if you are wanting to host VisitorAPI.js within DTM, then you may need to adjust where you are popping that stuff. For example, place the VisitorAPI core code above the custom code as the first stuff within the data element, before:
var visitor = new Visitor("xxxx") visitor.trackingServer = "xxx.xx.xx.omtrdc.net
Or, don't use the data element at all. Instead, put the VisitorAPI code within the Adobe Analytics custom code or core lib section and pop all that stuff (aboove the s.visitor assignment). Or a number of other methods; point is, VisitorAPI stuff must be loaded before the data element can make use of it, same as it must be loaded before Adobe Analytics can make use of it.
So DTM is changing pretty fast and furious right now. They have a "Marketing Cloud Service ID" that works well. Before I used that, however, I did find a way to fix the code. Crayon Violent was right, as usual, that the problem was that the script wasn't available yet. I fixed this by putting the following code in between the VisitorAPI.js and the AppMeasurement stuff in the DTM managed library.
var aA = new AppMeasurement();
aA.visitorNamespace="companyname";
aA.visitor = Visitor.getInstance("companyname");
In addition, there were also some issues using my localhost for testing while trying to see if I had this correct or not. If you are having issues and think you have it correct, it may be worthwhile to elevate it to a different environment.
My application uses 2 DXGISurfaceRenderTargets.
The 1st render target is used to create ID2D1Bitmap, then ID2D1BitmapBrush from it.
Resulting ID2D1BitmapBrush is used to FillGeometry on the 2nd render target.
Is it possible to retrieve IDXGISurface that was used to create ID2D1BitmapBrush from the ID2D1BitmapBrush or the ID2D1Bitmap?
Windows 8 has ID2D1Bitmap1 with GetSurface method, but I need this on Windows 7.
Thank you.
No, you cannot, as you pointed out, only ID2D1Bitmap1 can retrieve the surface by calling Getsurface, and that's only works on Windows 8.
If you want to use the surface, can you store it after creation, and then pass it as the parameter to the function which used it?
D2D1Bitmap
D2D1Bitmap1
I am using the Datalogics library 9.1 and I am trying to embed an OutputIntent in a PDF I am creating so that it will be compliant with PDFA-1B.
I'm using PdDocColorConvertEmbedOutputIntent to do so and the function call is succeeding. The intent is getting in there, I can see it in Adobe Preflight. But certain PDFA verifiers still do not like what I'm creating.
I think it may be because the PDFA/s I create with this method have an outputIntent with a subtype of "GTS_PDFX" (as shown in Preflight). I believe it needs to be "GTS_PDFA". I see nowhere to specify the subtype of the output intent in the PdDocColorConvertEmbedOutputIntent parameters. This meethod seems to automatically choose the "GTS_PDFX" subtype and not allow me to choose anything else.
Basically, I'm just reading an ICC profile into pBuffer from a file, creating the profile and embedding it as below.
AC_Profile profile = NULL;
ACMakeBufferProfile(&profile,pBuffer,nSize);
PDDocColorConvertEmbedOutputIntent(m_pDoc,profile);
Am I missing something?
The 9.1 API and early versions of the 10 API have no parameter to supply to PdDocColorConvertEmbedOutputIntent () to specify the subtype. At the time of creation there was only one subtype "GTS_PDFX" and was hard coded into the API.
Manipulation at the COS layer will be necessary to affect a change to the subtype.
The Documentation of OpenCV mentions that "the returned image (by cvRetrieveFrame) should not be released or modified by the user" ...
Link: http://opencv.willowgarage.com/documentation/c/highgui_reading_and_writing_images_and_video.html#retrieveframe
I am trying to debug my code, which involves the following steps:
Retrieve frame from video using cvRetrieveFrame()
Do some processing on the frame
output results
My instinct says that something is wrong with cvRetrieveFrame() because if I manually input frames using cvLoadImage, the program works fine. But I am not getting same results while using cvRetrieveFrame().
Since the documentation mentions such a restriction, any reason for such a restriction ? And, any alternatives ?
Have a great day
Before you call this function, you should have used another function which is cvGrabFrame() in order to be able to use the mentioned function, which you can use it for doing any necessary processing on the frame (such as the decompression stage in
the codec) and then return an IplImage* pointer that points to another internal buff er
(so do not rely on this image, because it will be overwritten the next time you call
cvGrabFrame()).