Problem with composite layers creation performance

[Jānis Taranda]

In my we app I have a lot of elements flying in and out of screen (using transforms). I noticed in FPS meter, when an element is out of the screen for some X pixels, the layer is destroyed (VRAM cleared). When

it fly's in back and reaches same point X, element is again layerized (VRAM grows) .

The problem is, that in the moment is layerized and pushed to VRAM, I got and 50-80 ms LAG and it's bad for smooth animating :(.

Is there any way (with CSS on JS) to archive that the layer is not destroyed when being out of screen?

Why know best, than chromium devs!

P.S -  don't suggest will-change, as this not stable on other browsers.

Best, Janis

[PhistucK]

On Mon, Oct 3, 2016 at 1:59 PM, Jānis Taranda <ja...@eptron.eu> wrote:

P.S -  don't suggest will-change, as this not stable on other browsers.

​Mmm does it ruin anything in other browsers?

Is your issue Chrome-specific?​

A 50 - 80 millisecond lag is very high. Sounds like a bug.

The less moving parts on the page, the shorter the lag is, right?

You can search crbug.com for an existing issue and star it. If you cannot find one, file a new issue using the "New issue" link on the same page.

Please, do not add a "+1" or "Me too" or "Confirmed" (or similar) comment. It just wastes the time of Chrome engineers and sends unnecessary e-mails to all of the people who starred the issue.

You can reply with a link to the found or created issue and might get triaged (and fixed) faster.

Thank you.

☆PhistucK

[Jānis Taranda]

I do not think it's a bug. It's just how it's is- when new layer is pushed to VRAM, it puts pressure on video rendered. I'm developing for weak hardware. 

When I code native OpenGL or WebGL, I cant control when the textures are pushed to VRAM, and it's mostly in loading phase.

Chrome has intelligence on it's own for compositing and decomposition layers, and when that happens at wrong time.... it's what I get.

So my question still the same.

[PhistucK]

You have not answered my three questions, actually.

Such a long lag still sounds like a bug. Chrome should be smart about creating layers or disposing them if layer creation takes such a long time.

will-change: transform; is the proper way to indicate that something will be changing (which translates to something like creating a layer or accelerating sometimes), however, I do not know whether it helps in the case of off-screen elements.

☆PhistucK

--

--
Chromium Discussion mailing list: chromium...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-discuss

---
You received this message because you are subscribed to the Google Groups "Chromium-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discuss+unsubscribe@chromium.org.

[Jānis Taranda]

​Mmm does it ruin anything in other browsers?

For now we are developing for chrome, no other browsers tested.

Is your issue Chrome-specific?​

I guess we can assume that :)

The less moving parts on the page, the shorter the lag is, right?

I have 3 parts, slide-in'g in to screen (with rotation effect) added. LAG is right at the moment when some part becomes visual (I can see VRAM growing at this point). If I set much slower transforms, I guess I miss the LAG, because of smaller movement intervals. But that's not always an option, to make IT SLOW :)

will-change: transform; is the proper way to indicate that something will be changing (which translates to something like creating a layer or accelerating sometimes), however, I do not know whether it helps in the case of off-screen elements.

Yes it does not help with off-screen elements :/

Such a long lag still sounds like a bug. Chrome should be smart about creating layers or disposing them if layer creation takes such a long time.

As we are developing for webOS2, what runs web-apps on older webkit, reporting a bug will not help at this moment. But I still might do that.

Tnx for you effort!!!

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

[PhistucK]

Oh, so you develop in Chrome for rendering later in WebKit (the two has diverged a lot in terms of compositing, if I understand correctly, which is probably the area that breaks your use case)?

That does not sounds like the optimal way to develop it... Does WebOS2 have an emulator? Did you reproduce the lag under a real WebOS2 installation?

I mean, of course, it would be great to have your website working across platforms, but if you develop for a very specific platform, I guess you want it to look great there first and should ask for advice on a WebOS2 group, since they can probably be more helpful than us.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discuss+unsubscribe@chromium.org.

[Jānis Taranda]

I develop, test on chrome & TV simultaneously (browser sync). LAG is on both. Just that on weekear gear (like WEBOS2 TV) it's much more noticeable. I can also reproduce on old laptop.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discu...@chromium.org.

[PhistucK]

Personally, I would have filed bugs at crbug.com as well as the issue tracking system of WebOS2.

A 50 - 80 millisecond lag is too long to be justified, in my opinion.

☆PhistucK

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-discuss+unsubscribe@chromium.org.