LINUXTALKS.CO

И вот снова о UX линуксового софта

 , ,

L


0

1

Открыл в Gwenview каталог с лоровскими пикчами (13287 изображений, вес 6,2 ГБ). Gwenview начал жрать 2 потока процессора и оперативку под генерацию миниатюр.

Потом оперативка кончилась и система зависла, т.к. свопа нет. я не стал ждать развязки и нажал резет.

В итоге Gwenview, полностью сгенерировав миниатюры, занял 9,5 ГБ оперативки.

Я не эксперт в разработке программ, но по-моему, так не должно быть.

★★★★★

При повторном запуске каталог открывается быстрее, но если мгновенно промотать на несколько сотен файлов - опять тормоза, жор процессора и гигабайты оперативки.

alexferman    
★★★★★
Linux / Firefox

А у меня на гноме 3 не показываются превьюшки для фоток > 10 Мб (в файловом менеджере, nautilus)

Когда я гуглил проблему, этот лимит как-то не удалось по-быстрому изменить, типа глубоко зашит, в итоге я забил тогда, так как таких фоток было ну 10% от общего числа. Но всё же периодически попадаются

ThePlayerZero    
★★
Android / Chrome
Ответ на: комментарий от ThePlayerZero

Я бы не назвал это багом. Всё-таки 13200 скриншотов, 6,1 ГБ. Это, скорее, изъян проектирования.

По-твоему, как можно решить эту проблему? Создавать миниатюры пониженного качества?

alexferman    
★★★★★
Последнее исправление: alexferman (всего исправлений: 1)

Linux / Firefox
Ответ на: комментарий от ThePlayerZero

Да, такой ход бывает используют, чтобы не было как у Gwenview. В Dolphin тоже можно лимит размера файла включить.

В настройках Gwenview есть режим пониженного потребления ресурсов, но я не увидел разницы)

alexferman    
★★★★★
Последнее исправление: alexferman (всего исправлений: 1)

Linux / Firefox
Ответ на: комментарий от alexferman

Ты мне для начала объясни, как 6 гигов фоток на диске могло создать 9 гигов миниатюр в ОЗУ.. Ну да, на диске они сжаты, а в памяти наверное нет, но блять неужели мелкость миниатюр не компенсирует этот коэффициент? Получается, что миниатюра в памяти занимает больше полноценной фотки на диске?

ThePlayerZero    
★★
Android / Chrome
Ответ на: комментарий от alexferman

По-твоему, как можно решить эту проблему?

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

Решение всегда одно и то же. Не надо держать в памяти все 13000 миниатюр. Они ведь не нужны все сразу, а только те, что отображаются на экране – ну и наверное ещё парочка экранов вперёд и назад, для упреждения. Код gwenview и KDE я не знаю, я другой программист

ThePlayerZero    
★★
Android / Chrome
Ответ на: комментарий от alexferman

При повторном запуске каталог открывается быстрее

Ну вот, значит в кэш он умеет, в каком-то виде.. Уже нагенерил эти 13000 миниатюр и они где-то лежат у тебя на диске. Скорее всего, на диске они не 9 гигабайт занимают, но ты проверь :)

А зачем он весь этот кэш грузит в RAM для 13000 файлов.. Как я уже говорил, надо багтрекер смотреть

ThePlayerZero    
★★
Последнее исправление: ThePlayerZero (всего исправлений: 1)

Linux / Chrome
Ответ на: комментарий от ThePlayerZero

как 6 гигов фоток на диске могло создать 9 гигов миниатюр в ОЗУ..

На диске скомпрессированы, в ОЗУ/VRAM распакованные?

torvn77    
★★
Последнее исправление: torvn77 (всего исправлений: 1)

Android / Chrome
Ответ на: комментарий от torvn77

Ну из данных выше уже понятно, что миниатюры на диске 2 Гб, а в оперативной памяти 9, грубо говоря в 4 раза они распухают.

Всё равно такое потребление рамы это баг, возможно ещё не заведённый

ThePlayerZero    
★★
Android / Chrome
Ответ на: комментарий от ThePlayerZero

Я не про разбухание в ОЗУ, я про сравнение форматов как таковых.
RAW/BMP это просто таблица цветов пикселей, его размер не зависит от сложности картинки, а только от размера и глубины цвета.
И белый шум, и заливка одним чистым цветом будет иметь одинаковые размеры, именно в таком виде в конце картинки и будут в ОЗУ.

torvn77    
★★
Linux / Chrome
Ответ на: комментарий от torvn77

И белый шум, и заливка одним чистым цветом будет иметь одинаковые размеры, именно в таком виде в конце картинки и будут в ОЗУ.

именно поэтому их там быть и не должно

ThePlayerZero    
★★
Windows / Chrome
Ответ на: комментарий от ThePlayerZero

именно поэтому их там быть и не должно

Именно в таком виде они и отображаются на монитор, ты не можешь избежать распаковки картинки.
Другое дело что как правильно тут заметили нет необходимости хранить в ОЗУ ВСЕ распакованные миниатюры.

torvn77    
★★
Linux / Chrome

Я не эксперт в разработке программ, но по-моему, так не должно быть.

А это из той же оперы, про которую писал @crypt. Современные погромисты идиоты чуть более, чем все. Сначала дерадируют инструменты, которые создают сами программисты, а потом деградирует поколение программистов, которые использую деградировавшие инструменты. Чему тут удивляться?

Oberstserj    
★★★★★
Ubuntu / Firefox
Ответ на: комментарий от alexferman

запускает другой линуксовый софт

Лол, зацените разницу))

Т.е. проблема не в линуксовом софте, а в конкретном линуксовом софте от конкретных идиотов разрабов?

Oberstserj    
★★★★★
Ubuntu / Firefox