Анимированное изображение в формате GIF на x86 занимает 360 МБ ОЗУ, на Apple Silicon — почему-то 35.51 ГБ со свопом

[v1000]

владельцы Mac с M1 жаловались на быстрый износ новых SSD

немного напомнило историю про быстрый износ флешки, которая стояла в мультимедийных системах машин, потому что вместо запоминания уровня громкости во время выключения устройства, записывалось каждое изменение громкости. и в итоге за пять лет флешка изнашивалась в ноль. как раз после гарантии.

[daggert]

Там ему присвоили номер FB9112835 и пообещали разобраться с таким расходом памяти.

В следующем обновлении GIF на маке будет deprecated?

[Lirick]

Просто добавят платное включение поддержки GIF.

[DGG]

Или лучше: исправят, но на x86 версии, чтобы там тоже отжирало 100500ГБ памяти, а то непорядок

[tbl]

Уберут возможность посмотреть (в том числе и сторонними утилитами), сколько памяти отожрано: "Пользователям это не важно"

[denisshabr]

Какого хрена несчастная gif даже 360Мб занимает? Там ведь простейший формат, созданный как раз для того, чтобы в реальном времени раскодировать и показывать кадр, ничего не кэшируя, и это не жрало памяти даже на первых пентиумах. Разработчики вообще обленились и перестали считать память?

[johnfound]

Это память после декомпресии в 32bpp в редакторе. Как раз около:

400px240px4byte*730frames = 267MB

Ну и по мелочи там служебная информация в редакторе и т.д. до 360МБ

[nerudo]

Страшно представить, сколько тогда должен занимать в видеоредакторе двухчасовой фильм в HD.

[johnfound]

Видеоредакторы это очень специализированное ПО. Там используют всякие ухищрения чтобы понизить использование памяти. Но все равно, жрут память они очень и очень много.

[datacompboy]

Потому им и нужны быстрые диски, и raw кадры.

[nidalee]

В видеоредакторах нет такой битности цвета. Производителям хватает 12 в основном. Потребителям — 8-10, причем сжатых inter-frame. Кроме того, никто не кеширует целиком фильм в память: видео — большие файлы, которым нужны линейные чтения. С ними и жесткие диски прекрасно справляются, в кеш ложатся только окрестности вашей позиции на таймлайне как правило. Проблемы возникают только при перемотке и использовании кодеков, не предназначенных для монтажа.

[JekaKey]

Занимает не gif, а программа в которой этот gif редактируют.

[denisshabr]

Да пофигу, делали криворугие индусы, которые просто не подумали, что будет gif больше 30 кадров. Раскодировать кадр gif занимает долю миллисекунды, это не h264/h265, который опирается на 100 предыдущих кадр (и то который научились быстро seek-ать в видеоредакторах).

[maxzhurkin]

А GIF разве не опирается на ВСЕ предыдущие кадры?

[johnfound]

В исходном виде да. А когда развернули в редакторе по кадрам, увы уже нет.

[StSav012]

Это ерунда! Может, в том редакторе и так, но в GIMP, например, изображение всегда формируется из текущего кадра и всех предшествовавших. Кадры, знаете ли, с прозрачностью бывают.

[gsaw]

Там 730 кадров, 400x240px итого 70 080 000 пикселей. Если все открывалось в RGBA, умножить на 4, примерно под 280мб выходит. Конечно 360мб намного больше, но не так уж и сильно. «И так сойдет».

[wormball]

На некоторых (не будем показывать пальцем) развлекательных сайтах, не понимающих видеофайлы, столько порою занимают гифы даже в сжатом виде.

[namikiri]

Да почему «утилизирует» если «использует», ну что за калькированный перевод, ну доколе?

[maxzhurkin]

Поздно

[dorne]

Ранее в феврале владельцы Mac с M1 жаловались на быстрый износ новых SSD (расход ресурса SSD со скоростью записи 180Гб/час).

На самом деле, две проблемы могут быть связаны.
Открытая в браузере вкладка с ГИФкой вызывает утечку памяти, и заставляет систему очень активно использовать «файл подкачки», что, в свою очередь, вызывает перерасход ресурса SSD.