FastRawViewer 1.1 (RC2)
lexa - 24/Апр/2015 13:57
Удивительное дело, но серьезных и воспроизводимых багов нам в FRV 1.1-RC1 не нашли, да и вообще почти никто не пишет.
Поэтому в RC2 изменения минимальны:
- Обновлено руководство, идущее в комплекте поставки
- Переведена на английский страничка What's new
- Добавлена поддержка двух камер (Olympus SH-2 и TG-4), общее количество поддержаных камер теперь over 800 (а именно 801 :)
- Еще в паре мест обновлена LibRaw, еще чуть лучше работает с битыми файлами.
Ссылки для скачивания 1.1-RC2
(здесь были ссылки для скачивания) Версия 1.1 выпущена, качайте с официального сайта
Заметили какую-то гадость - пишите. У нас (авторов) - взгляд давно замылился, мы используем программу так как сами привыкли, скажем вот в меню я вообще давно не заглядывал, можем чего-то не замечать месяцами.
Comments
Кстати, а вот
Кстати, а вот
WARN: [24-04 16:03:00.637] QWindowsWindow::setGeometry: Attempt to set a size (334x132) violating the constraints(220x266 - 524287x26600) on window QWidgetWindow/'Window_FilmstripWindow'.
[24-04 16:03:00.700] Started: 1
WARN: [24-04 16:03:00.789] QWindowsWindow::setGeometry: Attempt to set a size (334x93) violating the constraints(124x103 - 524287x524287) on window QWidgetWindow/'Window_FoldersWindow'.
как-то связано с запоминанием размеров Folders и Filmstrip?
С запоминанием - нет, не
С запоминанием - нет, не связано.
Эти окна стартуют пустые - и хотят поставить себе некие (маленькие) размеры сами. При этом, там минимальная ширина для folders и минимальная высота для filmstrip - ограничена.
А запоминаются (при выходе) - восстанавливаются (при запуске, но позже чем эти сообщения) - реальные размеры.
Серьезных нет но на первом
Серьезных нет но на первом старте (Win7 64 + OpenGL) крахануло. В не бета стврой версии была открыта папка с запоротыми raw файлами, не знаю сказалось ли это как то или нет. Вторичный запуск пошел нормально и воспроизвести я не смог, поэтому и не писал.
Невоспроизводимое, увы,
Невоспроизводимое, увы, невозможно чинить.
Crash - сохраняйте дампы пожалуйста (не закрывая окошка с сообщением о падении, в Task Manager, по правой кнопке "create dump file")
Ок сделаю если упадет еще раз
Ок сделаю если упадет еще раз. Сейчас попытался открыть директорию с массивным количеством равов (штук 800), просмотр сильно замедлился пока генерировались превью - буквально жмем на фотке в filmstrip и ждем секунд 5. Все на внутреннем SATA диске, нормальный просмотр равок обычно молниеносный. Настройки кэшэй все - по умолчанию. Как все превью сгенерировались то стало нормально работать.
Кодаки?
Кодаки?
Да они - - у меня других нет
Да они - - у меня других нет :)
Эта конкретно директория была с файлами ProBack с кучей кадров для панорамок (поэтому много)
Вообще, "все превью" не
Вообще, "все превью" не генерируются. Генерируется видимое + (по умолчанию) 30 штук вперед.
Но мне не удалось на файлах с SLR/c (800 штук положил на SATA-диск, 3Tb-барракуда) заставить тормозить.
Нет ли случайно кого-то еще, кто дерется за этот же диск?
Да нет. Что интересно - я
Да нет. Что интересно - я пытался пробегать по ленте и в конце директория показывало ? как превью а ближе к началу все превьюхи показывались нормально. Чем долше работало тем больше показывалось превьюх и меньше ?. Пока потом последние пару отработали и все стало бегать быстро.
Странно - попробую еще (свалю кучу файлов в какие то директории и потренируюсь попозже) .
Что я на эту тему хочу
Что я на эту тему хочу сказать
1) Превьюшки строятся в N потоков (где N - число ядер CPU, считая гипертрединг). Регулировки не предусмотрено - во всех моих тестах, втч на дисках подключенных через USB enclosure - производительность не было смысла ограничивать. Понятно, что на HDD может быть драка за диск, но вроде бы она в пределах разумного.
2) Проверил на отдельном SATA: превьюшки для SLR/c строятся даже быстрее, чем вынимаются здоровые JPEG-и из олимпусовских ORF. Так, на глазок, примерно 50 превьюшек в секунду (я растянул окно filmstrip на весь второй монитор, туда влезают аж 160 превью 100x66, вот эти 160 строятся за ~3 сек).
3) Если у тебя это происходит существенно медленнее, хочется понять что именно тормозит, процессор или диск. Это можно узнать, к примеру, по performance monitor-у виндовому, если он показывает в районе 100% disk active time - значит диск. CPU - ну опять же по загрузке ядер там же.
4) Если превьюшки не нужны, нажимаешь F6, окошко прячется - и декодирования превью более не происходит. Если не нужны фолдеры и мониторинг сменных носителей, то F7 и перезапуск программы (мониторинг начинается по первому открытию folders).
То есть я конечно избаловался с SSD (у меня 4 штуки в десктопе), быстрыми массивами и т.п., но в принципе тестирую даже по сети по wifi (300Mbit) и даже так оно приемлемо (безобразно, конечно, относительно нормальной техники, но долгих ожиданий нет).
Попробовал и кеширование
Попробовал и кеширование уменьшил и директории с разными файлами NEF и DCR попробовал и повыходил из всех программулин которые только могли этот диск использовать (включая антивирус - хотя там стоит опция не сканировать диск этот). Все равно медленно - NЕF чуть быстрее, DCR точно существенно медленнее. А тест такой - открваю папку с кучей равов, выбираю первый из ленты ()обычно показывается почти сразу). Скроллирую ленту в самый конец и выбираю рав один из последних - жду секунд 5-10 пока появится. Диск в это время что то читает судя по звукам - через какое то время (пару минут) перестает и все работает с нормальной скоростью
Так а с точки зрения
Так а с точки зрения Performance Monitor - кто виноват (загружен на 100%), диск или процессор?
Вообще, для такого паттерна доступа (сразу мотанули в конец) - глубину префетча превьюшек (Prefs - Performance - Thumbnail cache) надо уменьшать до нуля.
Еще вдогонку.
Еще вдогонку.
Возможно, на каких-то файловых системах (FAT?) чем дальше файл от начала каталога - тем дольше открывается. Оно примерно так у мака на SMB, но вообще конечно в 21-м веке принято кэшировать каталоги....
Тогда вот да, на больших каталогах будут тормоза.
Ок буду тестировать с
Ок буду тестировать с Performance Monitor - файловая система extFAT (у меня она с Мак осью шарится через бут)
Ну так что ж из вас клещами
Ну так что ж из вас клещами то тянуть приходится! exFAT, HDD, большой каталог.
Вот взял ноутбучный диск, форматнул в макоси в exFAT, включил в USB3-enclosure, налил в один каталог 2000 файлов. Размонтировал (кэши сбросить). Сунул обратно.
Ну таки да. Тормозит. Resource Monitor кажет 100% highest disk time даже без просмотра raw, только на построении превьюшек.
Рекомендаций, на выбор, три:
- или увеличить размер кэша превьюшек (они хранятся 4 байта на пиксель, нежатые, т.е. стандартные 200x133 - 100kb на превьюшку) и глубину префетча до максимальной (там 100, могу пару тысяч поставить в максимум). И, открывая каталог, один раз потерпеть, пока оно все прочтет. Оно закэшируется, один раз на каталог, дальше будет легче.
- или уменьшить величину Thumbnail prefetch depth, наоборот, до нуля. Она тогда будет декодировать только то, что видно в окне filmstrip (+1 с каждой стороны).
- ну или убрать окно с превью совсем и жить по старому.
Кроме того, на медленном носителе (а single HDD - медленный!) стоит количество raw decode threads уменьшать. Где-то до 2-3. Не меньше 2. Тогда префетчи не будут драться за диск.
Поигрался. Нулевой префетч
Поигрался. Нулевой префетч (только видимое на экране) + 2 raw decode thread работают плавно.
А вообще - пора привыкать, что single HDD или гигабитная сеть - это (в 2015-м году) медленный носитель. Оптимизировать под него стандартные настройки мы уже не будем, нет смысла.
Работает спасибо. Только в
Работает спасибо. Только в ленте превьюшки почему то не всегда отображаются. Но не тормозит зато.
Одиночный HDD - все очень просто, мне надо каталоги шарить между Мак осью и виндами, а заводить для этих целей хардверный RAID немного накладно. Вот и работаю. Пока особо нигде не тормозило.
Я тоже вот увидел не
Я тоже вот увидел не-отображение, буду разбираться.
Лечится нажатием гайки (gear) на панели превьюшек и там Refresh, но непорядок.
Кроме того, по всей видимости для таких медленных носителей параллельные декодеры тоже надо зажимать, не на все ядра запускать, а на меньшее количество.
Для "медленных" с одним HDD
Для "медленных" с одним HDD думаю надо зажимать. Как мне кажется для многих кто покупает себе скажем iMac для обработки фоток со встроенным диском и не парится с RAID (иногда даже не зная что это) это будет довольно частая ситуация. Я могу ошибаться конечно...
Я вот, к сожалению, не умею
Я вот, к сожалению, не умею еще программно отличить SSD от HDD, надо разбираться и с этим.
А кто покупает аймак с HDD, а не (хотя бы) с fusion drive - будет страдать.
Ну iMac это к примеру. На PC
Ну iMac это к примеру. На PC все еще хуже - особенно если не собирать самому. К примеру можно держать кучу фотографий за много лет на большом разделе который на SSD не влезает итп.
Свою проблему я понял спасибо, надо чего то быстрее.
В принципе подкачка и построение превью длительное не раздражают, раздражает что все это блокировало показ самих равок - выбирая что то из ленты даже без превью еще появившегося надо сильно долго ждать (в изначальном варианте с ненулевым префетчем). Превьюхи при этом начинали показываться быстрее всего пару секунд, а основного изображения приходится ждать долго. Инстинктивно ожидается как раз обратное - превьюхи в ленте на второй план, показ выбранного рава из ленты на первый. В предыдущих версиях FRV без превьюх на тех же самых директориях все летает (на установках по умолчанию со всеми потоками) даже при очень быстром листании взад вперед.
Я таки тестировал на HDD, но
Я таки тестировал на HDD, но он у меня сформатирован NTFS, там на больших каталогах все гораздо веселее. exFAT - да, все довольно печально выглядит.
В новом FRV стало хуже, потому что "со всеми потоками" старый FRV реально при листании с устоявшейся скоростью - префетчит по 1-2 (все потоки работают только при открытии файла или позиционировании в случайное место). А новый - префетчит превьюшки во все ядра (считая и виртуальные) - на моих экспериментах с NTFS это работало весело и я не стал делать ограничений по декодерам thumbnails.
И, да, несколько потоков чтения на HDD - убивают перформанс очень сильно. Головка дрыгается, а толку нету.
Но, как я уже где-то выше написал, если панель Filmstrip закрыть, то все будет как раньше, в закрытую панель превьюшки не декодируются.
Попробую переконвертить ФС на
Попробую переконвертить ФС на NTFS у меня вроде парагоновские драйвера теперь есть в мак оси. Просто кроме exFAT ничего лучше в голову не приходило года три назад когда я все это устанавливал чтобы работало с Мака и виндов.
Да я доведу работу с
Да я доведу работу с медленным диском в USB3-читалке до приемлемой.
Чудес не будет, потому что ограничивается все диском, но придавить чтение превьюшек, чтобы они основной функциональности не мешали - всяко можно.
Проблема уходит если в
Проблема уходит если в настройках включить Prefetch thumbnails for preceding images
Соврал - не помогает...
Соврал - не помогает...
Это смотря в какую сторону вы
Это смотря в какую сторону вы мотаете ленту.
То есть вот смотрите мой комментарий от 12:59, это виндовая драка за файл-локи, я уже вот починил, осталось сделать так, чтобы один файл (допустим он битый и там превьюшка 0x0 таки) много раз не онанировало.
>>Только в ленте превьюшки
>>Только в ленте превьюшки почему то не всегда отображаются
О как я люблю такие баги, которые на concurrency:
1) под виндой файлы открываются в exclusive mode (и, скажем, для std::filebuf(), который используются - я не знаю как отменить блокировки, смешно).
2) Мы отменили префетч, поэтому когда мы мотаем filmstrip - у нас оно не префетченое и вот будет читаться прямо сейчас.
UPD: или мы не включили "префетч назад" а по filmstrip идем в обратную сторону.
3) Дальше мы наудачу ткнем в еще не прочитанную иконку - и этот же файл будет читаться в другом месте (thumbnail cache - сильно отдельный от отстального FRV)
4) Шансы что они вдвоем подерутся - на медленном носителе достаточно велики.
Они и дерутся.
В результате из файла достается thumbnail размером 0x0, который и кэшируется в thubmbnail cache.
Вот не стал сильно париться: эти которые 0x0 просто кладутся в retry queue и будут префетчены повторно, через пару секунд, по таймеру.
Спасибо - это будет работать
Спасибо - это будет работать нормально
Ну и надо на mmap()
Ну и надо на mmap() переходить конечно везде. Это прогрессивно и правильно.
Записал в отдельный TODO по техническому долгу, летом надо бы его сделать.
Пишу повыше к началу треда,
Пишу повыше к началу треда, чтобы другим читателям было легче найти. Попробуйте версию отсюда: http://updates.fastrawviewer.com/data/110rc3/
Настройки:
Для HDD ставить в 1-3 (чем больше - тем больший будет приоритет у построителя превьюшек относительно остального).
Для SSD: в 2x CPU core count (больше нет смысла, внутри программы больше 2x core не поставится). На SSD дает чудесный эффект: превьюшки строятся быстрее, чем я мотаю мелкие превью 100x66 в большом окне (в котором ~160 превьюшек).
Можно уменьшать, но при одном потоке можно оставить как есть, оно зачитает в один поток вперед свои 30 штук, не мешая остальному.
Для плавного листания (пробелом) на HDD надо ставить в 2-3, иначе будет рывками. Если типичный паттерн поведения "на файл все-таки смотрим", то можно ставить (оставить) побольше чтобы оно в фоне насасывало побольше.
Разное
Следует понимать такие два момента
Соответственно, если хочется пролистать 2-3-4 файла (и в планах дальше листать вперед) - это быстрее делать пробелом, а не тыканьем мышом в filmstrip.
Попробовал спасибо. На exFAT
Попробовал спасибо. На exFAT с префетчем превьюх все равно тормозит сильно, я его в 0 оставил - так нормально. Сейчас конвертирую ФС в NTFS, в ней погоняю.
А перевозьмите оттуда же
А перевозьмите оттуда же (http://updates.fastrawviewer.com/data/110rc3/) 627-й билд.
Я ему еще оптимизма оторвал: если оно всегда префетчило +1 row (потому что когда light table, это нужно)/а юзерские настройки шли вдобавок к/, то теперь в режиме filmstrip оно +1 file.
Или вот RC4: http://blog.lexa
Или вот RC4: http://blog.lexa.ru/2015/04/26/fastrawviewer_11_rc4.html
Добавлена кнопка Filmstrip Off/On (если он по большей части не нужен, так и выключить!)
Спасибо - инсталлирую
Спасибо - инсталлирую
Нужны, нужны настройки
Нужны, нужны настройки префетча per drive (в режиме указания типа, "Fast SSD", "Single fragmented HDD with exFAT").
Но не в этой версии, потому что вот threads префетчеров пускаются на старте программы и их число на рантайме не регулируется. Записал в кондуит (может заодно автомат сделаем, программно отличить SSD вроде можно, вот с массивами хуже).
Автомат - тема хорошая
Можно попытаться их потестить. :)
Не факт, конечно, что имеется хороший кросс-платформенный способ, но продвинутым юзверям можно дать крутилку числа i/o потоков и рекомендации по расчёту её параметров из данных, выплюнутых умным скриптом, пускающим консольную утилитку замера io performance.
Сам то я в силу профдеформации всегда sqlio для таких целей пользовался, но наверняка же хватает и других.
Толку то с тестов. Вот
Толку то с тестов. Вот вставили новую карточку из фотика, хотят две фотки глянуть. И тут - тест.
Можно же UUID карты
Можно же UUID карты запоминать? Или он только у полноценных USB устройств есть?
Тест всё равно можно тихонечко сделать. Начинать число читающих тредов инкрементить и смотреть на характер деградации общей пропускной способности. Я наивно полагаю, что на медленных носителях оно до четырёх дойти успеет от силы. На дешёвых флешках всё становится ясно на двух потоках, по моему опыту.
Но, вероятно, многое придётся переписать. :)
Ну то что нужно многое
Ну то что нужно многое переписать для динамики - это факт. Сейчас там в разных местах - где снаружи раскладывает в первую idle thread, где сами threads по освобождению от работы - хватают следующую из очереди (очередей, на самом деле, но не суть).
Рассуждения же общего плана, увы, не работают. Вот, казалось бы, одиночный HDD. Азбука - фигачить в один поток, потому что seek-и убивают. На практике оптимальными оказываются 2-3, потому что оно же не только читает, но и распаковывает, процессорные ядра надо чем-то загружать.
Массив, который по latency еще хуже одиночного диска (по идее) - 8 потоков (по числу ядер), потому что читается то быстро.
Статистику можно приделывать, конечно, но боюсь я этого искусственного разума, бунт машин, вот это вот все.
Там же еще и повторяемости нет, даже на одном носителе. ОС кэширует (и, теоретически, и префетчит). То есть вот новый запуск FRV, пошли в частично закэшированный каталог, все стремительно, ручку вывернули на максимум, кэш кончился - и труба. Для тестов на одиночном диске - я его постоянно выдергиваю и обратно сую, потому что иначе все отлично после первого прохода.
Ну, есть, в конце концов, и
Ну, есть, в конце концов, и возможность некэшируемо читать. Но, видимо, это всё не сильно кросс-платформенно получится.:)
Ну вот смотри - мы
Ну вот смотри - мы договорились до того, что мы считаем статистику реальной работы юзера и адапативно подстраиваемся. Идея, в принципе, нормальная. Можно, к примеру, просто вариабельно менять число потоков +-1 и, если достигается улучшение, менять среднее. Вопрос в скорости этих изменений, но опять же можно решить (ну и идея то - хорошая!)
Но если при этом читать без кэширования - это наказать юзера.
В рабочем процессе нельзя,
В рабочем процессе нельзя, конечно. Тихонечко, тихонечко в idle.
В idle полезнее префетч
В idle полезнее префетч просто сделать. В один поток и не парясь о статистике.
Ну и вдогонку. Как вы
Ну и вдогонку. Как вы понимаете, писать ничего нельзя в таком тесте. Флеш-носители, еле живые, вот это вот все.
Читать, конечно же.
Читать, конечно же.
Флеши, да, с ними всё ясно. Правильная эвристика для removeable drive малых размеров - ОДИН поток. Дещёвые такие все, по моему.
Хм. А есть API для
Хм. А есть API для определения цены?
Потому что вот даже Class 6 (тормозной) в макбучном ридере (USB3, скорее всего, но не вдавался) хорошо работает в 4 потока.
Чтобы сейчас покупать Class 6 - нужно быть непонятно кем.
У меня есть Class 10, который
У меня есть Class 10, который деградирует на чтении в два потока не на десятичный порядок, но близко к тому. При этом, да, формально он свои 10 мегабайт НА ЗАПИСЬ даёт.
Эта мерка, она же для тепличных условий внутри камеры. Ничего про многопоточное чтение там нет, как я понимаю.
Ну тем более - и API по цене
Ну тем более - и API по цене (или формальным характеристикам накопителя) не спасет.
Нужны "классы накопителей" (достаточно 3-4) и возможность назначить их на тома. Не автоматом.
Хотелки
Я конечно понимаю, что есть горячие клавиши для сокрытия зон(филмстрип и ....)
Но хочется треугольничек на бордюре для сокрытия раскрытия, чтоб одной рукой всё делать, и хоткеев не запоминать ;)
"для сокрытия раскрытия" я
"для сокрытия раскрытия" я спросонья не уверен что понял. Превратить панель из "окна" в заголовок? Зачем вам заголовок?
То есть да, все (лайтрум, к примеру) приучили к такому интерфейсу, но мне он кажется вынужденным - у них так много в боковых панелях, что раскрытое - не лезет. У нас - даже на ноутбучном экране пока еще лезет.
Перестанет лезть - сделаем, конечно. Но не так, как в лайтруме, конечно же. Скажем, если уж свернуть (но не убирать) EXIF, то на заголовке должно остаться EXIF Summary (экспозиционные параметры), ну и со всеми панелями где это осмысленно - аналогично.
[quote]То есть да, все
[quote]То есть да, все (лайтрум, к примеру) приучили к такому интерфейсу, но мне он кажется вынужденным - у них так много в боковых панелях, что раскрытое - не лезет. У нас - даже на ноутбучном экране пока еще лезет.[/quote]
Ну почему лезет.
Открылось окно, посмотрел пару кадров, видишь что дальше последовательно будешь смотреть, фильмстрип не нужен, скрываешь его - фотка увеличивается.
Смотришь дальше, понадобился фильмстрип нажал куда-то он вылез. И все действия крысой(одной рукой)
Конкретно с фильмстрипом,
Конкретно с фильмстрипом, расположенным внизу - как его прятать то, во что превращать? К нему и так приложены усилия, чтобы не было заголовка сверху, если фильмстрип горизонтальный, но дальше прятать некуда.
Для него придется или освоить стандартный хоткей или, к примеру, повесить на одну из кнопок мыши (если кнопок на мыши много и есть избыток.)
[q]Конкретно с фильмстрипом,
[q]Конкретно с фильмстрипом, расположенным внизу - как его прятать то, во что превращать?[/q]
А чем реализация в пресловутом лайтруме не нравится, бордюр в десяток пикселей треугольник, нажал на него, ушло, остался бордюр, нажал на него вышло ;)
[q]Для него придется или освоить стандартный хоткей[/q]
Да не проблема освоить, просто хочется часть операций выполнять не подключая вторую руку ;)
В пресловутом лайтруме для
В пресловутом лайтруме для фильмстрипа - нет такой реализации.
[q]В пресловутом лайтруме для
[q]В пресловутом лайтруме для фильмстрипа - нет такой реализации.[/q]
Как это нету.
Правда пишу по памяти для левой, правой и верхней областей точно есть, для нижней вроде тоже...
Ну вот текущий Lr6, режим
Ну вот текущий Lr6, режим Library. Фильмстрип - внизу, переместить вбок - нельзя, закрыть-открыть треугольником нельзя, можно вот размер поменять и все: https://www.dropbox.com/s/v6m754f9ggkf8ao/Screenshot%202015-04-25%2010.1...
UPD: пардон, увидел треугольник ВНИЗУ. Но он жрет столько места по высоте, что ТАК мы делать не будем точно. Учите один хоткей. F6
[q]переместить вбок - нельзя[
[q]переместить вбок - нельзя[/q]
А вот это не надо.
[q]закрыть-открыть треугольником нельзя[/q]
Дома посмотрю. (на памяти осталось вроде всё скрывал)
А в режиме девелоп?
Как тут правильно цитировать?
Как тут правильно цитировать?
Да и так видно - ну и
Да и так видно - ну и прекрасно.
[q]увидел треугольник ВНИЗУ.
[q]увидел треугольник ВНИЗУ. Но он жрет столько места по высоте, что ТАК мы делать не будем точно.[/q]
У меня сейчас нет программы перед глазами, а если треугольник посередине(ну или не посередине) статусной линии.
[q]Учите один хоткей. F6[/q]
Дело не в учёбе. Для использования хоткея необходимо задействовать вторую руку, или перенести руку от мыши на клавитуру. А если у меня работа настроена на использование мыши. Следующая предыдущая мышиные кнопки, зум - колесо...
Если на мыши есть лишние
Если на мыши есть лишние кнопки - назначить на них.
Если нет - крестик закроет, Menu - Panels - Filmstrip откроет.
Просто вот потеря высоты под треугольник (1% по ширине, а остальные 99% просто пустые) - на маленьких экранах недопустима.
Я предлагаю сделать маленькую
Я предлагаю сделать маленькую кнопку(с пиктограммой filmstrip) снизу посередине, которая появляется при поднесении мышки к нижней части экрана.
Посмотрим. Меня выезжающие
Посмотрим. Меня выезжающие панели бесят.
С другой стороны, вот есть уже иконки кликабельные в нижней строке, можно туда воткнуть.
(отвечаю тут, чтобы оба
(отвечаю тут, чтобы оба участника треда увидели ответ)
Сделал кнопку в статусбаре, рядом с включением/выключением всех панелей.
Удобно, кстати. Спасибо что настояли!
http://blog.lexa.ru/2015/04/26/fastrawviewer_11_rc4.html
[q]Если нет - крестик закроет
[q]Если нет - крестик закроет, Menu - Panels - Filmstrip откроет.[/q]
Не...
Свойство, или действия над объектом в разных местах....
Ценой места.
Ценой места.
Лайтрум на 15" макбуке (1400x900 эффективных) выглядит безобразно. Собственно картинка занимает четверть экрана по площади (померял). В том числе и за счет нижнего поля со стрелкой, совершенно бесполезного.
Еще кнопку можно разместить в
Еще кнопку можно разместить в углу, вот так:
https://dl.dropboxusercontent.com/u/17378315/frv_filmstrip.png
Так она будет расположена рядом с крестиком после закрытия, что неплохо.
Как вариант визуально
Как вариант визуально "оставлять" кусочек темной подложки:
https://dl.dropboxusercontent.com/u/17378315/frv_filmstrip_2.png
https://dl.dropboxusercontent.com/u/17378315/frv_filmstrip_3.png
[q]15" макбуке (1400x900
[q]15" макбуке (1400x900 эффективных)[/q]
Понятно что у всех мониторы разные, у меня 1900х1200 24
Вот и хочется...
А всё таки, если всунуть в строку состояния-управления, ведь там место есть или только у таких как я...
Да, вот в строку состояния -
Да, вот в строку состояния - наверное можно. Только Filmstrip, остальным много чести.