> Да, а сообщение об ошибке в инсталляторе с Атлона можно
> увидеть?

Exception c000001d at 8837b
Причем, та же и в XP и в Me.
Zoomer, сам по себе, в Windows Millenium на Атлоне вообще не запустился - система выдала ошибку, после нажатия 'закрыть' - снова и т.д.
Возможно, конечно, все ошибки на Атлоне из-за кривого железа, но на нем тот же Photoshop, например, работает без проблем. Это я к тому, что:
> Вот не пойму при чём там может быть Атлон вообще



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

Очень похоже, что это именно так.

На всякий случай:

1 комп.:
Intel Core 2 Duo / Vista x64 (XP, 98 на вирт. машине)

2-й:
AMD Athlon XP / Windows XP, Windows Millenium

показывает на команду paddq mm7, mm1.
Что за... поддержка MMX называется. Ладно у меня только 1 такая
команда, поправлю. Кстати, у вас не должны тогда грузиться гифы - вообще! Но это только в загрузчике gif'а, непонятно тогда,
что с открытием программы с директорией в командной строке :(

> Кстати, у вас не должны тогда грузиться гифы - вообще!
Точно, не грузятся.

> непонятно тогда,
> что с открытием программы с директорией в командной строке :(
Заметил такую вещь, если директория открывалась в зумере ранее, и зумер "запомнил" последний просмотренный файл, то с вероятностью близкой к 100% тумбы испортятся.

Но я надеюсь, не когда программа уже загружена, а именно при запуске с этой директорией, так?

Не могу пока обновлять на kolmck, сайт не доступен. Пока еще чего-нибудь поделаю.

А, нет, уже всё работает. Мне сейчас главное KOLGraphic обновить, чтобы с gif-ами не было проблем в mmx-оптимизированной версии на Атлонах.

> Но я надеюсь, не когда программа уже загружена, а именно
> при запуске с этой директорией, так?

Именно так.

Ну вот, заодно обновил и zoomer: 401O. Вот что я попробовать решил, пока в голову больше ничего не приходит: задержка 250 мс остаётся для случая директории в командной строки, но отсчёт начинается только после отрисовки окна просмотра, с картинкой или без. Т.е. моё предположение в томЮ что проблема в попытке тумбнайла получить ClientRect этого окошка слишком рано, из другого потока, что приводит к поломке всего потока. Не факт, конечно, но есть надежда, что поможет. Ну, и gif с инсталлятором на Атлонах, соответственно, должен работать.

А вот сейчас интересный момент: будет ли всё еще ломаться на 1ядерном Атлоне, если ломается на 2ядерной машине.

kolmck опять не работает, и даже не пигуется. Соответственно, доступ только к старому почтовому ящику.

Все, Тэдди сайт наладил, теперь все пашет. Обновил CxKolTiffJpg сразу же, а то битые tiff'ы вообще не читались, пусть хоть до первого сбоя читаются, как в других вьюверах.

Версию O можно не качать, уже проверили: то же. Надо делать версию с преподробным логом загрузки тумбочки, завтра займусь.

> битые tiff'ы вообще не читались, пусть хоть до первого сбоя
> читаются, как в других вьюверах.

Кстати битые png тоже не читаются.

Пришлите мне, небольшой только, сбойный png. А то руками устроить сбой я попробовал - сначала мусор напихал с помощью hexapad'а, потом вообще треть обррезал - все равно показывается (хотя и с мусором на хвосте). Не попадаются мне на и-нете png-файлы, обычно "хороший" сбой получается как раз при качке из сети, когда файл не докачивается. Так с тиффом было: скачал картинку с сайта хаббла, оказалась побитая, тогда и обнаружил проблему.

Сейчас выложил 401o, при бросании папки на ярлык программы будет строить лог Лучше сделать папку и 1, ну 2 картинок, чтобы лог был поменьше. thumb_load_log.txt, в папке зумера. Очень боюсь только, что опять получится "градусник, меняющий температуру воды", т.е. что наличие лога "исправит" пробему.

> Кстати битые png тоже не читаются.

Оказывается читаются. Просто я на полумеговом недокачанном png не дождался.
Очень медленно. На порядки медленнее др. просмотрщиков.

> 401o

Есть папка с одной картинкой (c:\tst1img\img.bmp).
Тумбнэйл сломался.
Лог загрузки:


+ Системное сообщение об ошибке в программе:
> ...
> Смещение исключения: 0000ee35
> ...

Смещение в данном случае бесполезно: где-то в глубине системным процедур, 40ee35.

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

Когда диспетчер задач вызывается, показывается два отдельных
графа загрузки процов, на Атлоне64 или один?

Единственное, что я могу подозревать, то либо чистую двухъядность, или
такой гипертрдинг, который ближе к двухядерности, чем к моей
гипертрединговости на интеле. Т.е. ошибка явно возникает (другого не
остается пока) из-за попытки обратиться к хранилищу тумбочек
одновременно на чтение по одному адресу, и на запись по другому.
Странно, однако, что не наступает восстановление нормальной ситуации.
Как будто "читатель", недовольный результатом, срочно шлет "писателю"
команду перечитать это дело, а тот в своем потоке начинает писать
новый тумб, а в это время читатель одновременно пытается прочитать, и
у них начинается ступор, быстро переходящий в стагнацию.

Я попробовал разделить маппинг файл хранилища, создав отдельное окно для
чтения и для записи. Это потребовало несколько времени на переделку, но
это лучше, чем делить доступ к хранилищу семафором. (Хранилище, это
временный файл ZOOxxxx.xxx в temp-диретктории, и объектная обвязка к
нему, такое решение я принял еще давно, когда тумбы сканировались
всегда все, и количество их могло быть таковым, что иногда требовался
гигабайт и больше. Сейчас, если > 100 картинок, тумбы грузятся лишь по
мере надобности, но механизм остался прежний).

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

--- Что касаемо медленного png, это потому, что пришлось задействовать свой kolpng, написанный исключительно на паскале, вместе с lzw-декодированием. Тот что в KOLGraphic лажается в слишкм простых ситуациях. Самое неприятное: зацикливается (лучше бы падал). Надо же проверять результат обращения к функции, а не надеяться, что всегда всё путём. Потом руки дойдут доберусь я и до png. Правда, больших png видеть не приходилось. Максимум - как скриншот экрана.

> Когда диспетчер задач вызывается, показывается два отдельных
> графа загрузки процов, на Атлоне64 или один?

Два. Только у меня не Атлон64, а Intel Core 2 Duo.

Положил версию 401p. Вообще изменил алгоритм хранилища тумбов, убрал вообще маппинг файл, не будет вообще оставаться файл ZOOxx.tmp в темповой дире. А для тумбов GlobalAllocom беру память по 16М блоками, и без засорения кучи распределяю. Сейчас, если оять облом, исключается возможная проблема маппинг-файлов, нестыковок между читателем и писателем и если оно опять падает на директории, то нужно опять делать лог, но уже на рисовальщике тумбов.

Так, сто не надо качать. Говорят, то же, 50/50. Пойду лог рисовальщика делать.

Положил Q, с подробным логом рисования. Мне бы нужен лог именно с Duo, лог от Атлона 64 мне тоже пришлют, надеюсь. Лог лучше упаковать раром, он жмется в 100 раз. Спасибо!

Вот такой облом: хоть я и сделал лог с накоплением его в памяти, и сбросом порции лога только после окончания процедуры на диск, сработал тем не менее эффект градусника - на Атлоне64. Есть только 3-секундная задержка перед началом показов тумбов в этом случае но все равботает нормуль, без красных кругов. Посмотрите, приз, на 2 Duo, и если там все такое же, то я оставлю лог, просто уберу его сбрасывание на диск, к этому моменту процедура отрисовки уже завершилась, и лог можно просто очистить. Только посмотрите, пожалуйста, 3 случая: маленькая папка (1-5 файлов), средняя (<100), и большая (200-2000, сколько наберётся). Последний случай отличается только тем, что грузятся не все тумбы сразу, а только те, что видны, остальные - как обычно, по мере надобности догружаются.