Asciinema on jfrog.com causes very high memory consumption

For support with specific websites

Moderator: trava90

Forum rules
Please always mention the name/domain of the website in question in your topic title.
Please one website per topic thread (to help keep things organized). While behavior on different sites might at first glance seem similar, they are not necessarily caused by the same.

Please try to include any relevant output from the Toolkit Error Console or the Developer Tools Web Console using the following procedure:
  1. Clear any current output
  2. Navigate or refresh the page in question
  3. Copy and paste Errors or seemingly relevant Warnings into a single [ code ] block.
User avatar
mmouse
Apollo supporter
Apollo supporter
Posts: 34
Joined: 2019-02-13, 06:47

Asciinema on jfrog.com causes very high memory consumption

Unread post by mmouse » 2021-09-10, 07:44

Hello

this page

https://jfrog.com/blog/critical-vulnera ... smuggling/

at first displays normally on Palemoon 29.4.02 both on Firefox and on Windows.

However when scrolling down, one encounters under the 'Attack demonstration – ACL bypass' subtitle one piece of asciinema replaying some console entries.
When these few lines displays, the memory consumption shots up, bringing slugishness under Windows and sometimes a system message warning to close applications,(that's getting from 250 Mb to 3,3 Gb in a few seconds) and under Linux the browser crashes, sometimes getting the whole system with it (swap exhausted).

Under Firefox 92.0 the memory consumption does not rise significantly when playing the asciinema part.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35481
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Asciinema on jfrog.com causes very high memory consumption

Unread post by Moonchild » 2021-09-10, 15:17

It's a 2880x1440x1274f animated gif that is dynamically loaded, and therefore forces full decoding of the image frames to memory for display. Gif images should not be used as pseudo-video, especially not oversized like that; it does take a lot of memory to hold something like that (4.49 billion decoded pixels).

Not dynamically loading (i.e. going directly to https://jfrog.com/wp-content/uploads/20 ... 6_Demo.gif) allows the browser to use some mitigating measures by discarding frames as they are decoded, but when preloading it that can't reasonably be done.

There really isn't much that can be done about that in our current setup. The website should really not use gif images in that fashion. in fact, the 30 MB gif will happily compress into a 1.32 MB MP4, according to a quick check in an on-line conversion tool. See attach.

You can (likely) work around this by setting "image.decode-immediately.enabled" to "true" in about:config, but that will have a detrimental performance effect in all other (i.e. non-edge) cases.
Attachments
ezgif.com-gif-to-mp4.mp4
(1.32 MiB) Downloaded 9 times
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
mmouse
Apollo supporter
Apollo supporter
Posts: 34
Joined: 2019-02-13, 06:47

Re: Asciinema on jfrog.com causes very high memory consumption

Unread post by mmouse » 2021-09-11, 06:21

>> You can (likely) work around this by setting "image.decode-immediately.enabled" to "true" in about:config,

Sorry, the only thing that changes is that the crash (Linux) or system memory warning (Windows) occurs when the page is loaded and not only when the page is scrolled to the gif of doom.

From my tests, neither Chrome nor Firefox are attempting to load the whole file in memory. From what I guess from it's behaviour, Chrom(ium) is saving the file in cache and reading it according to the available memory; in the Windows system (a VM with only 3 Gb) it's keeping things low profile (task manager see less than 45 Mb total use) and on my Linux system (8 Gb Ram) it's consuming 700 Mb (it could be an artifact of how task manager vs htop) but video display is quite more sluggish under Chrome/windows than Chromium/Linux)

As of what should do web designers, if a permit demonstrating competence and wisdom was required to be one, the world would probably be a better place but Sir Berner Lee would not be a Sir because the Web would not exist, so if a relatively technical site like jfrog.com is clueless, there are certainly thousands of clueless sites like this in the world, so IMO it's a real problem that Palemoon is handling gif images this way.

BTW I was wrong to name this 'asciinema', it's a real web technique (asciinema.org) and afaict it use text, not images so it works quite normally with Palemoon.

Thanks for taking the time to explain this to me.

User avatar
Moonchild
Pale Moon guru
Pale Moon guru
Posts: 35481
Joined: 2011-08-28, 17:27
Location: Motala, SE
Contact:

Re: Asciinema on jfrog.com causes very high memory consumption

Unread post by Moonchild » 2021-09-11, 11:24

mmouse wrote:
2021-09-11, 06:21
Sorry, the only thing that changes is that the crash (Linux) or system memory warning (Windows) occurs when the page is loaded and not only when the page is scrolled to the gif of doom.
Well it does reduce memory consumption significantly on my system. It'll still take a few GB because of the sheer resolution and size of it and that simply can't be helped.
mmouse wrote:
2021-09-11, 06:21
neither Chrome nor Firefox are attempting to load the whole file in memory
The problem isn't loading. The problem is decoding. An animated GIF file is progressively encoded and you MUST have the previous frames to reconstruct the next frame
Also, we are neither Firefox nor Chrome.

As said though we can't really do much about it. 1440p animated gifs are a really, really bad idea.
"Sometimes, the best way to get what you want is to be a good person." -- Louis Rossmann
"Seek wisdom, not knowledge. Knowledge is of the past; wisdom is of the future." -- Native American proverb
"Linux makes everything difficult." -- Lyceus Anubite

User avatar
mmouse
Apollo supporter
Apollo supporter
Posts: 34
Joined: 2019-02-13, 06:47

Re: Asciinema on jfrog.com causes very high memory consumption

Unread post by mmouse » 2021-09-14, 08:17

>>An animated GIF file is progressively encoded and you MUST have the previous frames to reconstruct the next frame

gifsicle --colors=255 <Demo.gif >aa.gif
gifsicle --colors 256 --conserve-memory --careful --unoptimize <aa.gif >bb.gif
Using palemoon I have been able to open bb.gif and it displays like the original does (on Chrome or Firefox)
It's animated to it must be progressive ? Yes but it's not *compressed*. bb.gif is a 200 Mb file and that's the real problem I think.

I tried an assortement of open source tools on these 2 files (original and uncompressed) and they were all miserable failures because
they were trying to be a viewer, that is, allow display frame by frame and go backwards, things that are not possible without
loading the whole data in memory and overwhelming my limited system (I was able to use gifsicle to convert to uncompressed only on a 16 Gb ram system).

I then remembered that I have a *viewer* on my system, ffplayer (from ffrmpeg) and it's handling both files with ease, displaying both versions
quickly and efficiently, like Firefox or Chrome do.

So my conclusion is that handling huge gif files is difficult - but not impossible. Worth it for an understaffed project ? Well, no, obviously.
However I don't quite see why it should not be tracked an a possible enhancement if someone feel the itch.

vannilla
Moon Magic practitioner
Moon Magic practitioner
Posts: 2183
Joined: 2018-05-05, 13:29

Re: Asciinema on jfrog.com causes very high memory consumption

Unread post by vannilla » 2021-09-14, 09:18

The real issue is using GIFs at all.
Why using a GIF that is lazy-loaded only when the user scrolls to near it, when you can use a video that is never buffered until the user clicks play?
There's a significant waste of resources here, especially since downloading GIFs puts more of a burden on the server, so even the webmasters have something to lose by using GIFs.

Locked