Slow/Jerky UI Performance On Some Systems (Full Version)

All Forums >> [Current Games From Matrix.] >> [Napoleonics] >> Crown of Glory >> Crown Of Glory Support



Message

thufir -> Slow/Jerky UI Performance On Some Systems (10/9/2005 5:58:28 AM)


This looks like a fun game, but after starting up it seems clear that there I've got fairly serious lag problems on many parts of the UI. It also seems clear that not all users are impacted, but based on posts in this forum it looks to me like there is a significant subset of users that are having the same problem I am. I've seen some replies from west-civ, but none that either provide a resolution to the problem, or clearly acknowledge the bug.

Here are 3 posts that may be describing the same bug:
post 1
post 2
post 3

HW Setup:
Pentium 4 1.6 GHz
512 MB
Windows XP Home (5.1, Build 2600)
Virtual Memory: total paging size currently 700mb, using "Custom Size" option: 700mb-1500mb (planning on forcing page size > 1500 next, to see if that helps).

NVidia GeForce3 Ti200 w 64MB
Drivers have been recently updated (version: 6.14.0010.7772)
Direct X 9.0c (4.09.0000.0904)
I've attached the DxDiag.txt file, for west-civ's benefit.
CoG v1.1

I have very little in the way of background processes running when I go into CoG, but when I go in, I see the same general jerkiness that others describe. The worst behavior I've seen so far is in the military screen, where I can cue up a few scrolls, and leave the program locked up for minutes, as it struggles to clear the buffer (I think west-civ may have called this the "slow click" problem, or something like that, in one of the posts above). While this worst case behavior is avoidable, the best case behavior is pretty bad, at least on this screen. While my system is not state of the art, it is well beyond the minimum specs, and really should be more than good enough to handle any strategy game.

It would be great to get a response from west-civ on this (it does look like they're pretty active on this forum, which is cool). It'd be wonderful if we could get a set of system tweaks that constitute a workaround for this, but failing that I'd like to see west-civ acknowledge this as a bug.

TIA,

Thufir




jvgfanatic -> RE: Slow/Jerky UI Performance On Some Systems (10/9/2005 6:39:25 AM)

Yep, I've said it before. I think one of the more "over-plush" UI elements in a Matrix game is the military list. I have a system similar to yours with 1 gig on video and 1 gig in RAM and the thing still chokes on that list.

Actually, this problem alone has relegated the game to the "seldom played" folder :(

Sad but true, cause otherwise I really love it.



ericbabe -> RE: Slow/Jerky UI Performance On Some Systems (10/9/2005 4:56:44 PM)

On the Military Advisor screen the slowness is in the calls to Windows which allocate/move all the Windows-objects used on that screen. In all the places where the slowness is occuring on this screen my code looks something like this:

1) Loop through all the window handles used on this screen
2) Windows: please allocate/move this object
3) End loop

The delay occurs during the call to Windows in 2. It's a delay most likely because Windows is having to manipulate the Windows objects in virtual memory.

Have you tried running the game in low-animation and/or no-sound modes? Low-animation mode, in particular, has much, much less memory overhead than the regular mode, and the game really doesn't suffer that much for losing the puffs of smoke and being able to watch your little guy raise his sword when he charges.

In short, the problem seems to be on systems that are running largely in virtual memory space. The delay occurs in Windows code which I did not write and over which I have really no control. The only two possible solutions I can imagine are (1) to use fewer Windows objects (not really a possibility as it would involve writing an entirely new engine at this point) or (2) allow users to use less memory to try to avoid VM caching. We have provided a solution in the form of (2) by way of the low-animation / no-sound modes.




jvgfanatic -> RE: Slow/Jerky UI Performance On Some Systems (10/9/2005 6:39:48 PM)

