Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[OvermindDL1]

The render window is not what I am talking about, although yes it is slow, but that is because I assume you are probably renderoneframe'ing only when necessary rather then all the time (as in, right-click in render window, drag mouse, it updates about every half second instead of real-time, no, I have not looked at the code yet).  What I am talking about is the window itself.  Just open the app, don't open or make or anything any projects or files.  Now, unmaximise it, click and hold the lower right resize bar (or any corner), and start dragging around.   It updates reasonably fast when it is small, but as you drag the corner so it pulls the thing to be about the size of my screen (1600x1200), you can watch it paint, taking about a half-second to repaint in full, which is keeps redoing as you keep pulling it down.  In other words, painting seems extremely slow.  It's not my system I am sure, I just whipped up a quick gui that matches VOS when nothing is open and there are no repaint time issues when dragged around, no matter the size, in debug mode even (I can post it if you wish, only took about 5 minutes to make, not pretty though as it uses the windows theming), so I can only assume something is going on in the background that is probably triggered on screen repainting (triggered for every control it looks like) that is being called and doing something rather costly based on the size of the control or something...

[pjcast]

I can say that i have not seen anything like that here (in release or debug). I admit I don't have such a high resolution though, but I believe Clay does, and he hasn't reported anything.

To compare, I have two systems:
Laptop - 2.4Ghz, Win2000, ATI Mobility (garbage card) - runs perfect with no scene loaded especially
Desktop Dual 1800s (soon to be upgrade to a Core2Dou system with newer PCIx cards), Nvidia Ti4200 - no issues of what you are saying.

[OvermindDL1]

My computer is rather ancient (only an athlon 64 3400+ with a gig of ram, and I have about 30 or so programs open), but no other program I have open (which is quite a few) have such an issue, not even that one I just whipped up that was running in debug...

I think I may have found the issue though, you seem to have some rather large memory problems.  For example, just by clicking the maximise button (to maximise it), it caused over three thousand page faults in that split second (bloody massive!).  By dragging and resizing it goes up over 16k page faults a second.  I've never seen a program grow like that, and it is quite obvious the reason why the repainting is slow.  Just for comparison, I clicked-dragged Opera, Visual Studio, notepad, etc..., the largest amount of page faults any of them made (visual studio) in a single second was 7, most averaged zero to one.  Nevertheless, reduce the amount of memory thrashing, massively, of your program, or you will have wierd odd problems the longer it has been running.  The only process on my computer that has more page faults then your app after running for a one minutes is explorer.exe (the windows gui), and it has been running non-stop (no restart) for almost two weeks...

Just for note, the little app I threw together that was running in debug, was unoptomized, using gdi+ for drawing (hack/cough), so it was anything but fast...

[pjcast]

My computer is rather ancient (only an athlon 64 3400+ with a gig of ram, and I have about 30 or so programs open), but no other program I have open (which is quite a few) have such an issue, not even that one I just whipped up that was running in debug...

I think I may have found the issue though, you seem to have some rather large memory problems.  For example, just by clicking the maximise button (to maximise it), it caused over three thousand page faults in that split second (bloody massive!).  By dragging and resizing it goes up over 16k page faults a second.  I've never seen a program grow like that, and it is quite obvious the reason why the repainting is slow.  Just for comparison, I clicked-dragged Opera, Visual Studio, notepad, etc..., the largest amount of page faults any of them made (visual studio) in a single second was 7, most averaged zero to one.  Nevertheless, reduce the amount of memory thrashing, massively, of your program, or you will have wierd odd problems the longer it has been running.  The only process on my computer that has more page faults then your app after running for a one minutes is explorer.exe (the windows gui), and it has been running non-stop (no restart) for almost two weeks...

Just for note, the little app I threw together that was running in debug, was unoptomized, using gdi+ for drawing (hack/cough), so it was anything but fast...

Your computer hardly sounds ancient. As i showed my specs were considerably less than yours. In addition, my laptop only has 512MB of RAM (minus another 64MB dedicated to graphics). Anyways, I just popped opne the ol' performance monitor, added some page fault checks.. And, as I expected, no issues here. Just a few faults noticed (when Firefox had considerable more a couple hundred compared to Ogre Studio's dozen or so). Not too mention, I am also running AutoGK to convert some stuff over to XVid codec, running with multiple threads, and loading Firefox in the background... While, it took a bit longer to load up Ogre Studio than normal, resizing/min/max were very quick with very little faults (I as said before).

As for memory thrashing, minimizing/maximizing/resizing does not cause Ogre Studio to do any memory allocations/deallocations. Perhaps there are some internal System.Windows.Forms things happening, but nothing odd. I think you do have something messed up with your .Net install.

[OvermindDL1]

As you recall, something is messed up with my .NET install, and I've had plenty of people help in trying to fix it, just does not want to work, no matter how many reinstalls, file messing, etc...  Care to try to help?

Also, your undo/redo buttons on your toolbar, in the file they are blue with a transparent background, in your app the arrow is transparent and the 'background' is black.  The rest are fine, does that happen to you as well?

EDIT(few hours later):  Was loading it up again, loading screen *just* appeared, and crash with this error:

Code: [Select]

---------------------------
Microsoft Visual C++ Runtime Library
---------------------------
Runtime Error!

Program: ...am Files\WreckedGames\VisualOgre\Core\VisualOgreCore.exe



abnormal program termination


---------------------------
OK  
---------------------------

EDIT(5 minutes later):  Found the reason, you need to pop up an error when DX9.0c is not installed (was some other DX9, testing on another computer where .NET works).  I installed it and it came up, display is still laggyish.

