Top.Mail.Ru
Мастера DELPHI, Delphi programming community Титульная страница Поиск, карта сайта Написать письмо 
| Новости | Поиск | FAQ | Статьи | Книги | Новости VCL |
| Форумы ЧАТ | Орешник | KOL и MCK |
Форумы -» Основная («Начинающим»)/ Базы / WinAPI / Компоненты / Сети / Media / Игры / Corba и COM / KOL / FreePascal / .Net / Прочее / RSDN.ORG

« предыдущая ветвь | форум | следующая ветвь »

Что скажете... [Delphi, Windows]


Страницы:   1 2 3 4 5 6 7 8 9 10 ... 18 19

ElectriC ©   (2007-07-05 19:10:00) 

Написал прогу на 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-ядерном зарегенная. На атлоне, соответственно, - нет.


Страницы:   1 2 3 4 5 6 7 8 9 10 ... 18 19

Наверх

Титульная страница Поиск, карта сайта Написать письмо