I had the opportunity to reformat my machine the other day. Did a fresh install of ALL matrix games (and believe it or not they were the FIRST things I installed on my PC.

AMD Atalon XP 2000+
XP SP2
1.66 GHz
1GB of RAM
GeForce4 Ti 4600 w/1GB

On a fresh launch with LOWANIM and NOSOUND has a really jerky, slow, unweildy Military Advisor screen. It's been this way since day one. On a machine of this calibur (not the best but no slouch either) a list shouldn't perform this badly.



ericbabe -> RE: Slow/Jerky UI Performance On Some Systems (10/9/2005 7:38:42 PM)

quote:

ORIGINAL: jvgfanatic
XP SP2
1.66 GHz
1GB of RAM
GeForce4 Ti 4600 w/1GB

On a fresh launch with LOWANIM and NOSOUND has a really jerky, slow, unweildy Military Advisor screen. It's been this way since day one. On a machine of this calibur (not the best but no slouch either) a list shouldn't perform this badly.


Those specs are better than my laptop specs; the video card is much better -- and the game runs just fine on my laptop in full animation, full sound mode, including the Military Advisor list -- with the debugger (no small program that) running along with it.

On our worst system that we test on (which has the min-specs listed on the box), running in low-anim/no-sound the Military Advisor list still functions alright, though there is a small delays when scrolling (but certainly not anything like 1 minute long.)

The long delays, as I mentioned, are almost certainly being caused by Windows internal code trying reorganize a table of windows-handles that is located all or in part in virtual memory. Any Windows program that uses a lot of MFC resources that is running partly in VM can experience very long delays.

The code I use to perform the Windows operations necessary to manipulate the list of windows in the advisor screens looks something like this:

1) Loop through all the window handles used on this screen
2) Windows: please allocate/move this object
3) End loop

All the delay is occuring in step 2 -- that is, in OS level code that I did not write but that is necessary to be called in order to manipulate Windows objects. There is not really any other way to create a window in Windows than to make Windows calls. Rewriting the operating system, sadly, is beyond the scope of this game. I could rewrite the list mechanism to avoid using Windows objects altogether, and just use my own graphics objects, but at this point that would be tantamount to rewriting the UI engine altogether.




jvgfanatic -> RE: Slow/Jerky UI Performance On Some Systems (10/9/2005 8:50:00 PM)

Totally understood on all counts that the problem isn't really fixable. The delays on my machine aren't 1 minute long but the list is "slow" and "clunky" when compared to other "lists" in other strategy games. There was a time, before the reformat when the list was having 20-40 second delays at times. I'm not too worried about that, a periodic reformat is a side effect of running under Windows. I do wonder if some UI optimizations could be made to the list itself to speed it up.

Tantamount to rewriting the UI? Heh, every programming job I had was UI work. I loved tinkering with this sort of thing but alas I can understand that there are other priorities.

IMO: If a list looks as beautiful and useful as the one in the Military Advisor screen then it should have been written with custom routines from the start. Pasting pretty pictures on top of a very robust yet resource heavy windows mechanism is suspect from the get-go.



thufir -> RE: Slow/Jerky UI Performance On Some Systems (10/9/2005 9:34:53 PM)


First of all, let me say thanks Eric for your quick and detailed replies. That's not a given in the world of computer games, but it goes a long, long way in getting my loyalty as a game buyer! I do believe that game companies that support their games well can develop a large fan base (which of course ultimately turns back into profits for said company).


quote:

ORIGINAL: ericbabe
Those specs are better than my laptop specs; the video card is much better -- and the game runs just fine on my laptop in full animation, full sound mode, including the Military Advisor list -- with the debugger (no small program that) running along with it.


This implies that to greater or lesser extent, the problem is platform specific. It seems to me that the most fruitful line to pursue is to diagnose precisely which systems have this problem, and which don't. If we're luck this might point us immediately to a workaround (say for example if we find this is only happening on systems which have NVidia boards and use Logitech Mouse drivers [don't laugh - i've seen it happen], then we can just go back to default MS mouse drivers and wala - problem solved!).

One thing seems clear on the system side, and that this is not a problem specific to systems w/ low memory. jvgfanatic clearly has lots of memory, both on the ram side and especially on the video side. So far we have 2 problem machines w/ older NVidia boards, so NVidia is certainly a candidate as the source of the problem (graphics boards should be high on the list when tracking down platform specific performance bugs).

