Investigate replacing `transform` with `transform3d` for supported browsers about react-virtualized HOT 15 CLOSED

Does Chrome have any way to measure GPU usage? The only potential downside is forcing each row to be handled as a GPU texture (or something like that). I'm not sure what the right pattern here is, but using transforms is probably the way to go, especially since we're only showing a constant number at one time anyway.

I've heard concerns from various browser devs about using too much GPU memory by overusing CSS properties that trigger GPU offloading, but I'm not really sure. What's the "scientific" way we can measure this?

I can see if there's anything in Firefox I can profile. I can't tell any difference in Firefox 46 with the APZ feature making things happen async.

from react-virtualized.

Does Chrome have any way to measure GPU usage?

I think the white bar inside of Chrome's Timeline view is GPU but I'm very inexperienced with that type of profiling. :)

It's good to hear that FF 46 is rocking both variants out. :)

from react-virtualized.

I found it: it's in the FPS overlay (???). devtools menu > more tools > rendering settings > show FPS meter. That meter shows the amount of GPU memory.

Observed results while scrolling down through the entire page:

Using top:

Without any overscan rows: 8-16 MB
With an overscan of 100: 8-25 MB

Using transform:

Without any overscan rows: 15-22MB
With an overscan of 100: 30-55MB

The question is if this is acceptable or not. I'm not really sure. But it seems like it could potentially use about twice as much memory on average (although this is all anecdotal, just watching the meter while scrolling).

I'm surprised the top works this well, honestly. I thought transforms would be clearly smoother, but maybe we should hold off on this until there's a clear reason to do it. Or wait until this lib gets used in more situations and other people complain about performance.

from react-virtualized.

I'm actually not sure if we have GPU memory in our devtools yet, but I'll check Firefox if we do.

from react-virtualized.

Bah. I've used that overlay before and forgotten that there was a GPU meter in there too. Nice! :)

Yeah. I'm okay to sit on this for a bit then and see if others have input. If the performance is at least improved from before (now that on-wheel is gone) then the need isn't as pressing.

I really appreciate all of the info and suggestions :)

from react-virtualized.

Thanks for all the work on this project!

There's a well-known post by Paul Irish about this: http://www.paulirish.com/2012/why-moving-elements-with-translate-is-better-than-posabs-topleft/ I think if you are animating complex objects, transform is better. But I think for the use case here, top is probably better, because there are many objects and they will likely be simpler.

Eventually, it would be easy to even make this configurable so users could choose whatever they want. I'm not sure we want to add yet another option though.

from react-virtualized.

I ended up making this change in version 5 because, anecdotally, it seemed like an improvement. I may revert the change (or more likely, as you say, make it configurable) if I get any reports of negative performance impact.

For now I'll close the issue. :)

from react-virtualized.

Actually I'll re-open this and repurpose for considering transform -> transform3d

from react-virtualized.

Performance is really bad. It would be cool if we will have ability to configure it.

from react-virtualized.

Performance is really bad.

Huh? Mind giving a little more context? My testing (in various browsers and devices) seems to suggest performance is quite good.

from react-virtualized.

Pinging @flosstik

from react-virtualized.

Sorry, but i don't have enough time for research. When i was update from version 4.0.9 to 5.1.0(and i was update another libs), i saw jerky scrolling. When i was reinstall all dependencies and update lib to 5.2.0, i saw smooth scrolling, but when i scrolled fast, i was saw white screen and after 3 or 5 second content was loaded.

i will try use overscanColumnsCount and overscanRowsCount, and i think it can help me.

I'm write postgresql viewer with electron. I'm have 1000 rows in one page, and can be infinity columns(in test 30).

I was switched from FixedDataTable (https://github.com/facebook/fixed-data-table). They also use transform for positioning, and they have problems (facebookarchive/fixed-data-table#49)

I think this information isn't helpful. When i will have time i will test it again, and will can give facts.

from react-virtualized.

Research is not necessary. More context than "Performance is really bad." is absolutely necessary if I'm going to do anything about what you're reporting.

For what it's worth, I think the discussion on #124 actually may actually be related to what @flosstik is reporting.

from react-virtualized.

Put another way: I don't think it's actually the transform change that's causing the problem you reported, but rather, the key change. However I'm not currently sure of a way to resolve this and there is ongoing discussion on #124 about it.

from react-virtualized.

@flosstik: You'll be happy to learn that version 5.2.3 replaces transform with left/top as you suggest. I'm going to go ahead and close this issue for now as that positioning seems to work the best in my testing when compared against translate and translate3d

from react-virtualized.