Свежие комментарии

Та же девочка оставила в истории поиска запрос "ледовое побоище для детей".
Я порадовался, хорошо хоть не "для взрослых".

Тут средняя дочь (скоро 11) спросила у жены "мама, а был ли УЖЕ Ленин, когда ты родилась".

Не надо переоценивать людей, это я вот помню что съезд был, да и то, в каком году вряд-ли вспомню вот навскидку.

В idle полезнее префетч просто сделать. В один поток и не парясь о статистике.

Ну вот смотри - мы договорились до того, что мы считаем статистику реальной работы юзера и адапативно подстраиваемся. Идея, в принципе, нормальная. Можно, к примеру, просто вариабельно менять число потоков +-1 и, если достигается улучшение, менять среднее. Вопрос в скорости этих изменений, но опять же можно решить (ну и идея то - хорошая!)

Но если при этом читать без кэширования - это наказать юзера.

Ну тем более - и API по цене (или формальным характеристикам накопителя) не спасет.

Нужны "классы накопителей" (достаточно 3-4) и возможность назначить их на тома. Не автоматом.

У меня есть Class 10, который деградирует на чтении в два потока не на десятичный порядок, но близко к тому. При этом, да, формально он свои 10 мегабайт НА ЗАПИСЬ даёт.
Эта мерка, она же для тепличных условий внутри камеры. Ничего про многопоточное чтение там нет, как я понимаю.

Можно же UUID карты запоминать? Или он только у полноценных USB устройств есть?
Тест всё равно можно тихонечко сделать. Начинать число читающих тредов инкрементить и смотреть на характер деградации общей пропускной способности. Я наивно полагаю, что на медленных носителях оно до четырёх дойти успеет от силы. На дешёвых флешках всё становится ясно на двух потоках, по моему опыту.
Но, вероятно, многое придётся переписать. :)

Ну и вдогонку. Как вы понимаете, писать ничего нельзя в таком тесте. Флеш-носители, еле живые, вот это вот все.

Можно попытаться их потестить. :)
Не факт, конечно, что имеется хороший кросс-платформенный способ, но продвинутым юзверям можно дать крутилку числа i/o потоков и рекомендации по расчёту её параметров из данных, выплюнутых умным скриптом, пускающим консольную утилитку замера io performance.
Сам то я в силу профдеформации всегда sqlio для таких целей пользовался, но наверняка же хватает и других.

[q]DVall, мне кстати помогает клик по панели windows, а потом опять клик по приложению, т.е. мне перезапускать ничего не приходится, может и вам поможет.[/q]
Это понятно, имелось ввиду что все последующие нажатия так работают пока не перезапустишь. ESC клик по новой...
А так да, клик по другой программе клик по FRV помогает.

Просто добавлю — у меня Win 7, тема классичная, всякие анимации и т.п. отключены, этот баг с потерей фокуса при переходе в фуллскрин тоже проскакивает, и не только в FRV, сходу еще могу сказать что с VLC тоже самое.

DVall, мне кстати помогает клик по панели windows, а потом опять клик по приложению, т.е. мне перезапускать ничего не приходится, может и вам поможет.

Все анимации по максимуму выключены, как-бы двухэтапность только первый раз.
Когда приложение становится активным.
Оутпост, SysTrayX закрыл всё равно осталось,
Classic Shell и TrueLaunchBar как-то сносить несруки....
Как бы меня эта "двухкомпонентность" не напрягает.
Хочется только понять почему вдруг при переключении в фулскрин не уходит виндовая панель.

Есть некретичный баг который у меня вылез пару раз.
Но как его однозначно выловить на повторяемость я незнаю.
Win 7 64, 16 гб., FastRawViewer-1.1.0.628-x64-OpenGL, NVIDIA 970
Берём и играемся с новыми кнопками - убрать фильмстрип, правые панели, полноэкранный режим.
Визуально переключение в олноэкранный режим происходит как-бы в два этапа.
Сначала распахивается всё но остаётся виндовая панель, потом выезжает сатусная линия и панель уходит первый раз.
Потом вроде всё одномоментно.
Так вот на каом-то этапе статусная линия перестаёт появляться и остаётся висеть виндовая панель.
Лечится только открытием FastRawViewer по новой.
Закономерности не уловил....

Мне для полного счастья в FastRawViewer не хватает синхронного показа нескольких файлов.
Прошлый раз мне было сказано что нужно полностью переписать код.
А если пойти другим путём?
Реализовать это, типа как доп. плугин.
1 файл, работаем по старому, несколько файлов зовём плугин, и показываем в другом окне.
Позволит пилить отдельно - основной модуль и этот.
Такой режима как правило необходим для оценки распределения глубины резкости, где он лучше лёг.
И Функционально он может быть победнее чем основной модуль.
Там в принципе необходимо - синхронное перемещение по полю кадра, синхронное зуммирование, [b]пикинг[/b] и ряд операций с файлами - скопировать, переместить, удалить.
Не надо переписывать основной модуль, а со временем может они и сольются, а может так и останется.