Warn users about Firefox performance about re-com HOT 25 CLOSED

Are your hboxes and vboxes significantly more deeply nested than the demo?

from re-com.

They are.

from re-com.

So no problem on Chrome? Or IE11? Just a problem on firefox?

If so, is it possible to create an example app which shows the problem, then we can report to Mozilla.

from re-com.

From the readme:

(Update: Firefox 38, due May 2015, fixes the performance problems caused by nested flexboxes.)

I'm testing with FF 39 and 41, so this isn't fixed (or not as much as it should).

Can't test on IE11 for now; don't have access to a Windows machine.

I'll try to find the cause before doing any report to Mozilla. Nested flexboxes might not be the problem, as this loads fine on FF http://codepen.io/anon/pen/dhzJE.

from re-com.

Not sure if you tried your app on the pre 38 version of Firefox but even some of the simpler pages in the re-com demo we almost unusable and the most complex one (the h-box page) was utter molasses.

So, Firefox has come a long way since then but I have certainly noticed it to be slower than Chrome but at least usable.

Just to confirm for Chrome, how would you describe the usability of your app in terms of speed?

from re-com.

On Chromium: lightning fast.

from re-com.

Thanks. If Mozilla still has a problem, I'm sure Mozilla would like to know. flexbox use is only going to increase.

from re-com.

We'll add a note about Firefox in the "Warning: re-com Might Not Be For You (just yet)" section, even if only temporary, and mention the versions of Firefox in question.

from re-com.

The next step here is to come up with a minimal example of it being slow on Firefox, but fast Chrome, and report it to the Firefox guys. Its a bug they will want to know about, because flexbox use will only increase.

Firefox easily handles the level of nesting in the demo app ... so we need a better example of this problem to attach to the bug report. @Frozenlock any chance you can put up a working, minimal example somewhere, then report it? They probably won't be interested in the code ... just the working app which exposes the problem in their algorithms.

from re-com.

There was a message about Firefox already there but I updated it somewhat.

from re-com.

@Frozenlock if you get around to reporting a bug to mozilla, would you mind putting a link to it in here. So we can track its progress.

from re-com.

Sorry, my turn to be a little overwhelmed. 😉

I'll try to isolate the problem and warn the concerned parties as soon as I can.

from re-com.

I did some other tests.

Turns out one doesn't even need to have many nested components.

The demo itself is already quite slow in Firefox.

If you insert a splitter in the re-com demo, you should immediately see how sluggish it is in FF.
(And this is on a powerful desktop... on a netbook this should be horrible.)

Chrome

Firefox

I still don't know what might be causing this. (JS or CSS)

from re-com.

Interesting. Can you raise a ticket with firefox? If you point out that Chrome handles it well, then I'm sure they'll be attentive. They were last time.

from re-com.

Sure. I'll try to open one tomorrow.

Should we insert the splitter into the demo? This way they could experience it first hand...

from re-com.

Sure. We need to give them a working example of the slowness. Do you already have that code? As a PR?

from re-com.

We're wrapping up the 0.6.0 release as we speak

from re-com.

Sorry, one more question: have you only ever see this issue when a splitter is involved? Perhaps it is something about the way we do splitters, rather than the flexbox stuff. Maybe.

from re-com.

You might be on something here...
It is indeed A LOT slower with splitters.

from re-com.

Just FYI, I tried the Splits layout examples on the latest Firefox v40.0 on OS X 10.10.4 and it doesn't seem to be noticably different than what it feels like on Chrome 44.

from re-com.

@ducky427 I don't see any difference with them either. You should try with non-empty children.

from re-com.

I'll try to come back to it. For now it seems the problem is still related to flexboxes (I can gain speed by removing them). The split seems to amplify the problem more than a simple h-box.

from re-com.

The "real time" nature of dragging a splitter is certainly going to expose any flexbox implementation problems - recalculating some nested arrangement every 16ms will put a lot of pressure on.

So there may well be nothing wrong with Splitters, they might just be the stressor which shows the flexbox algorithm's problem.

I'd still like to throw an issue the way of the firefox guys. I'm sure they'd be keen to know about any issues.

from re-com.

For what its worth, @Frozenlock, i converted the re-com demo to have a splitter as in your gif and I don't get the lag with FF40 on my laptop.

I can upload a gif of what I am seeing but I don't know how to create the animated gif. Any suggestions?

from re-com.

Is there any plan to include #57 ?
I was kinda waiting on a live example to ping the firefox guys.

from re-com.