POST
|
Just a quick update on the progress with our OpenGL ArcMap extension: Whatever the OpenGL draw issue(s) with the ArcObject "dockable window" may be, they do not affect a regular Windows Form at all. Even in the same process, if we put the OpenGL viewport on a regular form and have ArcMap show it (instead of putting the OpenGL in the ArcObject "dockable window") the OpenGL drawing in our new Windows form works beautifully. No disappearing viewport, and no flicker. We can call it from ArcMap in the same process. We're 90% of the way there, except that we still would prefer the integrated dockable functionality if possible. So the problem with the dockable windows and OpenGL either is *not* the feared issue of a potential tug-of-war between ArcMap<-->Our-extension over the OpenGL context; *or* else ArcMap is placing the extension-as-Form in its own thread for some reason, whereas utilizing the "dockable window" for the container causes the execution of drawing to exist in the main thread where presumably ArcMap has "dibs" on the OpenGL context. Or perhaps it is something else entirely and the "dockable window" simply does not work well with OpenGL for (an)other reason(s)? Can anyone from ESRI please comment?
... View more
08-16-2013
01:23 PM
|
1
|
1
|
499
|
POST
|
This request for help follows from the good suggestion by Alexander Gray of The Forum to begin a separate thread around my original post here: http://forums.arcgis.com/threads/63628-get-reference-to-a-dockable-window-controls?p=319538&highlight=opengl#post319538 [As a related aside in reply to Alexander's other comment.. Although our development machines are 64-bit we are successfully compiling all of our builds for a 32-bit target architecture, for which example applications other than our ArcMap extension work okay with OpenGL.] After another couple of days of trying to integrate OpenGL with the ArcObject "dockable window", the challenges to doing this seem a little greater than we had first imagined. Our OpenGL draw code was greatly simplified and in-lined directly into the class itself that extends the ArcObject "dockable window." For those whom it might help to understand this distinction, formerly our setup was a .Net UserControl containing a Panel object for which a System.Drawing.Graphics object was created and from that the device context ("dc") for OpenGL obtained from it via GetHdc(). This control was then pasted into the ArcObject dockable window control class, itself a subclass of UserControl. Now, instead, the device context is obtained directly in said dockable window class that Implements IDockableWindowDef so that the one unified class now contains the OpenGL code in-lined within it. The device context is obtained as follows: dc = User.GetDC(Me.Handle) For utmost simplicity for subsequent drawing, the overridden OnPaint method now merely 1) activates the rendering context (rc) with Tao.Platform.Windows.Wgl.wglMakeCurrent(dc, rc), where rc was created in the usual OpenGL way using dc 2) sets the OpenGL viewport to be the extents of the Width and Height of the dockable window 3) sets the glClearColor to green 4) then just issues glClear. If all is as it should be, this new setup described should paint the dockable window green. And the dockable window should remain green permanently as long as it is visible. What we actually see is as follows. When we first show the dockable window it is green. If the dockable window is floating and not docked, as happens to be the case when we first create it, any interaction at all whatsoever with the main ArcMap application window causes the green dockable window to turn white. This means that in response to this user interaction event, OpenGL drawing suddenly does not work in the undocked dockable window. The same is true when clicking on other application windows that are neither ArcMap nor this new dockable window--the dockable window loses the OpenGL rendering and "whites-out" as though not drawn. However our undocked dockable window lost the OpenGL, it can be made green (i.e., to be drawn complete with OpenGL rendering again) subsequently by interacting with it. But going back and interacting with the main window or outside of the ArcMap process windows always causes the same behavior of the OpenGL in the undocked dockable window to stop being drawn. For clarity, let us call this Issue #1. Question regarding Issue #1: Is there perhaps a snag with the main ArcMap application window taking and not relinquishing the device context, and if so any workaround to allow context to be shared when utilizing an Arc dockable window? [Note: I am relatively new both to Arc and OpenGL low-level programming, so any specific pointers are welcome especially if there is something obvious being overlooked here which there may well be.] Secondly, Issue #2: When the dockable window is not docked, resizes of it also cause the OpenGL to flicker as noted in my original post. Let us refer to this as Issue #2, which may or may not be related to Issue #1. We had a notion to work around this Issue #2 by causing Paint to happen only upon ResizeEnd if posslbe, but this seems not possible because the ResizeEnd event is unavailable to a mere UserControl--it looks only to be available to a Form object. The only other suggested workaround that we found (on older Forms programming message boards) was perhaps to use the Application.Idle event somehow but this seems error-prone, cumbersome, and possibly wasteful besides that it might be more relevant only for older Frameworks and most of all, we don't see how exactly to do this within an ArcMap extension. All of this being said, when the dockable window is docked in the main application window, Issues #1 and #2 go away completely. As an alternative, we have not yet tried to load our plain (i.e., non-dockable) Form instead as opposed to one of these "dockable windows." Using the dockable window option seemed most desirable because we already have several such windows all with related integrated functionality that we must manage within our extension and did not want to add yet another that must float apart from the rest. Ideally, we also may wish to permit a user of our extension to add more than one instance of this OpenGL window, but only if we can get one of them to function properly to be sure. Thanks very much ahead for any assistance. As you can see, we have a lot of investigation invested in finding a good solution. Brad
... View more
08-12-2013
11:31 AM
|
0
|
3
|
2397
|
POST
|
To ESRI Support or anybody with any insight to this specific question, We are having a terrible time all of a sudden with a new OpenGL window we are attempting to introduce as part of our C# extension to ArcMap. Whenever the window is created moved or resized, the image either doesn't appear at all or flickers badly. Outside of Arc we had solved this difficult problem previously by using a panel instead of a picturebox as the control to put underneath our opengl viewport in the custom control we made. That is to say, if we are just making a simple Windows Forms project in VS2010 for instance, the recipe of using the panel control as the same screen region as the GLViewport allowed the contents of the OpenGL viewport never to disappear on loading it up, nor flicker nor disappear on window moves, resizes, or maximizes/restores. However, inside of ArcMap we are trying to put the control we made (that uses the panel instead of the picture box) onto one of these "dockable windows" as described in this thread and here http://help.arcgis.com/en/sdk/10.0/arcobjects_net/conceptualhelp/index.html#//00010000014w000000 and now all of a sudden we are seeing the same issue as before with the OpenGL drawing (code that was reasonably well tested outside of Arc wrt this issue). The undrawn, or partially-undrawn, window really is unacceptable for would-be users of our extension. Often nothing draws at all, you just see the flat background window or control color where the normally good-looking interactive OpenGL stuff is supposed to be. Long story short, within these new constraints of using the Arc dockable window we can't seem to figure out how to ensure that the drawing always happens as it's supposed to and avoid whatever hDc, windows messaging, and/or other race condition(s) are making our opengl screen region disappear intermittently as a result of dropping it into the dockable window control. This is an opengl issue, but also related to the dockable window. How do we make a control with an opengl viewport draw correctly in this dockable window, or better yet, regardless of whatever windows forms container it is placed into? Before anyone questions hardware, drivers, environment, etc, also know that this 64bit test machine has all of the latest opengl drivers, 4Gb of memory, tao for namespace in C#, pretty much top of the line. And, like I say, we tested the opengl example outside of ArcMap and it worked fine, no flicker no redraw issues. We obviously didn't fully understand any of these limitations when we first started adapting the dockable windows for our Arc extension. It's a bit surprising that such subtle distinctions as whatever this is (native form versus dockable window or whatever) would prevent the opengl display from functioning properly. There must be some easy solution. The panel thing took a long time to figure out but somebody had made a good post about it here which is how we learned that trick. http://www.opengl.org/discussion_boards/archive/index.php/t-160945.html For this dockable window piece, we�??re just fast running out of ideas after spending a day racking our brains, and any help would be really appreciated. Thanks much, Brad W Senior Systems Engineer
... View more
08-07-2013
01:00 PM
|
0
|
0
|
908
|
Title | Kudos | Posted |
---|---|---|
1 | 08-16-2013 01:23 PM |
Online Status |
Offline
|
Date Last Visited |
11-11-2020
02:24 AM
|