Upon the previous error, with quick dig, it seems that it also crashed, even on my main comp, when either DX or OGL plugin is removed.  You really should set it up so it autodetects which are available.  To prevent the program from crashing due to a previous version of DX (which does not throw an exception, it just *crashes*), then you need to read the DX version before attempting to load the DX9 plugin.  I have the code for all this if you so wish.

EDIT(5 minutes yet later):  Here is an example of the detection.  Click Launch Game to init Ogre (but it does nothing else).  Launch editor launches the gui I made where I added in the drop-down box detection.  I seperated them because it also shows you (if you goto the editor without clicking to goto the game first) how it fills out when nothing is detected.  You can also rename/delete the plugin's to have it only load one or another.  If you have an old computer somewhere that does not have DX9 then it will not detect DX at all and will just ignore it (rather then having the usual forceful with no exception crashing like in your app).  Want the code?  I know it is not necessary, but as the Ogre wiki says, it makes the application look more professional when it just does not crash upon loading...  And yes, I borrowed the toolbar images...

For note, the log file will also output the detected DX value, regardless of if DX is available (will be zero if not installed).  Also, where is VisualOgre's log file placed?  And no, the linked app is not missing the config files, it does not need them, that is a subset of my multithreaded engine.

EDIT(another few hours later):  Just clicked on the shortcut, splash screen didnt' even appear, just instantly did this:

Code: [Select]

Method (wrapper runtime-invoke) System.Object:runtime_invoke_void_string (object,intptr,intptr,intptr) emitted at 01231550 to 012315E7 (code length 151) [VisualOgreCore.exe]
Method System.OutOfMemoryException:.ctor (string) emitted at 012315E8 to 0123160B (code length 35) [VisualOgreCore.exe]
Method System.SystemException:.ctor (string) emitted at 01231630 to 01231653 (code length 35) [VisualOgreCore.exe]
Method System.Exception:.ctor (string) emitted at 01231668 to 01231680 (code length 24) [VisualOgreCore.exe]
Method System.Exception:set_HResult (int) emitted at 01231688 to 01231696 (codelength 14) [VisualOgreCore.exe]
Method System.NullReferenceException:.ctor (string) emitted at 01231698 to 012316BE (code length 38) [VisualOgreCore.exe]
Method System.StackOverflowException:.ctor (string) emitted at 012316C0 to 012316D6 (code length 22) [VisualOgreCore.exe]
And if I read that right, my system has plenty of free memory, heck, had to start the web browser (Opera) just to come here...  And yes, it is still doing it (just did it again)...

EDIT(less then a minute later):  Now it comes up fine...

EDIT(an hour or so later):  Was clearing out some processes when I noticed I had an orphan VisualOgreCore.exe loaded, taking only 9 megs of memory, no window, heck, only using 78 handles.  Not a clue what caused it, there have been numerous attempts recently to start it where nothing popped up, perhaps one of them ended up as this ghost...
Either way, restarting now, been a few weeks since I've done so.

[OvermindDL1]

Quick question, I'm trying to reorganize the tabs (Project Explorer, Properties, open files, etc... kind of tabs) and they don't reorganize (I'm used to visual studio, so sue me ).  Any chance of adding that functionality?

Also, can it save the workspace as well so the files that were open last time in a project are open again when it is reopened (like Visual Studio)?

[pjcast]

As for tabs, I can't say for sure if that is possible at the moment. We use Maic Library to handle the docking/tab items, and I havn't run across a property that allows that. Although, I agree that feature is useful; fill free to add it as a feature request, and if we ever switch Magic li for something else (there are a few other docking managers) we can add that feature.

As for the saving open files for a project, good idea. Another feature request for that would rock So as these things don't get forgotten about.

[Clay]

I've added the DirectX/OpenGL plugin issue and the DirectX version issue to the mantis tracker.

Did I miss any other issues which should go on the tracker in this thread?

---

You said you have detection code available for checking DirectX versions.  Could you pass that along?  I found this on the Ogre wiki, was that what you are refering to?  If not, could you post the code you were refering to (or just a link to it) on the mantis tracker?  It has a file upload feature.

Thanks.

[OvermindDL1]

That is mostly what I was referring to and it will work fine.  Mine has slight changes in that it sets a lot of state information that is queryable elsewhere and so forth.

I'm still working on that program with that test gui, ended up being a good test-bed to test new features, like dynamically switching between D3D and OGL.  Found out the Ogre plugins had a bug (the people in IRC confirmed) and I fixed and issued a patch.  Something is still not getting set properly inside Ogre somewhere (another singleton issue probably, but need to look) before it will work 'well', but right now it does indeed work.  I could not work on it any longer after I made the patch (have work in a few minutes and I needed sleep), but will continue to do so this evening if I get home soon enough.  If you want I can give show you how to dynamically switch between the two, but you have to be sure to encapsulate your scene well (which you probably already have due to the very nature of the program) since you have to rebuild it in Ogre after the change.  The only real remaining issue I believe is to find out why when switched, the screen turns grey (as stated, probably just something I overlooked due to being tired), although rendering time is still taken and so forth with the rebuilt scene.  If you want to see the issue, I uploaded the new version over the above link if you wish to redownload.  (Yes the scene is rendering every 30ms, no I don't have any controls to you can't spin the ogrehead or whatnot.)  Try switching rendersystems (no more crash unlike before due to Ogre bug), it just does not update the window (even though I destroy the renderwindow before switch, and recreate after switch, and I do confirm it goes to the new system).  I think it is because the onetimewindowinit needs to be called again for the new system.  Will give it a try when I get home this evening.