Aug 30 2016, 8:52 am
|
|
Lummox JR
  |
I'm thinking what I might try to do here--though this is very much a crapshoot--is to see if the images can be pre-displayed during the load, hidden behind the splash, in order to frontload all of the ImageDecode functions and possibly also texImage2D. This is iffy because the last time I took a foray into preloading, I ran up against a Chrome bug that used way too much memory up front and wouldn't let it go. But that was to get alpha maps, whereas this is a little different, so I'm hoping Chrome won't do things quite the same way.
|
That would be great if it works out. Might even be worth the memory hog/bug unless we're talking huge numbers.
| |
Weird. I'm not sure if this is just an issue with the latest version but things are a lot slower now:
http://puu.sh/qTVsr/11750c428c.png http://puu.sh/qTVvc/4225c7215b.png http://puu.sh/qTVxG/7425c860e8.png And a profile: http://puu.sh/qTVOG/6d4b63e702 Compared to this, which was a lot cleaner: Pixel Realms wrote: http://puu.sh/qmZai/7f99cfcd0c.png The 'anon' function at the top points back to invoke closure. 'ClearTimeout' also causes jank, but not as often. A good ddeal of procs are still also being marked as 'Optimized too many times' which might be something to look into, since it means Chrome keeps trying to reoptimize, which slows things down. We'll test against older BYOND versions tonight to see if anything is up there. | |
That looks like an apples-and-oranges comparison to me; the times on that first set are ridiculously small. But again, the top-level anonymous function is meaningless in this comparison. You have to look at the individual stuff like doAtoms() and whatnot.
| |
Well, I thought something was up since the profiler is showing longer frames throughout now, and I've profiled multiple times to confirm it's not a one off. Other than when ImageDecode/textImage2D show itself, there isn't really any significant stuttering/pauses on my machine.
I'll compare to past BYOND versions later today to see either way. It struck me as off so I figured it'd be a good idea to mention. Lummox JR wrote: the times on that first set are ridiculously small. But I definitely don't agree with you here, unless I'm misunderstanding. Any frame that's longer than 10ms can mean a FPS drop, so when you have frames that are consistently 100ms, things aren't going to be too pretty unless the person is on a high-end machine. | |
I'm talking about in comparison to the second set. If you look at the times, it's clear that one of those runs did not collect data for very long at all.
| |
Ah, hm... I'm a little confused. Both live profiles in the first and second set were taken for about 40 seconds. The frames highlighted in the first set's screenshots just weren't as expensive.
I suspect it's not an issue with recent changes in the engine but something to do with my computer's performance, though, maybe. It doesn't really matter until I compare the BYOND versions, so perhaps it wasn't a good idea to bring it up. | |
Pixel Realms wrote:
We'll test against older BYOND versions tonight to see if anything is up there. Okay, confirming that this isn't an issue on BYOND's end. Might just be a change in Chrome's profiler or something else... | |
Any plans to optimize the current problem area functions? Things are still pretty rough for low-end users, and that's with the game set down at 10FPS, so games at a higher FPS will suffer moreso. Ideally we want to raise the FPS of the game in the future but that won't be possible without further optimization to the webclient.
| |
Optimizing the image decoding function and texImage2D is literally impossible; those are in the browser. However I believe I'll try loading icons into a hidden portion of the load screen to see if I can force some of this to happen earlier. The real question is whether Chrome will try to hang onto the memory forever if I do; I know it had a heck of a problem with that when it came to alpha maps.
| |
I was speaking generally rather than specifically the decoding function and textImage2D, since your own profiling is obviously going to be a lot more efficient at figuring out what could be improved. I can point out functions that seem off to me but in the end I don't understand what I'm really looking at, other than that the webclient really needs to be faster than it is ATM.
http://puu.sh/rpMeS/15ae8d9372.png Is this something on our end by the way, since the anon function doesn't link to any dart code? But dart.invokeClosure and the anon function on line 23294 appear in long frames and seem slow, I think: http://puu.sh/rpN5k/22643ef458.png (Again though--my finger pointing is probably way off, but if you can identify and fix culprits, that'd be great) | |
As I've said before, the anonymous function and the closure are top-level functions that all the other stuff hangs off of. They are utterly meaningless in terms of profiling because they're basically running the entirety of the program.
When you look at profiling info on those functions, it's like trying to find out which of your appliances uses the most electricity by narrowing it down to something in your house. | |
Ah, okay. Yeah, then I'm not really sure. Do you have any functions in mind to work with outside of the image decoding and textimage2D?
| |
It's strictly a matter of looking at what takes up time that's actually directly in the webclient code. Those routines you keep looking at are too high-level, and image decoding and texImage2D() are internal to the browser. It's a question of which functions in the webclient proper are taking the longest.
| |
I have no idea how to tell apart the routines that are top-level, but either way it's probably a whole lot easier for you to spot inefficiencies since you have access to the webclient code.
| |
Basically the fact that stuff like invokeClosure takes up most of the running time is a big clue that it's top-level; it also doesn't have a name like drawMap or renderObject or such that would suggest it's part of the nuts-and-bolts code.
| |
Will there be any optimizations in the near future? Again, I want to stress that there are severe performance issues with the webclient on a game that is tile-based, runs at 10FPS, and has a small resolution compared to standard web games. My biggest fear right now is uploading our game to, say, Kongregate, and getting low ratings due to client-side lag. Unless a player has an i5 processor or better, they can expect consistent stuttering at times that wouldn't be a thing in DS.
Although I realize that you have a lot on your plate--it's just that it's been almost half a year since the last optimizations and I feel like this should be a high priority thing, since nobody is really going to use the webclient unless its performance is up to par. | |
For example, this is how it plays while using an i3 laptop (2 cores, 1.7ghz, 4gb ram) that I've been testing performance on: http://i.imgur.com/J9ypQTj.gif
You can see instances where frames are skipped due to jank, such as when I first attack the boar, or when the 'Fenworth Valley' text appears, causing me to lag out into the trees. | |
Honestly, a 2-core 1.7 GHz system with only 4GB of RAM is very underpowered. We're talking about a game that's running in a browser, and browsers have plenty of their own housekeeping to do. 4GB is really inadequate RAM for Windows 7+, and at only 1.7 GHz there are fewer cycles per any given amount of time. Your testing is basically giving you a worst-case scenario that won't be the case for a lot of users.
I'm definitely planning to do further work on optimization, and in particular I want to look at how feasible it is to get the browser to pre-decode images and prepare textures so that there isn't jank later on (if it can do so without sucking up tons of memory). That's still high priority. I've been doing a lot more work on the webclient as of late, so that's still up there. Still I think expecting a system that has too little memory and a relatively slow processor to perform at a high level is a bit unrealistic. And comparing to Flash games is still often a case of comparing apples and oranges--a very great deal depends on how those games were designed, and they're using completely different display code. However I think this distinction will continue to disappear as browsers continue to evolve their HTML5 support and improve JavaScript performance, and of course I'll continue to work to push the webclient as fast as it can go. | |
Lummox JR wrote:
Your testing is basically giving you a worst-case scenario that won't be the case for a lot of users. Yeah, that's what I'm hoping. I'm worried that a good chunk of our users will have low-end machines, since the people who play web games are usually more casual gamers. So far however we've only had performance complaints from one of our testers though, and most have been playing at a higher frame rate with client FPS. Still, we want it to play well, and it's a bit worrying how many people do only have 2 cores or 4GB ram: http://store.steampowered.com/hwsurvey It's hard to tell at the moment regardless. We'll know more once we start to publicly test, like I've said before. Either way the reassurance is appreciated. | |