1489977 - Performance-Issue of HTML5-CardGame (Haxe-OpenFL, Canvas-Mode) causes Scroll-Blocking to fail

Status: RESOLVED INCOMPLETE

(Core :: JavaScript Engine, defect, P3)

Description

[yves.scherdin]

Attachment: SpielePalast_transitionOverview.jpg

User Agent: Mozilla/5.0 (Windows NT 6.3; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180830143136

Steps to reproduce:

This report is based on the ticket https://bugzilla.mozilla.org/show_bug.cgi?id=1480045

Here I give more info about performance issues I had with my card game, as it was asked for. For the Performance-profile please see also the original ticket.

----

Background info about the project:
It once was Flash (AS3) and we ported it to OpenFL (Haxe). And from there we target HTML5. And in HTML5 lots of performance problems appeared. We already handled lots of them. But not 
all. And performance in ported projects is somehow a known issue. So our optimizations are ongoing.

We are currently using Canvas-2d, not webGL, because it appears to have the overall best performance.

----

Setup:
- if necessary, reset your config-value "apz.content_response_timeout" to its default (for me it currently is 400)
- go to our page: https://www.solitaire-palast.de/online-solitaire-spielen.html?html5=1
- login with this debug account (mail: "[e-mail]"   password: "qweasd")
 - of course you can create your own account, too. (the email does not have to exist)
 - you can adjust the language if needed (see the flag symbol in the 1st popup)

---- 

There are certain moments when js needs more time to run, generally when a game scene or the lobby screen is loaded; or if the lobby list is scrolled.
To cause scrolling issues, just scroll heavily during these transitions, or whenever you think that the js execution time is longer than usual.

These are known:

1. At some points during loading (Not included in the profile)
2. Always when entering the lobby...
 a) from LogIn-Popup ("Account-Central-Popup")
 b) coming back from "Competition"-Screen (accessible from lower left button in lobby)
 c) coming back from "MiniSlots"-Screen (accessible from lower right button in lobby)  (Not included in the profile)
 d) coming back from a game (Not included in the profile)
3. When scrolling the list of game tables in the lobby
4. When entering a game table (Not included in the profile)

----

See the attached image to get an overview of the transitions where perf-problems occur.
Yellow Arrows indicate problematic transitions.
Black arrows are transitions without problems.


Actual results:

Only in Firefox these moments result in disfunction of the scroll-blocking like it is described in the original ticket.


Expected results:

Scroll block should work all the time.

Comment 1

[Matthew Gaudet (he/him) [:mgaudet]]

Thanks so much for opening this. I'm ni?ing myself to ensure I don't forget to come back to this, though I may not get a chance to look at this this week.

Comment 2

[yves.scherdin]

Okay. No problem.

Just one thought about Firefox's JS-Performance: I think overall it is fine. It is nearly as good as Chrome and a lot better than IE 11.

On the other hand: if the whole reason is the way how this APZ-Controller works, why not add a way for the browser-js-developers to customize it on per-page-level, with some js-call? Because, maybe that APZ-behavior breaks other mousewheel-catching code for other devs, too? I don't know.

But if this is not possible or desirable, then there is of course no other way than optimizing the game's performance, which we are also currently working on.

Comment 3

[Matthew Gaudet (he/him) [:mgaudet]]

ni?ing Kats, as I don't know enough to answer the question in Comment #2

Comment 4

[Botond Ballo [:botond]]

(In reply to yves.scherdin from comment #2)
> On the other hand: if the whole reason is the way how this APZ-Controller
> works, why not add a way for the browser-js-developers to customize it on
> per-page-level, with some js-call? Because, maybe that APZ-behavior breaks
> other mousewheel-catching code for other devs, too? I don't know.

We purposely didn't create a way for web developers to opt out of the 400 ms timeout for preventDefault decisions, because it's an intervention for the benefit of the user. In the (far more common) case where the ultimate answer is defaultPrevented=false, i.e. "go ahead and scroll", waiting an unbounded amount of time before scrolling on pages with slow JS code was a very bad user experience.

> But if this is not possible or desirable, then there is of course no other
> way than optimizing the game's performance, which we are also currently
> working on.

There are other ways to prevent scrolling than using preventDefault.

  * If you always want to prevent scrolling, you could make the scrollable 
    element overflow:hidden, or just restructure the page so the element
    doesn't have an overflow area at all.

  * If you sometimes want to prevent scrolling and sometimes not, you could
    still make the element overflow:hidden, and have your scroll event 
    handler call scrollTo() in the cases where you want to scroll.

Have you considered these options?

Comment 5

[Matthew Gaudet (he/him) [:mgaudet]]

Just a note: 

A profile taken with today's nightly: https://perfht.ml/2N05hc9 shows nowhere near as much time spent in |bool js::jit::GetNativeDataProperty| compared to previous profiles seen (this is during loading, where I can reproduce the scroll-block failure).

Comment 6

[yves.scherdin]

@Botond Ballo:
I see. Thanks for the explanation. I will discuss the alternative options for blocking scrolling with my colleagues.

@Matthew Gaudet:
We are currently preparing lots of instance pools in the beginning during loading time. This will change later on.
However, the most unwanted moment for the scolling-problem is in the lobby when fastly scrolling the list and a list-scrolling gets interpreted as page-scrolling instead.