Is there anything you can do to try to reproduce this bug at your end? Do you have any machines w/ older NVidia boards on them? Is there any further diagnostic info I can give you?

For anyone else out there reading this, do you see the same performance problem on the military panel? Some of the earlier posts were focused on scrolling the map (where I also see performance problems) - personally I'm inclined to believe their related, but the military screen makes this problem jump out far more obviously, at least on my system. It would be good if we could see some more system specs for users that are seeing this problem.


quote:


1) Loop through all the window handles used on this screen
2) Windows: please allocate/move this object
3) End loop


Once upon a time (in the early days of DirectX (v3 - v6) I used to write 3D character animation, and even though it's been a while, I can say that there is one honkin big red flag in pseudo code above. That being the "allocate" included in step 2. If you mean that you literally allocate an object evertime you move it (or even every time that object becomes visible, as you scroll through the list), than that would be distinctly bad architecture.

With graphics/UI code, you always want to move your allocate/destroy code as far out of inner loops as possible. Every object in that list should be allocated the first time the military panel is entered, and references to them stored in a static object/structure. As the list is scrolled through, objects should be shown/hidden (rather than allocated/destroyed - and btw, I'd bet a $1,000 that MFC still has the hide/show functionality for the objects in question). The same thing when the military panels is displayed/exited - everytime I go into that panel I see a delay of several seconds. With good architecture, that would happen perhaps on the first time you bring the panel up, but it should not happen repeatedly.

Now this might mean an architecture change, and that might be a problem to include in a patch, but at least you should consider this style of UI architecture for future products. Also, this should be a less difficult architecture change than moving away from MFC for your UI objects (imho MFC is a good choice for CoG). Finally, it shouldn't be out of the question to consider this in a patch. If enough users out there are experiencing this problem then it might be worth your while to go through the work/risk of making this change (and remember, most users who experience this are likely not saying a word, and instead walk away from your game in frustration - as such getting an estimate of the percentage of your users who have this problem will require some analysis).

I'd also mention that all the above commentary on your list scrolling pseudo code does not change my opinion that this problem is platform specific (at least in a practical sense). However, if you did implement an architecture w/ object creation/destruction moved out of loops, you would have an implementation that was far more robust w/r to performance and would probably work better on all the lower end systems out there.

One thing to note is that the systems that do not see this problem might have some hardware/software combination that allows them to cache the objects that you are allocating/destroying. For example, I've seen it happen with MFC that developers all have a particular version of a particular DLL that behaves slightly differently than the DLLs that come with the MFC install. Presumably you've tested on clean systems that have never seen any developer versions of MFC (or anything else), so that wouldn't be the problem, but you get my drift.

Well, forgive my long winded post, but I would really love to see this problem nailed. Eric, if I've misinterpreted your pseudo code, forgive me, and just ignore all my above comments on architecture.


Cheers,

Thufir





thufir -> RE: Slow/Jerky UI Performance On Some Systems (10/9/2005 9:44:17 PM)


quote:

ORIGINAL: jvgfanatic

IMO: If a list looks as beautiful and useful as the one in the Military Advisor screen then it should have been written with custom routines from the start. Pasting pretty pictures on top of a very robust yet resource heavy windows mechanism is suspect from the get-go.


On this point, I'd respectfully disagree (not on the fact that the Military Advisor screen is beautiful and useful, but on the use of custom routines ;) ) Especially on your system w/ 1gig of video memory, pasting pretty pictures into a scrolling list should be no problem at all. It's not like we're doing 3D on the fly, w/ tons of dynamically generated shadows, reflections, what-have-you going on here. Based on Eric's pseudo code, I'd guess that more careful memory management (or object management, if you prefer) is all that's required (see detailed comments in my post above).




Mr. Z -> RE: Slow/Jerky UI Performance On Some Systems (10/9/2005 9:47:04 PM)

I agree that on the face of it, there's no good reason why this is happening, but I do wonder if it's the GeForce 4 (my GeForce 2 works fine) but this is sort of grasping at straws...



ericbabe -> RE: Slow/Jerky UI Performance On Some Systems (10/9/2005 10:31:52 PM)

quote:

ORIGINAL: thufir
ly to a workaround (say for example if we find this is only happening on systems which have NVidia boards and use Logitech Mouse drivers [don't laugh - i've seen it happen], then we can just go back to default MS mouse drivers and wala - problem solved!).


The problem most likely involves virtual memory caching -- that's the only thing I can think of that can take up minutes of time on a computer -- so video cards and mouse drivers should be fairly irrelevant.


quote:


One thing seems clear on the system side, and that this is not a problem specific to systems w/ low memory. jvgfanatic clearly has lots of memory, both on the ram side and especially on the video side. So far we have 2 problem machines w/ older NVidia boards,


Even with a 1GB system VM caching can happen if system memory being put to use for other high thread priority tasks (such as virus checkers, or systems with a lot of ad-ware/spy-ware.) Also depends on how the page file is set up... I believe it is possible to setup the page file so that Windows is more likely to use it (such as setting Control Panel | System | Advanced | Performance Options | Advanced | Memory Usage:Programs/System Cache to System Cache, for instance.)



quote:


Once upon a time (in the early days of DirectX (v3 - v6) I used to write 3D character animation, and even though it's been a while, I can say that there is one honkin big red flag in pseudo code above. That being the "allocate" included in step 2. If you mean that you literally allocate an object evertime you move it (or even every time that object becomes visible, as you scroll through the list), than that would be distinctly bad architecture.


I don't actually allocate an object every time I move it. I was just giving an example of what the code looks like. The allocation code looks like:

1) Loop
2) Windows::Allocate
3) End loop

