Icon Procedure Update in Feature Requests

ID:114729
 
Jun 19 2011, 6:09 am
Applies to:Dream Maker
Status: Open
Issue hasn't been assigned a status value.
It is well known through the community that the icon procedures are rather slow. Especially when you use a hefty amount of them at once.

I know that it is easier said than done, but is there any chance of them being sped up? Such an update would allow something like this to work fluidly.
#1 Jun 19 2011, 12:48 pm
upvote
#2 Jun 24 2011, 12:45 pm
I'm not quite sure what you're asking for here. The routines pretty much optimized as far as they can be, except for palette changes which is something I experimented with but wasn't able to get working quite right (nor did it seem to produce as huge an improvement as I would have hoped). Plus with client-side icon processing in place, the server contribution to icon operations has been greatly lessened.
#3 Jun 25 2011, 7:28 am
Games using icon operations are almost always a bad idea even in dedicated servers hosting BYOND games that i've played one was easily able to lag the whole server by changing hair color at the character creation screen.

I find it hard to believe this major failure of speed that can lag a dedicated server is the best BYOND can do. The dedicated server was a decently fast 4Ghz quad core processor with one core to BYOND, and 3 other cores basically doing nothing(since BYOND barely does anything on a seperate thread/core).

---Anyways since their so slow maybe BYOND can process each individual icon in a seperate thread/core(basically making a new thread to use to process each icon)

That might speed it up enough since they take so much cpu plus make a way to over-ride the new client-side icon processing it seems to be a failure at processing less icons now & individuals are getting lagged out very quickly in games that use the icon processing routines.

I could go up to 10 icon processes at a time before with it how it is now before someone lags out its about 3.

I am not sure how it's coded either but does it send info to every client how to do the icon processing change? seems pretty in-efficient to have every client in-game re-do the same process that could've been done once by the server then sent to people.
#4 Jun 25 2011, 10:18 am
How is it less efficient to send to every client info on how to process an icon than it is to burn through CPU and then send the actual icon to every client?

P.S. Weren't you banned for being stupid once already?
#5 Jun 26 2011, 5:33 am
How is it efficient for every client to do an operation that is so in-efficient that it takes so much cpu that you can only do like 5 per second(if it even takes that many) before the game will start to lag to hell & back.

As it was before at least a dedicated server could take the lag out of the game for these operations since they were fast enough, now people are lagging out of games instead.

This is a trade-off between the server's cpu usage, the network bandwidth & a players cpu usage.

You can't however do anything about a players computer sucking but you can get a higher quality server to host on so your game will run smoother.

It's already supposed 2 decide when 2 run on server or client already but that apparentally doesn't work because they can lag themselves on a game i host & nobody else by pressing buttons that do random icon operations.
#6 Jun 26 2011, 9:34 am
First of all, if your computer can't run five icon operations per second, then you shouldn't be playing games on that computer. I have a miniature laptop, 1.6 ghz processor and 1gb of RAM, and it runs Ultimate Jigsaw just fine. In fact, I programmed Ultimate Jigsaw on that laptop.

Per peice, Turn() is called 0-3 times and Blend() is called 3-5 times(). During the creation of the puzzles, Crop() and Scale() are also called once, and if outlines are on, DrawBox() is called around 400,000 times. Yet, even on my crappy little laptop, it can render the pieces in 10-20 seconds.

So I will testify here that icon operations are not inefficient and that it is your computer(s) that suck.

P.S. Sending a maximum of 256 bytes to a client to tell it how to perform an icon operation is a hell of a lot less than sending them a 256 kilobyte icon file.
#7 Jun 26 2011, 9:58 am
Icon procedures in and on themselves aren't really too slow, in that they usually complete in a few milliseconds on a decent machine. What is usually a little iffy is doing them a few thousand times in a tight loop and expecting that to be okay, given their standing cost.

The solutions for this sit on the programmer's end, and range from simple caching to a complete re-think of the logic they are applying.

I see two potential extensions in this area though, that could help:

IconBuffers - The notion here being that you can perform a number of operations on an icon in memory, then "flush" out a completed /icon that can be used and sent to clients. This really just allows for avoiding that RSC file interaction you seem to get when doing a series of operations on an icon. Saves a little disk-work, makes those kinds of scenarios a little bit quicker etc.

The other scenario is actually to do with somewhat more indirect stuff, like say ... accessing properties of an atom's icon without hitting RSC. For example F_Damage will try to use the target's visual width/height to align the damage text. Unfortunately this can almost be as costly as the icon merge we try to cache earlier, because of hitting RSC for the target's icon.
#8 Jun 26 2011, 1:50 pm
Stephen001 wrote:
The solutions for this sit on the programmer's end, and range from simple caching to a complete re-think of the logic they are applying.

I already cache the icons created. I am open for discussing better ways to optimize my system. But to be honest, without removing the quality produced, I cannot think of any method that would allow a less amount of calls for cast8k.
#9 Jun 26 2011, 8:58 pm
Well my computer is better than your laptop even per core, anyways i've only had trouble with operations mostly on the icon operation to modify the color of an icon such as for re-coloring hair.

Anyways obviously it will use less bandwidth to not send the icon but it will take the processing off the client(and make the client lag less) if it sends the icon instead, most people don't get lag due to a bad connection (unless the host just has really low upload speed), they get lag because of the servers cpu spiking high or their own.

Obviously it will use more server cpu for it processing it instead of the client(s) that can see it, it's already supposed 2 use the server I thought to do the icon procedures if the client is already taxed but apparentally doesn't work because some users are getting lagged out of games with lots of icon procedures being done(mainly the re-coloring i said)
#10 Jun 26 2011, 9:08 pm
Stephen001 wrote:
I see two potential extensions in this area though, that could help:
IconBuffers - The notion here being that you can perform a number of operations on an icon in memory, then "flush" out a completed /icon that can be used and sent to clients. This really just allows for avoiding that RSC file interaction you seem to get when doing a series of operations on an icon. Saves a little disk-work, makes those kinds of scenarios a little bit quicker etc.

This is actually what the /icon datum already does. Nothing is copied to the .rsc until it's necessary. This happens if the /icon is put into an atom or image's icon var, or if fcopy_rsc() is called. It also happens if the /icon sits around for a while without being refcounted out of existence, but needs to be unloaded from memory. (Only so many loaded icons are allowed to sit in server memory at any one time.)

The other scenario is actually to do with somewhat more indirect stuff, like say ... accessing properties of an atom's icon without hitting RSC. For example F_Damage will try to use the target's visual width/height to align the damage text. Unfortunately this can almost be as costly as the icon merge we try to cache earlier, because of hitting RSC for the target's icon.

The Width() and Height() routines now pull from an internal cache that's already used by the server for handling big icons.
#11 Jun 28 2011, 3:25 am
Cheers for that second bit. I suspect my users will still complain of "lag" from F_Damage, but you can't please them all.