Открыл в Gwenview каталог с лоровскими пикчами (13287 изображений, вес 6,2 ГБ). Gwenview начал жрать 2 потока процессора и оперативку под генерацию миниатюр.
Потом оперативка кончилась и система зависла, т.к. свопа нет. я не стал ждать развязки и нажал резет.
В итоге Gwenview, полностью сгенерировав миниатюры, занял 9,5 ГБ оперативки.
Я не эксперт в разработке программ, но по-моему, так не должно быть.
Это баг конечно, посмотри в багтрекере у них, может ты не первый жалуешься
Я бы не назвал это багом. Всё-таки 13200 скриншотов, 6,1 ГБ. Это, скорее, изъян проектирования.
По-твоему, как можно решить эту проблему? Создавать миниатюры пониженного качества?
Ты мне для начала объясни, как 6 гигов фоток на диске могло создать 9 гигов миниатюр в ОЗУ… Ну да, на диске они сжаты, а в памяти наверное нет, но блять неужели мелкость миниатюр не компенсирует этот коэффициент? Получается, что миниатюра в памяти занимает больше полноценной фотки на диске?
Да, тоже хороший вопрос
На диске скомпрессированы, в ОЗУ/VRAM распакованные?
Много ты сожмёшь в файлах jpeg и png?
Так сравни размер в png/jpeg и в bmp/raw.
Ну из данных выше уже понятно, что миниатюры на диске 2 Гб, а в оперативной памяти 9, грубо говоря в 4 раза они распухают.
Всё равно такое потребление рамы это баг, возможно ещё не заведённый
Я не про разбухание в ОЗУ, я про сравнение форматов как таковых.
RAW/BMP это просто таблица цветов пикселей, его размер не зависит от сложности картинки, а только от размера и глубины цвета.
И белый шум, и заливка одним чистым цветом будет иметь одинаковые размеры, именно в таком виде в конце картинки и будут в ОЗУ.
именно поэтому их там быть и не должно
Именно в таком виде они и отображаются на монитор, ты не можешь избежать распаковки картинки.
Другое дело что как правильно тут заметили нет необходимости хранить в ОЗУ ВСЕ распакованные миниатюры.
Не поверишь, я сейчас как раз ебусь с похожей задачей на работе… Ну, идейно похожей. Много однотипны объектов занимают “дорогой” ресурс, надо уменьшить футпринт, при этом не потеряв в скорости
Решение всегда одно и то же. Не надо держать в памяти все 13000 миниатюр. Они ведь не нужны все сразу, а только те, что отображаются на экране – ну и наверное ещё парочка экранов вперёд и назад, для упреждения. Код gwenview и KDE я не знаю, я другой программист
Да, это явно в Gwenview что-то с алгоритмами намудили
Ну вот, значит в кэш он умеет, в каком-то виде… Уже нагенерил эти 13000 миниатюр и они где-то лежат у тебя на диске. Скорее всего, на диске они не 9 гигабайт занимают, но ты проверь :)
А зачем он весь этот кэш грузит в RAM для 13000 файлов… Как я уже говорил, надо багтрекер смотреть
Я так понимаю, вот миниатюры Gwenview