Animations applied pixel offsets improperly.
BYOND Version:507
Operating System:Windows 7 Home Premium 64-bit
Web Browser:Firefox 31.0
Applies to:Webclient
Status: Resolved (507.1249)

This issue has been resolved.
Descriptive Problem Summary:
animate() performs very poorly in the webclient, and has a very very large effect on the framerate.

Additionally, it doesn't seem to play nice with pixel offsets.

Screenshot from dream seeker (smooth at 30fps):
Screenshot from webclient (very choppy, <0.5 fps):

Numbered Steps to Reproduce Problem:
Create an object. Maybe create multiple objects. Give them a pixel offset. animate() them. Observe the framerate.

Code Snippet (if applicable) to Reproduce Problem:
//This is code from the game depicted in the screenshots above.
P.pixel_x = px
P.pixel_y = py
P.icon = trailIcon
animate(P, alpha = 255, time = 0, loop = 0)
animate(alpha = 0, time = 2, loop = 0)

Expected Results:
Pixel offsets are applied consistently, and are unaffected by the animate() calls.
Framerate maintains consistent.

Actual Results:
animate() appears to affect the pixel offsets, despite not receiving new parameters for them in the function call.

framerate drops significantly.

Does the problem occur:
Every time? Or how often?
Every time
In other games?
I have tested this in two games so far.
In other user accounts?
Seems irrelevant.
On other computers?

When does the problem NOT occur?
Don't know.

Did the problem NOT occur in any earlier versions? If so, what was the last version that worked? (Visit to download old versions for testing.)
Not applicable.

Perhaps work the pixel offsets into the animate(), to resolve the pixel offsets getting messed up.

Framerate is still negatively impacted, regardless.
Although I'm almost certain this is a server-side issue, I suggest trying on Chrome (if you are using Firefox as reported) on the off chance that you are using WebGL in one and not the other. I think they should both be supporting it though. There is a significant performance difference and our stuff just tries to use WebGL if it can.

[Edit] There appears to be a hardware-acceleration setting in Firefox-- make sure that's on. We should report this information.
Here is a screenshot of it in Chrome:

Framerate is still very bad.
can you confirm you are running webgl? I'm sure there is a setting for it. It's probably a server-side issue though. We'll test that out tomorrow. Any source or link you can provide would help if that source by itself doesn't do it (or maybe you can make a little demo).
I'm using Chrome and I'm having the same issue.
atom.transform also doesn't work right with pixel offsets in the webclient. I've made sure that webGL is enabled on my browsers.

I'm not experiencing the framerate problems or pixel offset problems in games that don't use transform or animate, like Casual Quest.
Left side is in DS, right side is in Webclient, both logged into the same server. They should look the same...
After removing animate() from the game I have been posting screenshots of, none of the pixel offset problems showed up and the framerate of the game was high and the game ran smoothly.
I know pixel offsets have always been my bane when working with animations, so something must be off there. I'll see what I can figure out.

I can't really explain the significant drop in framerate you're seeing, though; that's troubling. The code responsible for handling the animation ought to be relatively quick. It does create new Appearances, but that shouldn't be slowing anything down significantly, and they get cached. I'll have to see what's going on with that and if there's something that can be much improved.
Lummox JR resolved issue with message:
Animations applied pixel offsets improperly.
I've resolved the offset issue, but the slowdown I have not been able to observe reliably. Running a profile on an animation-heavy world did not show appreciable time spent in those functions. I might need something more concrete to test, but there will be some framerate changes in the next build anyway and I found a few things to improve performance-wise, so the results may be different in the next build. However if severe slowdown on animation persists, please post a new report for it.