the move code looks like:

1) Loop
2) Windows::Move
3) End loop

the hide window code looks like:
1) Loop
2) Windows::Hide this
3) End loop

etc.


quote:


that panel I see a delay of several seconds. With good architecture, that would happen perhaps on the first time you bring the panel up, but it should not happen repeatedly.


It's not that a call to any particular MFC function has a short delay and that all these delays add up, it's that every once in a while on systems that are VM page caching that one single MFC calls forces MFC to reorganize some internal table and to page-cache often while doing it.


quote:


a patch. If enough users out there are experiencing this problem then it might be worth your while to go through the work/risk of making this change (and remember, most users who experience this are likely not saying a word, and instead walk away from your game in frustration - as such getting an estimate of the


I'd also be interested in finding out how many users are having this problem...


quote:


However, if you did implement an architecture w/ object creation/destruction moved out of loops, you would have an implementation that was far more robust w/r to performance and would probably work better on all the lower end systems out there.


Again: I really want to make sure that people understand that my UI archicture does *not* work in the crazily flawed way that you describe.


quote:


install. Presumably you've tested on clean systems that have never seen any developer versions of MFC (or anything else), so that wouldn't be the problem, but you get my drift.


Naturally. Though I suss that dev versions of MFC are much, much more bloated than the release build versions, and so the expectation is that the delay in developer version calls would be even worse.





ericbabe -> RE: Slow/Jerky UI Performance On Some Systems (10/9/2005 10:59:50 PM)

quote:

ORIGINAL: thufir
On this point, I'd respectfully disagree (not on the fact that the Military Advisor screen is beautiful and useful, but on the use of custom routines ;) ) Especially on your system w/ 1gig of video memory, pasting pretty pictures into a scrolling list should be no problem at all. It's not like we're doing 3D on the fly, w/ tons of dynamically generated shadows, reflections, what-have-you going on here.


Since you seem to know something about this, can you tell me how to use video memory to solve a page-caching problem involving MFC internal tables? For instance, I could write this code:

HWND hTable[SomethingReallyBig];
// code that initializes the table....
// code that moves the table
for (int i=1; i<SomethingReallyBig; i++)
:MoveWindow((HWND) hTable, 0,0, 100,100,false);

How would I use video memory to have MFC avoid page caching while processing the :MoveWindow call?


quote:

ORIGINAL: thufir
what-have-you going on here. Based on Eric's pseudo code, I'd guess that more careful memory management (or object management, if you prefer) is all that's required (see detailed comments in my post above).


Again, please allow me the opportunity to dispel the notion that my Windows object management works according to the flawed method which you had suspected. It does not.




jvgfanatic -> RE: Slow/Jerky UI Performance On Some Systems (10/9/2005 11:01:24 PM)

Great reading people and let me echo the thanks for the speedy and detailed replies. 'Tis also why I'm a new but very loyal Matrix customer.

I'm thankful that thufir clearly has his chops when it comes to Windows issues :) My last programming job was over 7 years ago and I was purely Macintosh focused. lol. LDefs and MDefs were my loves.

Unfortunately this is the most powerful Windows based machine I have in my house to test on and I have no other video cards. I'm actually very much a newbie when it comes to PC gaming.



ericbabe -> RE: Slow/Jerky UI Performance On Some Systems (10/9/2005 11:33:55 PM)

quote:

ORIGINAL: Mr. Z
I agree that on the face of it, there's no good reason why this is happening, but I do wonder if it's the GeForce 4 (my GeForce 2 works fine) but this is sort of grasping at straws...


The delays thufir and jvgfanatic are experiencing shouldn't have anything to do with the video card. COG is quite memory intensive and seems to be forcing some machines to run using virtual memory. *Any* application that runs with many VM caching events will run much more slowly than normal, and if it does something that is memory intensive and a lot of caching (such as a bubble sort) it may experience very long delays.

Video card memory is normally reserved, naturally enough, for use by the video card. I don't know of any way to get Windows to run its internal objects in heaps allocated in video memory. In fact, the only way I know of to directly access video card memory is through the DirectX libraries, and even they only make preferences as to which type of memory gets used for allocation...and local-video memory allocated by DirectX sometimes has to be locked as write-only in relation to the CPU for the video card to use that memory, so I'm not sure how MFC and the video card could effectively share video memory.

The parameters that cause a system to use virtual memory are various. Systems with a lot of free memory but with high-priority resident applications (including spy-ware and ad-ware) can cause regular applications to dip into VM. There are settings in Windows that can cause applications actually to prefer to use some cache memory in order to keep RAM open for other Windows applications. So simply having 1GB is no guarantee that VM caching will not occur.

The speed of virtual memory also varies according to the state and speed of the harddrive. Running VM on a fragmented HD, for instance, is much slower than on an unfragmented HD.




ericbabe -> RE: Slow/Jerky UI Performance On Some Systems (10/9/2005 11:35:47 PM)

quote:

ORIGINAL: jvgfanatic
Tantamount to rewriting the UI? Heh, every programming job I had was UI work. I loved tinkering with this sort of thing but alas I can understand that there are other priorities.

IMO: If a list looks as beautiful and useful as the one in the Military Advisor screen then it should have been written with custom routines from the start. Pasting pretty pictures on top of a very robust yet resource heavy windows mechanism is suspect from the get-go.


I must admit that I haven't been that pleased with the MFC routines. I've customized just about every thing that MFC makes transparent enough to be customizable and I've had to write my own messaging system to add behavior that isn't normally available in MFC. And you mention, they are somewhat of a hog when it comes to system performance.



jvgfanatic -> RE: Slow/Jerky UI Performance On Some Systems (10/10/2005 7:25:55 AM)

Not really wanting to derail this thread or anything but there is an element of the UI (well, dozens like this really but I've not taken the time to iterate them all) that has been bugging me:

In the tutorial there is a window described that isn't named but I believe it is called the "attachment box" (it being unnamed in the tutorial is another bug however...)

When you move the mouse over the units in this window a "select info" cursor appears.

The sensitive area for the cursor is offset on the horizontal axis so that it's not over the unit's designated rectangle (in the attachment box).

This actually interferes with the "+" and "-" buttons so that only the left half of them is clickable/active. It also causes the right portion of the unit rectangle to be inactive.



Page: [1]

Valid CSS!




Forum Software © ASPPlayground.NET Advanced Edition 2.4.5 ANSI
1.107422