![]() |
| ||
|
|
Новости |
Поиск |
FAQ |
Статьи |
Книги |
Новости VCL
| | Форумы ЧАТ |
Орешник |
|
| |||
| |||
« предыдущая ветвь | форум | следующая ветвь »
Что скажете... [Delphi, Windows]
ElectriC © (2007-07-05 19:10:00)
Страницы: < 1 2 3 4 5 6 7 8 9 10 ... 18 19 >
Написал прогу на KOL(хотя и не первую), что скажете?
http://slil.ru/24597111/1736559902/Symbols_Image.rar
Vladimir Kladov (2007-09-07 12:58:00) [121]Положил версию 401p. Вообще изменил алгоритм хранилища тумбов, убрал вообще маппинг файл, не будет вообще оставаться файл ZOOxx.tmp в темповой дире. А для тумбов GlobalAllocom беру память по 16М блоками, и без засорения кучи распределяю. Сейчас, если оять облом, исключается возможная проблема маппинг-файлов, нестыковок между читателем и писателем и если оно опять падает на директории, то нужно опять делать лог, но уже на рисовальщике тумбов.
Дмитрий К (2007-09-06 23:39:00) [122]
> Когда диспетчер задач вызывается, показывается два отдельных
> графа загрузки процов, на Атлоне64 или один?
Два. Только у меня не Атлон64, а Intel Core 2 Duo.
Vladimir Kladov (2007-09-06 22:54:00) [123]Смещение в данном случае бесполезно: где-то в глубине системным процедур, 40ee35.
смотрю на лог и диву даюсь: загрузка-то прошла. Ни в какие бэды или
исключения не вошла процедура, все отработала, результат в хранилище
тумбочек записала и даже завершилась как положено.
Когда диспетчер задач вызывается, показывается два отдельных
графа загрузки процов, на Атлоне64 или один?
Единственное, что я могу подозревать, то либо чистую двухъядность, или
такой гипертрдинг, который ближе к двухядерности, чем к моей
гипертрединговости на интеле. Т.е. ошибка явно возникает (другого не
остается пока) из-за попытки обратиться к хранилищу тумбочек
одновременно на чтение по одному адресу, и на запись по другому.
Странно, однако, что не наступает восстановление нормальной ситуации.
Как будто "читатель", недовольный результатом, срочно шлет "писателю"
команду перечитать это дело, а тот в своем потоке начинает писать
новый тумб, а в это время читатель одновременно пытается прочитать, и
у них начинается ступор, быстро переходящий в стагнацию.
Я попробовал разделить маппинг файл хранилища, создав отдельное окно для
чтения и для записи. Это потребовало несколько времени на переделку, но
это лучше, чем делить доступ к хранилищу семафором. (Хранилище, это
временный файл ZOOxxxx.xxx в temp-диретктории, и объектная обвязка к
нему, такое решение я принял еще давно, когда тумбы сканировались
всегда все, и количество их могло быть таковым, что иногда требовался
гигабайт и больше. Сейчас, если > 100 картинок, тумбы грузятся лишь по
мере надобности, но механизм остался прежний).
В общем, положил версию P. Лог при загрузке с директорией в пути пока
остается, вычищать не стал - хотя пользы от него большой и нет.
--- Что касаемо медленного png, это потому, что пришлось задействовать свой kolpng, написанный исключительно на паскале, вместе с lzw-декодированием. Тот что в KOLGraphic лажается в слишкм простых ситуациях. Самое неприятное: зацикливается (лучше бы падал). Надо же проверять результат обращения к функции, а не надеяться, что всегда всё путём. Потом руки дойдут доберусь я и до png. Правда, больших png видеть не приходилось. Максимум - как скриншот экрана.
Дмитрий К (2007-09-06 20:14:00) [124]
> 401o
Есть папка с одной картинкой (c:\tst1img\img.bmp).
Тумбнэйл сломался.
Лог загрузки:
Enter1 3
Enter2 img.bmp
Enter3
Enter4
Enter7
Enter8
Strm 0
Enter9
Enter12
Enter13
Enter16
Bitmap1
Bitmap2
Bitmap3
Bitmap4
Bitmap5
Bitmap6
Final1
Final2
Final3
Final4
Final7
Final8
Final9
Final10
Final12
+ Системное сообщение об ошибке в программе:
> ...
> Смещение исключения: 0000ee35
> ...
Дмитрий К (2007-09-06 15:44:00) [125]
> Кстати битые png тоже не читаются.
Оказывается читаются. Просто я на полумеговом недокачанном png не дождался.
Очень медленно. На порядки медленнее др. просмотрщиков.
Vladimir Kladov (2007-09-06 11:12:00) [126]Пришлите мне, небольшой только, сбойный png. А то руками устроить сбой я попробовал - сначала мусор напихал с помощью hexapad'а, потом вообще треть обррезал - все равно показывается (хотя и с мусором на хвосте). Не попадаются мне на и-нете png-файлы, обычно "хороший" сбой получается как раз при качке из сети, когда файл не докачивается. Так с тиффом было: скачал картинку с сайта хаббла, оказалась побитая, тогда и обнаружил проблему.
Сейчас выложил 401o, при бросании папки на ярлык программы будет строить лог Лучше сделать папку и 1, ну 2 картинок, чтобы лог был поменьше. thumb_load_log.txt, в папке зумера. Очень боюсь только, что опять получится "градусник, меняющий температуру воды", т.е. что наличие лога "исправит" пробему.
Дмитрий К (2007-09-05 21:18:00) [127]
> битые tiff'ы вообще не читались, пусть хоть до первого сбоя
> читаются, как в других вьюверах.
Кстати битые png тоже не читаются.
Vladimir Kladov (2007-09-05 21:13:00) [128]Все, Тэдди сайт наладил, теперь все пашет. Обновил CxKolTiffJpg сразу же, а то битые tiff'ы вообще не читались, пусть хоть до первого сбоя читаются, как в других вьюверах.
Версию O можно не качать, уже проверили: то же. Надо делать версию с преподробным логом загрузки тумбочки, завтра займусь.
Vladimir Kladov (2007-09-05 17:16:00) [129]kolmck опять не работает, и даже не пигуется. Соответственно, доступ только к старому почтовому ящику.
Vladimir Kladov (2007-09-05 12:01:00) [130]Ну вот, заодно обновил и zoomer: 401O. Вот что я попробовать решил, пока в голову больше ничего не приходит: задержка 250 мс остаётся для случая директории в командной строки, но отсчёт начинается только после отрисовки окна просмотра, с картинкой или без. Т.е. моё предположение в томЮ что проблема в попытке тумбнайла получить ClientRect этого окошка слишком рано, из другого потока, что приводит к поломке всего потока. Не факт, конечно, но есть надежда, что поможет. Ну, и gif с инсталлятором на Атлонах, соответственно, должен работать.
А вот сейчас интересный момент: будет ли всё еще ломаться на 1ядерном Атлоне, если ломается на 2ядерной машине.
Дмитрий К (2007-09-05 11:59:00) [131]
> Но я надеюсь, не когда программа уже загружена, а именно
> при запуске с этой директорией, так?
Именно так.
Vladimir Kladov (2007-09-05 11:48:00) [132]А, нет, уже всё работает. Мне сейчас главное KOLGraphic обновить, чтобы с gif-ами не было проблем в mmx-оптимизированной версии на Атлонах.
Vladimir Kladov (2007-09-05 11:45:00) [133]Но я надеюсь, не когда программа уже загружена, а именно при запуске с этой директорией, так?
Не могу пока обновлять на kolmck, сайт не доступен. Пока еще чего-нибудь поделаю.
Дмитрий К (2007-09-04 19:53:00) [134]
> непонятно тогда,
> что с открытием программы с директорией в командной строке :(
Заметил такую вещь, если директория открывалась в зумере ранее, и зумер "запомнил" последний просмотренный файл, то с вероятностью близкой к 100% тумбы испортятся.
Дмитрий К (2007-09-04 19:48:00) [135]> Кстати, у вас не должны тогда грузиться гифы - вообще!
Точно, не грузятся.
Vladimir Kladov (2007-09-04 19:33:00) [136]показывает на команду paddq mm7, mm1.
Что за... поддержка MMX называется. Ладно у меня только 1 такая
команда, поправлю. Кстати, у вас не должны тогда грузиться гифы - вообще! Но это только в загрузчике gif'а, непонятно тогда,
что с открытием программы с директорией в командной строке :(
Дмитрий К (2007-09-04 18:49:00) [137]
> Да, а сообщение об ошибке в инсталляторе с Атлона можно
> увидеть?
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
homm (2007-09-04 16:21:00) [138]Чувствую себя человеком-невидимкой :(
Владимир, [234]
Vladimir Kladov (2007-09-04 16:02:00) [139]Т.е. без разницы. Вот не пойму при чём там может быть Атлон вообще, 2хядерность еще каким-то боком может влиять на порядок выполнения потоков хотя бы. Может все-таки дело в Висте (виртуальная машина под Вистой, думаю, все равно будет фактически работать по правилам хостовой оси и хостового железа: я знаю только один эмулятор ПЦ, который реально озволяет смоделировть чужое железо, например 486 или Пень-2, он именно эмулирует каждую машинную команду, а не запускает код блоками, до очередного системного обращения).
Да, а сообщение об ошибке в инсталляторе с Атлона можно увидеть? (а то я еще код не менял, адрес может быть полезен. Тем более что в инсталляторе нет защиты через исключения, там вообще практически нет защиты, и выполяется совсем отдельный кусок кода).
Дмитрий К (2007-09-04 14:08:00) [140]На 2-ядерном зарегенная. На атлоне, соответственно, - нет.