K>В Widget будет так же лежать своя (перегружабельная) WindowProc для обработки виндовых сообщений. K>Как и положено, мы будем RegisterClass для всех наших виджетов и затем их CreateWindow.
а чем плох подход с независимыми от виндов виджетами (без WindowProc, RegisterClass и CreateWindow)
и одной WindowProc на форму, обрабатывающей все виндовые сообщения и вызовающей соотв. методы соотв. виджетов?
для мышиных сообщений без цикла по всем дочерним виджетам (в порядке "сверху вниз") с проверкой попадания
не обойтись (в каждом виджете, могущем иметь дочерние), ну так раз ты винде отрисовку не доверяешь,
то и эту диспетчеризацию наверняка сделаешь чем-то лучше, чем внутренняя виндовая.
Здравствуйте, CEMb, Вы писали:
CS>>hashmap -> element это O(1) операция. Какие проблемы-то? CS>>И потом к USERDATA имеют доступ все. Компоненты чужие уже не получится использовать.
CEM>Да, но там всё равно много вычислений по сравнению с тем, чтобы взять данные по смещению(userdata). С учётом того, что это всё надо обрабатывать в реалтайме, получение элемента из мапы по скорости становится критичным. А так я тоже за реализацию на основе мапы.
Я так понимаю что ты имеещь ваиду GetWindowLong() ? Если "да" то не морочь себе голову — hashmap будет быстрее.
Здравствуйте, c-smile, Вы писали:
CS>>>hashmap -> element это O(1) операция. Какие проблемы-то? CS>>>И потом к USERDATA имеют доступ все. Компоненты чужие уже не получится использовать.
CEM>>Да, но там всё равно много вычислений по сравнению с тем, чтобы взять данные по смещению(userdata). С учётом того, что это всё надо обрабатывать в реалтайме, получение элемента из мапы по скорости становится критичным. А так я тоже за реализацию на основе мапы.
CS>Я так понимаю что ты имеещь ваиду GetWindowLong() ? Если "да" то не морочь себе голову — hashmap будет быстрее.
CS>Напиши тест и расскажи всем что быстрее.
Написал тест на MSVC 2013, std::map и std::unordered_map на 100000 элементов
В цикле на 100000 итераций обращался к мапе через [], потом в таком же цикле звал GetWindowLong()
Замеры делал через GetTickCount(), под дебагом.
CEM>Написал тест на MSVC 2013, std::map и std::unordered_map на 100000 элементов CEM>В цикле на 100000 итераций обращался к мапе через [], потом в таком же цикле звал GetWindowLong() CEM>Замеры делал через GetTickCount(), под дебагом.
CEM>Итого: CEM>std::map — 1607-1670 CEM>std::unordered_map — 640-812 CEM>gwl — 15-32
CEM>
Тормоза спрятаны в xutility под макросом #if _ITERATOR_DEBUG_LEVEL == 2, одна только критическая секция будет вызвана 100000 раз с проверками в _Orphan_me.
Здравствуйте, peterbes, Вы писали:
P>Тормоза спрятаны в xutility под макросом #if _ITERATOR_DEBUG_LEVEL == 2, одна только критическая секция будет вызвана 100000 раз с проверками в _Orphan_me.
Ага.
Пришлось увеличить итерации до 1М:
unordered_map : 78-110
gwl: : 46-63
довольно приятная производительность, с учётом того, что gwl — просто сходить по смещению. Хотя там адрес, от которого смещение брать, тоже как-то хитро считается.
Здравствуйте, rean, Вы писали:
R>Надо использовать GetWindowLongPtr: GetWindowLongPtr(hwnd, GWLP_USERDATA) То, что вам предложили, не предназначено для хранения указателей, и, заодно, вряд-ли оптимизировано для целей использования в объектных прослойках для обработки сообщений.
Ага, я знаю, просто для тестов читал результат в dword. Думаю, скорости будут одинаковые, потому что данные лежат в одном месте.
Здравствуйте, Kolesiki, Вы писали:
K>Мужики, есть старая, но по-прежнему интересная идея написать "свой GUI" для Винды. Причём это всё на D и для D. K>Хочу изложить примерную схему для оценки (может и идею подкинете, как проще).
Если уж хочется рисовать современный GUI, то по уровню возможностей он должен быть не ниже .NET WPF, иначе любой школоло-веб-дезигнер слепит из готовых Фреймворков в разы круче. Что потихоньку подталкивает к мысли как у комрада L_G http://rsdn.ru/forum/winapi/6507879.1
(что все эти WndProc со товарищи есть настолько окаменелые отходы от мамонта, что лучше забыть сразу и делать свой windowless-рендеринг, что позволит заюзать и аппаратное ускорение при случае, ибо анимированно блюрить или фигурно стретчить на CPU — то ещё удовольствие).
Здравствуйте, rean, Вы писали:
MD>>Если уж хочется рисовать современный GUI, то по уровню возможностей он должен быть не ниже .NET WPF,
R>Ничего не мешает кнопочки и т.п. стандартные вещи делать в виде виндовых контролов, а все остальное рисовать в Direct2D. Благо, все это займет максимум 200 строк кода на весь такой собственный GUI. Например, рисовать лейблы в виде оконных контролов нет смысла, ну и рисовать Tab Controls и т.п. уже не в моде.
Ну, дайте мне стандартную кнопочку с маус-ховером, скруглёнными краями, картинкой, анимированным кликом и условной дисабельностью. Минимум 200 строк на все эти приседания вокруг WinAPI, причём вокруг одной лишь кнопки.
R>Остаются Edit, Button, ListBox и т.п. мелочевка, которая превращается в 5 строчек кода на контрол (создать с нужными флагами и отмасштабировать под DPI экрана). А использовать XML, HTML и т.п. ерунду для этого — это стрелять из пушки по воробьям.
А вот дайте мне в 5 строчек лист-бокс, который как в скайпе: на каждой строке слева аватарка (кликабельная, открывает картинку в полном окне), затем ФИО первой строкой (с многоточием для непомещающихся), ник (кликабельный, открывает URL профиля) второй строкой, плюс справа всякие мелкие кнопочки "пометить как favorite", "активен ли в сети" и прочую шелуху. И это не говоря уже про плюшки типа "неактивных в сети рисовать сереньким шрифтом" и т.п.
Без обид, но даже слабую претензию на "Rich UI App" на этих 200 строчках не напедалить от слова "никак", а полезны оказываются именно XAML, HTML и прочая "ерунда".
Kolesiki wrote:
> Шахматисты из Borland (да и в MFC тот же хак) решили эту задачу каким-то хитрым ассемблером
Нет там хитрого ничего. Выделяется память с правами на исполнение. Туда
записывается 2 инструкции типа:
1) загрузить this класса как константу
2) jump на метод класса.
В оконную процеду передаётся адрес этой памяти.
Здравствуйте, avp_, Вы писали:
_>Нет там хитрого ничего. Выделяется память с правами на исполнение. Туда _>записывается 2 инструкции типа: _>1) загрузить this класса как константу _>2) jump на метод класса. _>В оконную процеду передаётся адрес этой памяти.
а потом спустя 20 лет MS патчит такие приложения ШИМом. Потому что ATL это их своё, родное. А на тебя болт забьют.
