Здравствуйте, Cyberax, Вы писали:
C>Я точно помню, что и в более ранних DirectX можно было рисовать через GDI. Но оно было криво до невозможности всё, так как в Win98 оно автоматически блокировало поверхность, что вызывало взятие WIN16MUTEX. Т.е. любой вызов чего-то, кроме GDI-функций был чреват жёстким зависанием из-за не-реэнтерабельности API.
Так не надо было рисовать в отображаемый в данный момент буфер и тем более в отображаемый GDI-буффер.
По классике жанра ускорителей надо было рисовать в задний буфер и делать его передним. ))
Там еще была смешная фишка.
Отображаемый GDI-буффер, такой прям страшный и ужасный, вокруг которого прям всё вертится в Win32 Apps, можно было получить как одну из банальных DD Surface, затем внаглую отобразить свою Surface вместо главной, при этом остальные приложухи как слепые котята будут продолжать тыкаться в "главную Surface", которая в данный момент совсем не отображается, ы-ы-ы. Потом надо постараться не забыть вернуть "главную GDI-поверхность" на место, а то надо будет перезагружать комп ввиду черного экрана (в 98-х виндах).
В такие минуты и приходило ощущение "власти" над техникой — верчу как хочу (ну и плюс ВУЗ не так давно закончил на тот момент). ))
Примерно такие же были ощущения, когда на С первый раз создал еще один менеджер кучи, помимо дефолтного. ))
C>Потому оно использовалось разве что для вывода текста.
Я его использовал для вывода видео, ApplicationSharing, графического редактора и т.д. и т.п.
Т.е. не только перегонял туда биты, но и пользовался ф-иями рисования как текста, так и значков.
Прекрасно оно всё работает, если хорошо понимаешь, что делаешь и почему именно так.
Здравствуйте, CreatorCray, Вы писали:
V>>А зачем стандартные? CC>А затем что 99.99% софта пользовалось стандартными.
Деза ))
Возьми любую приложуху того же офиса — там стандартные контролы будут только на каких-нить совсем ранних версиях и только в каких-нить тупых диалогов. Потом оно переехало на WTL и досвидан — все AX-контролы рисовались ручками. А потом вообще переехало на DXGI.
Далее. Возьми любой CAD — аналогично. Те вообще почти сразу на DirectDraw переехали. Это потом уже, в начале 2000-х остальные приложения стали тоже постепенно переезжать на DirectX, вслед за всякими графическими редакторами и CAD — те были первопроходцами. ))
N>>>До этого делать гуй поверх DirectDraw означало делать закат солнца вручную, рисуя все контролы самому. V>>Во-первых, не так уж и самому. Можно прямо через системные АПИ рисовать части контролов (DrawFrameControl), подавая как параметр HDC. CC>А смысл? Это тот же GDI, но часто ещё и медленнее.
Не медленней, чем стандартные контролы, бо они рисуются именно так.
А профит в том, что иногда можно обойтись лишь окном вернего уровня, получив windowless.
А для OpenGL или DirectX так и вариантов других нет.
V>>Т.е., в случае DirectDraw получаешь HDC у DirectDraw-поверхности, затем делаешь такие же точно вызовы для рисования CC>А нахрена тогда с DD surface заморачиваться вообще?
Чтобы не наблюдать процесс рисования пошагово на экране. ))
Re[24]: Что на самом деле произошло с Windows Vista
Здравствуйте, netch80, Вы писали:
N>В режиме альтернативной истории можно много чего обосновать. Но я считаю, что IA64 никакие вложения не помогли бы. Слишком уж оно шизанутое.
Оно клёвое как раз. Просто шикарное.
Не Эльбрус, конечно, но круче архитектуры x64 в бесконечное кол-во раз.
Смотришь, и глаз радуется. ))
И оно дешевле в пересчёте на транзистор при аналогичных объемах выпуска...
Просто партии небольшие выпускают...
N>Я про процессоры, а не OS.
Плевать всем на процессоры. Люди покупают железо для исполнения программ.
MS всё хорошо для Итаниумов сделала, другие основные игроки тоже.
И тут AMD обломала весь кайф )))
N>Да, мародёрство остатков Alpha замедлило это. Но не сильно, потому что тот факт, что вышел общий заказ на 64-битность, видели все неленивые.
Это понятно. Так же как было видно, как тщательно Интел+HP готовятся стать монополистами в области настольных x64-процов.
Там столько было шума, столько спеси и чувства собственной недосягаемости...
О чем они вообще думали? ))
Что все остальные будут ждать, пока их поведут на заклание.
В общем, одна маленькая, но гордая птичка... (далее по тексту)))
N>Ойвэй. С чем сравнивали-то? С P-IV? Ну да, тогда ещё можно было что-то выгадать. Но с нормальными исполнениями — сомневаюсь. А чем дальше, тем больше разрыв усиливался, и дело не просто во вложениях.
Просто во вложениях.
Разрыв-то усиливался не сам собой, а ровно тогда, когда под x64 выходило обновление архитектуры (а этих обновлений было СЛИШКОМ много у Интел и АМД после 2002-го), а под IA64 обновление так и не вышло... Вот тебе и отставание. Вот тебе и понятно, по какой причине.
N>В плане сохранения основных проблем x86 — я полностью согласен. Так бездарно прозевать все возможности улучшения ещё надо уметь. N>В плане выбора альтернатив — я согласен на условное принятие многих, но никак не IA64.
Тебе-то что? Всё-равно на плюсах пишешь.
Система команд пусть заботит разработчиков компиляторов и более никого.
N>Ну проблемы этого подхода давно известны. Что-то я пока не видел унификации SIMD на уровне байткода.
Здравствуйте, Ops, Вы писали:
V>>Чего? ))) V>>Это сколько вариантов в час можно перепробовать на холсте? Ops>Зачем перебор? Рисуй свои образы.
Ясно.
"Страшно далеки они были от народа"
(С) Герцен.
V>>Разумеется, это дизайнерская работа. Ops>Только большая часть работы на компе — это отнюдь не креатифф: бухгалтерия, документы, АСУ всякие. А рисование и музыка — это так, факультатив.
Нафига RDP для бухгалтерии?
Последний раз живую 1C 7.x видели лет 10-15 лет назад.
Всё, закончились эти времена. ))
Здравствуйте, vdimas, Вы писали:
V>Нафига RDP для бухгалтерии?
А что для бухгалтерии нужно? Web? Так это в соседний топик, где как лучше сделать CRM обсуждается, с бухгалтерией аналогично.
V>Последний раз живую 1C 7.x видели лет 10-15 лет назад.
Ты же программист, а не бухгалтер, и то, что 1C видел лет 10-15 лет ни о чем не говорит. Или в 1С 8.X все по другому?
V>Всё, закончились эти времена. ))
какие времена?
Здравствуйте, vdimas, Вы писали:
V>Нафига RDP для бухгалтерии? V>Последний раз живую 1C 7.x видели лет 10-15 лет назад. V>Всё, закончились эти времена. ))
Клиент 1С 8.3+ точно так же запускается на терминальных серверах, и делается это повсеместно в городе Москве.
Здравствуйте, vdimas, Вы писали:
V>Потом оно переехало на WTL и досвидан — все AX-контролы рисовались ручками.
Дык всё равно GDI снизу было.
V> А потом вообще переехало на DXGI. V>Далее. Возьми любой CAD — аналогично. Те вообще почти сразу на DirectDraw переехали.
Для рабочей области — да, но всякие тулбары и прочие диалоги на тот момент всё равно были HWND + HDC over HBITMAP
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
Здравствуйте, vdimas, Вы писали:
V>В отличие от тебя? — ес-но.
Да вот что то у тебя с каждым напомнинанием как оно там на самом деле работает меняются показания.
V>Осталось тебе узнать, в каком году появились эти "GDI Acceleration Extension"
Судя по докам в RDP 5.0 уже были, а это W2k. В 5.1 были расширены.
Но уже хорошо что ты наконец то через нехочу признал что этот функционал в RDP есть.
V> и насколько они использовались в случае double buffer drawing, — мы же с этого зацепились, верно?
Это надо делать VM с дохлым каналом, прогу с GDI double buffering и смотреть как оно будет себя вести.
Ну или какой нить Wireshark который бы умел расшифровывать пакеты и показывать что там внутри.
Опять таки может зависеть от того, как сервер с клиентом договорятся.
V>Дык, RDP долгие годы и был тем самым T.128, как они купили его не помню уже у кого.
Аж всю 4.0 версию, которая была по сути первой. Потом дорисовали extensions.
V>А с расшаренным экраном в Скайпе?
Скайп жутко тормозит по тому же каналу на ту же машину.
V>- отключал обои стола;
У меня ни на одной машине их никогда не было — чОрный экран наше всио. Всё равно я их никогда не вижу.
V>- отключал сглаживание шрифтов;
Всегда на всех машинах отключены и без RDP.
V>- отключал темы;
Аналогично, везде Classic.
Поэтому что через RDP что через другие — картинка такая же.
... << RSDN@Home 1.0.0 alpha 5 rev. 0>>
Забанили по IP, значит пора закрыть эту страницу.
Всем пока
CS>>Как происходит primitive rasterizing на тех bitmap DirectDraw ничего не знал (можно было руками, а можно было GDI или не приведи тя хоспидя GDI+ какой использовать).
V>GCI+ — вообще не по теме. Это юзверская либа поверх GDI. А GDI — это драйверная технология. V>GDI так же имел возможность размещать битмапы в видеопамяти. V>В общем, ты сейчас вообще переврал всё что можно. )) V>Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места).
Слушай, прекращай уже фантазировать. Какой нахрен битмап в видеопамяти?
Для примера: для того чтобы TextOut работала и выводила ClearType ей нужен доступ к background pixels.
Ты предлагаешь сначала тот background закинуть в видео память потом оттуда его же читать и писать попиксельно?
Ну нет конечно.
CS>>ID2DRenderingTarget это не bitmap (как правило), а storage для GPU команд.
V>Опять мимо. V>ID2DRenderingTarget — это абстракция некоего интерфейса, наподобие HDC. V>Ну разве что АПИ оформлено не в процедурном стиле, а в стиле COM.
Да при чем там API?
Просто в Direct2D есть два типа ресурсов device-independent and device-dependent
device-dependent ресурсы как правило содержат handle на отображенные в GPU объекты — shaders, и пр.
Просто для управления временем жизни и версионностью этих ресурсов удобно использовать готовую идею IUnknown.
Re[25]: Что на самом деле произошло с Windows Vista
Здравствуйте, vdimas, Вы писали:
N>>В режиме альтернативной истории можно много чего обосновать. Но я считаю, что IA64 никакие вложения не помогли бы. Слишком уж оно шизанутое. V>Оно клёвое как раз. Просто шикарное. V>Не Эльбрус, конечно, но круче архитектуры x64 в бесконечное кол-во раз. V>Смотришь, и глаз радуется. ))
Чему именно радуется?
VLIW? Так неуместно же для такой области.
Структура команды? Так после блока разбора переменность длины и всякие префиксы/суффиксы уже пофиг. А вот необходимость связывать в бандлы — мешает.
128 регистров? Никто их столько не используют, 99.9% кода даже 32 не занимают.
Равнозначность регистров? Переименование решает эту проблему для большинства случаев.
Вынесенные предикаты? Проще было сделать на обычных регистрах, как у кучи разных RISC.
Тогда что?
V>И оно дешевле в пересчёте на транзистор при аналогичных объемах выпуска...
Дешевле что именно? Всё равно сейчас процентов 80 это кэш. Дальше блоки предсказаний и разбора кода — ну, вот на последнем можно кое-как сэкономить.
V>Просто партии небольшие выпускают... N>>Я про процессоры, а не OS. V>Плевать всем на процессоры. Люди покупают железо для исполнения программ. V>MS всё хорошо для Итаниумов сделала, другие основные игроки тоже. V>И тут AMD обломала весь кайф )))
Да-да. Просто они сделали то, что можно было очень легко сделать прямо сейчас и получить плавный переход. Причём воспользоваться минимальными усилиями в плане собственно компиляции (open64 вообще на коленке сляпан, а доработать gcc было легко, в отличие от полностью новой платформы), структуры ОС и т.п.
(Я говорю о том, что и при этом можно было целую пачку вещей улучшить, но они забили болт.)
N>>Да, мародёрство остатков Alpha замедлило это. Но не сильно, потому что тот факт, что вышел общий заказ на 64-битность, видели все неленивые. V>Это понятно. Так же как было видно, как тщательно Интел+HP готовятся стать монополистами в области настольных x64-процов. V>Там столько было шума, столько спеси и чувства собственной недосягаемости... V>О чем они вообще думали? )) V>Что все остальные будут ждать, пока их поведут на заклание.
V>В общем, одна маленькая, но гордая птичка... (далее по тексту)))
+100. Попытка тройного прыжка выше головы.
Причём, я уверен, если бы они подождали развития новых технологий ещё лет 20, а потом бы стали строить что-то подобное Itanium — у них бы получилось лучше. А так — попытка построения в 2000 на концепциях в лучшем случае начала 90-х. Если не раньше.
N>>Ойвэй. С чем сравнивали-то? С P-IV? Ну да, тогда ещё можно было что-то выгадать. Но с нормальными исполнениями — сомневаюсь. А чем дальше, тем больше разрыв усиливался, и дело не просто во вложениях. V>Просто во вложениях. V>Разрыв-то усиливался не сам собой, а ровно тогда, когда под x64 выходило обновление архитектуры (а этих обновлений было СЛИШКОМ много у Интел и АМД после 2002-го), а под IA64 обновление так и не вышло... Вот тебе и отставание. Вот тебе и понятно, по какой причине.
Ну ты вот веришь, что вложениями могло бы её поднять до чего-то сносного. Я — не верю. Причины тут прожужжались уже много раз.
Подобные революции можно делать тогда, когда об их необходимости жужжат "не только лишь все" (tm), и все чётко видят, что новое будет в плюс. Вот тогда толщина Intel могла бы сыграть на руку — или сделать самим, или купить. Покупка Altera — пример такого: о расширении CPU за счёт FPGA жужжали даже фантасты с гуманитарным образованием И, скорее всего, от этого будет какой-то реальный плюс.
А если бы они спокойно и плавно подошли к переходу на 64 бита по принципу "так, есть x86, выкидываем весь мусор, оставляем нужное", оставив совместимость по регистрам и основной логике команд — никакой AMD не потребовалось бы.
N>>В плане сохранения основных проблем x86 — я полностью согласен. Так бездарно прозевать все возможности улучшения ещё надо уметь. N>>В плане выбора альтернатив — я согласен на условное принятие многих, но никак не IA64. V>Тебе-то что? Всё-равно на плюсах пишешь. V>Система команд пусть заботит разработчиков компиляторов и более никого.
Разбирать полученное тоже важно, чтобы найти узкие места. А иногда и напрямую приходится в ассемблер идти. C/C++ некоторые вещи в принципе не умеют в своей концепции, ну и компиляторы не помогают.
N>>Ну проблемы этого подхода давно известны. Что-то я пока не видел унификации SIMD на уровне байткода. V>Здесь смотрел? V>https://dzone.com/articles/net-native-performance-and
Не подходит аж никак:
1. Там только .NET, а не кросс-платформенные подходы.
2. Оно само разбирает цикл уже на этапе JIT или native generation. На уровне IL это цикл.
Я бы скорее ожидал что-то в духе Agnerʼовского ForwardCom (где длина вектора, обработанного одной командой, в принципе не ограничена) — переложить это на конкретную ограниченную длину уже банально. Хотя и оно заточено под текущую схему концепций соотношения команды и кэша.
Здравствуйте, pagid, Вы писали:
V>>Нафига RDP для бухгалтерии? P>А что для бухгалтерии нужно? Web?
Какое-то у тебя дохлое воображение-то ))
А как же клиент-сервер?
А как же более мохнатый n-tier?
P>Так это в соседний топик, где как лучше сделать CRM обсуждается, с бухгалтерией аналогично.
Сказал человек, не разработавший ни одной бухгалтерской проги в жизни. ))
V>>Последний раз живую 1C 7.x видели лет 10-15 лет назад. P>Ты же программист, а не бухгалтер, и то, что 1C видел лет 10-15 лет ни о чем не говорит.
Я вижу 1С постоянно.
Но в сетевых применениях 7.x не вижу уже давно.
Речь в этом топике про RDP, он был популярен для 7-ки 1C когда-то, потому что БД у ней файловое.
P>Или в 1С 8.X все по другому?
Ты действительно не знал, или притворяешься?
8.x — клиент-сервер, ей не нужен RDP для комфортной работы.
V>>Всё, закончились эти времена. )) P>какие времена?
RDP для бухгалтерии.
Сейчас RDP имеет смысл только для обращения к мощным компам из дохлых.
Здравствуйте, CreatorCray, Вы писали:
V>>Потом оно переехало на WTL и досвидан — все AX-контролы рисовались ручками. CC>Дык всё равно GDI снизу было.
Только double-buffer теперь один на окно, и всё окно получается — один битмап.
V>> А потом вообще переехало на DXGI. V>>Далее. Возьми любой CAD — аналогично. Те вообще почти сразу на DirectDraw переехали. CC>Для рабочей области — да,
Это 99% трафика
CC>но всякие тулбары и прочие диалоги на тот момент всё равно были HWND + HDC over HBITMAP
Это менее 1% трафика.
Изображения на тулбарах, считай, не изменяются.
А даже когда изменяются, то их разница — чуть ли не константа (подсветка какая-нить).
Здравствуйте, CreatorCray, Вы писали:
V>>В отличие от тебя? — ес-но. CC>Да вот что то у тебя с каждым напомнинанием как оно там на самом деле работает меняются показания.
Уже не знаешь что сказать...
V>>Осталось тебе узнать, в каком году появились эти "GDI Acceleration Extension" CC>Судя по докам в RDP 5.0 уже были, а это W2k. В 5.1 были расширены. CC>Но уже хорошо что ты наконец то через нехочу признал что этот функционал в RDP есть.
Я этого не отрицал, я сказал, что это практически не используется — и указал не раз причины, почему именно.
По крайней мере уж точно не используется так, как вы тут расписывали.
Понимаешь, ты не можешь спорить, пока не ответил на мои прошлые аргументы.
А я пытался тебя вернуть в реальность уже не раз — многие контролы после перерисовки НЕ изменяются.
И напоминал, что так происходит в более 90% случаев.
А ты настойчиво игноришь неудобные тебе весчи. ))
Так вот, нет никакой возможности определить при передаче команд GDI, будет нарисовано то же самое или не то же самое.
Так какой тогда смысл гнать эту прорисовку, если в 90% случаев можно не гнать?
Далее, включи просто немного воображение, как оно там вообще может на сервере происходить.
Представь, что ты пишешь такую прогу со стороны сервера. Т.е. "оно как-нибудь там само" (как ты тут расписывал свои влажные фантазии) — такое не прокатит, тебе, программисту, надо принимать решения. Для начала надо определиться — надо ли вообще эту область обновлять. ОК, через mirror driver ты знаешь изменённые области (прямоугольники/регионы), тебе их надо по какому-то алгоритму склеить/укрупнить (которые склеиваются).
Далее ты эти области должен разбить на небольшие участки по некоторому алгоритму и проверить по каждому участку — есть ли разница с предыдущим кадром. Такая проверка выполняется одновременно с вычислением изображения-разницы. Далее ты сжимаешь разницу, потом сжимаешь само изображение, потом сжимаешь набор команд GDI, которые привели к такой прорисовке, выбираешь меньший по размерам пакет и отправляешь, я правильно понимаю ваши наивные предположения? ))
Так вот, оно бы банально не работало бы, если так делать. Не справлялось бы на момент начала/середины 2000-х, если сервер на своей стороне будет перебирать всевозможные варианты кодировки перед посылкой. Поэтому так и не делали. В момент вычисления разницы можно простой фильтрацией выявить среднюю амплитуду этой разницы и сравнить со средней амплитудой самого изображения, т.е. принять решение о том, что из них выгодней гнать еще до того, как применять тяжеловесный алгоритм сжатия. Так же можно определиться с самим алгоритмом кодирования цвета — через дельта-кодирование или через PCM (еще до сжатия).
Гнать же и кешировать битмапы имеет смысл лишь в том случае, если накапливается статистика о том, что битмап многократно используется (более 2-х раз), а значит, обычный сценарий double-buffer-прорисовки, где битмап создают и тут же грохают — оно в это не попадает. Именно на это я и обратил твоё внимание, наивно думая, что раз человек рассуждает о таких вещах, то он хоть немного в теме. ))
V>> и насколько они использовались в случае double buffer drawing, — мы же с этого зацепились, верно? CC>Это надо делать VM с дохлым каналом, прогу с GDI double buffering и смотреть как оно будет себя вести.
Именно это и делал — разрабатывал систему конференций, где было и видео и апп-шаринг и рисование на общем графическом редакторе. Всевозможные способы кодирования для апп-шаринга были испробованы и наблюдалось, ес-но, как ведет себя сторона "сервера" при этом. "Сервером" выступает машина одного из участников, который расшарил свой экран.
Разумеется, если бы можно было перебирать всевозможные варианты кодирования, то можно было бы выбрать самый лучший из них, угу. Но по-факту в реалтайм такой подход не работает.
CC>Ну или какой нить Wireshark который бы умел расшифровывать пакеты и показывать что там внутри. CC>Опять таки может зависеть от того, как сервер с клиентом договорятся.
Описания PDU лежат в свободном доступе, ты спокойно можешь их принимать и отвечать.
MS прямо заявила, что эта дока не содержит никаких коммерческих секретов.
V>>Дык, RDP долгие годы и был тем самым T.128, как они купили его не помню уже у кого. CC>Аж всю 4.0 версию, которая была по сути первой. Потом дорисовали extensions.
"Потом" — это через 7 лет использования, когда уже надобность в RDP, считай, отпала. ))
V>>А с расшаренным экраном в Скайпе? CC>Скайп жутко тормозит по тому же каналу на ту же машину.
Отключи микрофон, хосподя.
Отлично работает показ экрана в скайпе, хотя у них не совместимый с T.128 протокол, но вполне себе пашет.
V>>- отключал сглаживание шрифтов; CC>Всегда на всех машинах отключены и без RDP. V>>- отключал темы; CC>Аналогично, везде Classic.
ЧТД. Ты, вроде бы и отвечаешь, но суть аргументов нагло игноришь.
ЧСХ, если бы RDP в те времена гнал лишь команды GDI для прорисовки и бимапы для кеширования, то не требовалось бы отключать сглаживание шрифтов и не требовалось бы отключать темы.
Собсно, одного лишь моего напоминания об отключаемом сглаживании шрифтов во время сеанса RDP и об отключении темы WinXP должно было быть достаточно для того, чтобы спор мгновенно заглох.
Здравствуйте, c-smile, Вы писали:
V>>Для абстракции HDC, полученной для поверхности DirectDraw, тоже выполнялось аппаратное ускорение. CS>Тебя обманули. CS>
When the GDI DDI was first defined, most display acceleration hardware targeted the GDI primitives. Over time, more and more emphasis was placed on 3D game acceleration and less on application acceleration. As a consequence the BitBlt API was hardware accelerated and most other GDI operations were not.
При том, что и здесь в целом неверно.
Надо было называть конкретные карточки, которые не ускоряли "большинство GDI команд" в пользу 3D-акселерации. При том, что мне одно время приходилось поддерживать довольно-таки приличный парк машин для оптовой конторы в конце 90-х, ни на одной не стояло видеокарточки, нацеленной именно на 3D.
В общем, в нашей реальности рисование прямоугольников и линий сплошным цветом выполнялось графическим ускорителем еще со времён Win98. А со времён WinXP практически поголовно происходило ускорение так же процедур рисования растровой кистью.
Собсно, да какие проблемы? Этот ускоритель можно было отключить и наблюдать на машинах того времени артефакты медленной прорисовки — мелькающие черные квадратики. Эта разница тогда была слишком заметна даже для обычного UI (не надо было даже 3D), чтобы сейчас можно было так громко утверждать, что ускорения не было. ))
V>>Любая прорисовка в буферез заднего плана начиналась с последовательности вызовов CreateCompatibleDC/CreateCompatibleBitmap. Такой битмап по-возможности создаётся в видеопамяти (пока там хватает места). CS>Слушай, прекращай уже фантазировать. Какой нахрен битмап в видеопамяти?
Самый что ни на есть обычный битмап в обычной видеопамяти. Зачем, по-твоему, делали битмапу LockBits? Неужели до сих пор не разобрался? ))
Потому что доступ к видеопамяти исторически происходил через "окна" — некий участок адреса, предназначенный для основной памяти. Т.е. надо было сделать так, чтобы нужный участок видеопамяти достоверно был отображён на это "окно" (если битмап размещается в видеопамяти).
(В x64 этот момент уже стал неактуальным, кста, там идёт полное отбражение, без "окон").
CS>Для примера: для того чтобы TextOut работала и выводила ClearType ей нужен доступ к background pixels.
Это только в случае BkMode=TRANSPARENT. Но все стандартные контролы, т.е. вообще все, рисуют при установленном явно BkColor и BkMode=OPAQUE. Т.е. цвет заднего фона задан явно, никакого доступа к задним пикселям не надо.
CS>Ты предлагаешь сначала тот background закинуть в видео память потом оттуда его же читать и писать попиксельно? CS>Ну нет конечно.
Не, это просто праздник какой-то сегодня!
До Win7 ты вообще рисовал ПРЯМО в видеопамять.
То бишь, когда ты получал HDC текущего окна для прорисовки, ты получал DC над экранным буфером видеопамяти.
Причем, доступ к отображаемому в данный момент видеобуферу — он на тех карточках всегда был более медленный, чем к заднему буферу.
В Висте/Win7 и выше ты больше не пишешь прямо в экранный буфер, поэтому, когда ты растягиваешь окно, то опять появляются артефакты — черные или белые "пустые" области, пока приложение там прорисует в свой буфер.
GDI functions for blitting operations only are hardware accelerated on Windows 7 exclusively
(это цитата из времён, когда Win7 была старшей текущей операционкой)
V>>ID2DRenderingTarget — это абстракция некоего интерфейса, наподобие HDC. V>>Ну разве что АПИ оформлено не в процедурном стиле, а в стиле COM. CS>Да при чем там API?
Потому что разный вид АПИ тебя путает, вестимо.
CS>Просто для управления временем жизни и версионностью этих ресурсов удобно использовать готовую идею IUnknown.
А вот остальное ты зря скипнул. ))
Да, GDI многое делает "само", "под капотом", а в DirectDraw ты можешь явно просить у объекта IsLost — то бишь, памяти не хватило и некий буфер (Surface) был насильно освобождён. В случае же GDI этот буфер может молча переехать в обычную память, а ты и знать не будешь. Или сразу будет создан в обычной памяти — а ты тоже знать не будешь.
Вот и всей разницы, собсно. Остальные принципиальные отличия я указал в пред.сообщении.
Здравствуйте, CreatorCray, Вы писали:
V>>Значит, ты ОЧЕНЬ давно пользовался этим софтом. В лучшем случае в начале/середине 2000-х. )) CC>Ты много видел 34" моников в середине 2000х?
Я видел CRT-монитор 36" в начале 2000-х, и?
А если речь о более поздних 34" LCD — то там все-равно 1080 линий, просто он более широкий.
Так шта, не впечатлил от слова совсем. ))
У меня и на ноуте 1920x1080 17".
V>>Бродишь по интернет-магазинам, качаешь текстурки их кафельных плиток, или обоев, или паркета/ламината и т.д., назначаешь различным поверхностям эти текстурки, смотришь что там получается. Это ж творческий процесс... )) CC>Пардон, но это довольно таки примитивный софт, который может бегать на самом планшете.
Разумеется, браузер может бегать и на ноуте, но натягивать скачанные текстуры на элементы модели и и пересчитывать её лучше на рабочей станции.
Здравствуйте, vdimas, Вы писали:
V>Какое-то у тебя дохлое воображение-то ))
Ты как обычно в своём репертуаре
V>А как же клиент-сервер? V>А как же более мохнатый n-tier?
А оно RDP не противоречит. Более того, перечисленное это решение принимаемое при проектировании, а разумность/необходимость RDP при эксплуатации.
V>Сказал человек, не разработавший ни одной бухгалтерской проги в жизни. ))
"Прогу" наподобие 1С конечно не разрабатывал, не по силам оно мне. Как работают подобные программы, причем и изнутри и с точки зрения пользователя знаю неплохо.
V>Но в сетевых применениях 7.x не вижу уже давно. V>Речь в этом топике про RDP, он был популярен для 7-ки 1C когда-то, потому что БД у ней файловое.
Нет. На выбор, файл-сервер или клиент-сервер. Как 7.x, так и 8.х. В 7.x для клиент-сервера был нужен MS SQL. В 8-ке вроде можно еще Postgre использовать, слышал, что с большим геморром, но тут
V>Ты действительно не знал, или притворяешься? V>8.x — клиент-сервер, ей не нужен RDP для комфортной работы.
Ну конечно
Оно замечательно пока оператор документы выписывает, а как только бухгалтер начинает отчеты строить, так запуск клиента на сервере дает выигрыш в разы. Еще RDP замечательно работает в сетях чуть и не чуть больше, чем локальная. Конечно, можно рассуждать, что в упомянутых клиент-сервере и всяких-прочих n-tier эти проблемы решаемы достаточно задуматься о них на этапе проектирования, но в результате имеем то, что имеем. И 1С и другие подобные программы используемые в том числе и в RDP и активно продвигаемые любителями модных web-технологий и любителями стричь абонентскую плату "современные" приложения, ужасные для пользователя. Впрочем, они так похожи на вконтактик и подобную чепуху, что офисные девушки наверно привыкнут и к этому безобразию.
V>RDP для бухгалтерии.
А в жизни все не так.
Re[26]: Что на самом деле произошло с Windows Vista
Здравствуйте, netch80, Вы писали:
V>>Не Эльбрус, конечно, но круче архитектуры x64 в бесконечное кол-во раз. V>>Смотришь, и глаз радуется. )) N>Чему именно радуется? N>VLIW? Так неуместно же для такой области.
Какой "такой"?
Современный комп/ноут/планшет — это платформа для аудио-видео приложений.
Людям надо общаться, смотреть киношки, играть в игрушки.
Сейчас даже обучающий софт очень и очень интерактивный.
Или читалка "голосовая".
Ну конечно, только такая мультимедийные архитектуры, как Эльбрус или IA64 максимально уместны.
А вот x86 максимально неуместна для таких приложений.
Аудио-кодеки для интернета всё-равно же в CPU выполняются.
Ты же работал с SIP когда-то, должен помнить. ))
N>Структура команды? Так после блока разбора переменность длины и всякие префиксы/суффиксы уже пофиг. А вот необходимость связывать в бандлы — мешает.
Не вижу раскрытия темы.
N>128 регистров? Никто их столько не используют, 99.9% кода даже 32 не занимают.
Дык, есть команды обращения к текущему "окну" шириной в 8 или 32 регистра.
Как раз операционка может использовать одни регистры, прикладные приложения — другие, причем разные.
Для текущего потока один раз выставляет адрес "окна" регистров.
Оч удобно, как по мне. Можно добиться, чтобы было меньше свопа регистрового файла при переключении контекстов/потоков.
N>Равнозначность регистров? Переименование решает эту проблему для большинства случаев.
Самая большая ложь, которую я вижу тут постоянно. ))
Переименование регистров не решает проблему кучи лишних пар PUSH/POP, вызванных этой неуниверсальностью.
V>>И оно дешевле в пересчёте на транзистор при аналогичных объемах выпуска... N>Дешевле что именно?
Производительность к кол-ву транзисторов.
N>Всё равно сейчас процентов 80 это кэш.
Дык, с удвоенным кешем L0 и процы почти вдвое больше стоят. ))
N>Дальше блоки предсказаний и разбора кода — ну, вот на последнем можно кое-как сэкономить.
А это, батенька, у нас основной тепловыделитель, то бишь ограничитель частоты.
V>>И тут AMD обломала весь кайф ))) N>Да-да. Просто они сделали то, что можно было очень легко сделать прямо сейчас и получить плавный переход.
Ну, для AMD речь стояла не о "плавном переходе", а о "жить или умереть".
AMD пришлось продать все свои заводы в США и перейти на полностью заказной выпуск чипов.
Но на эти деньги от проданных заводов они разработали и отладили новую архитектуру, т.е. банально выжили как экономическая единица.
N>Причём воспользоваться минимальными усилиями в плане собственно компиляции (open64 вообще на коленке сляпан, а доработать gcc было легко
Да как легко-то? Куча новых регистров (Rx), способ линковки и релокации символов другой совершенно.
Всё это потребовало денег и людских ресурсов.
N>(Я говорю о том, что и при этом можно было целую пачку вещей улучшить, но они забили болт.)
Да какой болт? ))
AMD на последнем финансовом издыхании всё это делала.
Что смогли, то сделали.
Собсно, цель была дать возможности работать 32-разрядным приложениям в 64-битной ОС. Только научив свою архитектуру такой работе можно было выжить. Вот с этим моментом они справились просто на отлично. Согласись, что остальные моменты на фоне этого, главного, просто меркнут.
N>Причём, я уверен, если бы они подождали развития новых технологий ещё лет 20, а потом бы стали строить что-то подобное Itanium — у них бы получилось лучше.
Ну, они украли дековскую Альфу и наш Эльбрус. Им надо было конвертировать наворованно в прибыль "сейчас", а не "потом". ))
N>А так — попытка построения в 2000 на концепциях в лучшем случае начала 90-х. Если не раньше.
Э-э-э... Давай уточним. Речь идёт о концепциях суперкомпьютеров, которые (концепции) решили применить в декстопном проце.
Так-то практически все концепции даже современных процов уже были опробованы еще в 70-80-е.
И защищенная память, и ОоО и вообще всё.
N>Ну ты вот веришь, что вложениями могло бы её поднять до чего-то сносного. Я — не верю. Причины тут прожужжались уже много раз.
Да нет никаких причин, кроме запроса рынка.
N>2. Оно само разбирает цикл уже на этапе JIT или native generation. На уровне IL это цикл.
Дык, на уровне исходника тоже цикл. Ничего не меняется, оптимизирующий компилятор должен этот IL преобразовать.
N>Я бы скорее ожидал что-то в духе Agnerʼовского ForwardCom (где длина вектора, обработанного одной командой, в принципе не ограничена) — переложить это на конкретную ограниченную длину уже банально. Хотя и оно заточено под текущую схему концепций соотношения команды и кэша.
Здравствуйте, Cyberax, Вы писали:
C>А без разницы. Пока что нет систем с байт-кодом, которые систематически превосходили бы по производительности нативный код.
Я получал сравнимую с нейтивной скорость, и?
Просто надо код делать как нейтивный — без вот этой лишней чудовищной косвенности, как в современных библиотеках управляемых сред.
Недавно был серьезный разбор с замерами на эту тему (лень прямо сейчас искать, но если будет интересный спор, то можно попробовать).
Здравствуйте, Cyberax, Вы писали:
C>Кстати, в то время как-то Балмер на вопрос "ЧЗХ творится с IE?!?" ответил, что: "версия IE6 будет последней — дальше Web некуда развиваться".
Дык, так и было.
Остальные игроки тормозили как нарики после изрядного косяка. ))
Только представь на минуту, если бы MS стала развивать свой IE с теми расширениями CSS, которые вот только недавно появились.
И еще выкатила бы реализацию Canvas и GLSL/WebGL?
Да там взрывы от пуканов этих тормозящих нариков разнесли бы всё нахрен ))
И, скорее всего, от этого будет какой-то реальный плюс.
