123
-=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- (c) WidthPadding Industries 1987 0|287|0 -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=- -=+=-
Socoder -> Off Topic -> Quirky Monkey HTML

Mon, 07 Dec 2015, 02:04
therevillsgames
Chrome down the drain? Can you guys please test this: Linkage
Mon, 07 Dec 2015, 02:04
cyangames
The chrome update seems to have broken some basic CSS bits also, on version 47.0. something or other. Hopefully they'll patch it soon!

-=-=-
Web / Game Dev, occasionally finishes off coding games also!
Mon, 07 Dec 2015, 02:12
Jayenkai
Yeah, same issue. I gave it a go, late last night, then ended up staying awake, trying to come up with reasons it might be happening..
.. Couldn't think of anything obvious, except that the recolouring alone should be causing much more slowdown, except that Monkey tends to retain "The last colour"..

Perhaps, when the mouse is down, Chrome resets colour parameters so that hyperlinks and things behave in a certain manner...?
This would then cause Monkey to go "Oh, we're back to 0 colour?" and re-render the text image in standard white, then on the next frame you're asking it to draw in red again, and it has to re-render in red.

.. At a guess!

Any chance you could add a "If mousedown and mousex<32 and mousey<32, then toggle the color" thing? That way I can test it on the iPad, too.

-=-=-
''Load, Next List!''
Mon, 07 Dec 2015, 10:51
rockford
Tested in FF.

While the text is white I get a rough FPS of 56. When it's red I get 2FPS.
Mon, 07 Dec 2015, 12:26
steve_ancell
In FireFox it hovers between 56 and 60 FPS, it's between 5 and 6 FPS when red.

In Chrome I get 59 FPS, and between 27 and 29 FPS when red.
Mon, 07 Dec 2015, 12:51
Jayenkai
Just tried it with my controller-test engine, and have noticed exactly what it is you're on about. (I think because there's oodles of pixels flying about on mine, so you can see more clearly where the stutter is)

It's not a case of "Recoloured and Mouse", it's more specifically "Recoloured and Mouse Dragged Movement" as if the actual movement is what's causing the issue.
I feel like this might be something to do with Chrome trying to drag "The thing under the mouse", which would suggest it's specifically a Chrome issue.

-=-=-
''Load, Next List!''
Mon, 07 Dec 2015, 13:30
therevillsgames
Thanks all for testing it.

I think you are right Jay... and more specifically its a Windows Chrome issue as I tried the same version of Chrome on my Mac and I didnt see the slow down issue.

Now to recreate the issue with pure HTML5 and send it to the Chrome Dev guys to fix it!
Mon, 07 Dec 2015, 14:09
cyangames
FPS is 60 on white.

On Red, it drops to 3

Running on Firefox it doesn't seem to matter about the mouse dragging, just the change of colour.



On Chrome I Get 60 until I do anything with the mouse, it drops down to 3-5.

In Red on Chrome I get 20 down to 3-5.


Hope this helps out.

-=-=-
Web / Game Dev, occasionally finishes off coding games also!
Tue, 08 Dec 2015, 14:03
therevillsgames
I've submitted a bug report to the Chrome team after I managed to get a "pure" HTML5 example running:

https://code.google.com/p/chromium/issues/detail?id=567563

Hopefully they will fix it

Thanks for testing.
Tue, 08 Dec 2015, 14:33
Jayenkai
Kewly!
Will be interesting to see how long that takes to get looked at!!

-=-=-
''Load, Next List!''
Sat, 19 Dec 2015, 08:05
Jayenkai
This bug is pissing me off, today, as I try to get "Free Ball" positioning to work!!!

-=-=-
''Load, Next List!''
Mon, 04 Jan 2016, 14:28
therevillsgames
Apparently this has been fixed in the next build (M48):

Got a reply today regarding this Chrome bug:

https://code.google.com/p/chromium/issues/detail?id=567563

Thanks for the report. Looks like your test app is using timers instead of requestAnimationFrame() to schedule rendering. I'd suggest switching to rAF instead so the browser has a better idea of what you are trying to do.

That said, this particular bug has already been fixed in M48.
And its now marked as a duplicate linked to this bug:

https://code.google.com/p/chromium/issues/detail?id=570845

Maybe Mark should look at requestAnimationFrame in the future?
Mon, 04 Jan 2016, 15:11
Jayenkai
\o/yeay\o/
Thu, 03 Mar 2016, 00:37
therevillsgames
Chrome updated today for me... all fixed
Thu, 03 Mar 2016, 04:02
Jayenkai
\o/yeay\o/