Перейти к содержанию

Очистка очереди сообщений WinAPI


Antonshka

Рекомендуемые сообщения

42 минуты назад, youneuoy сказал:

он и при слипе не тратит.

Я не говорил что он при Sleep тратит. Sleep меня пока вообще не интересует.

 

44 минуты назад, youneuoy сказал:

 Ты видел, на что ответ цитировал?

В твоем сообщении ты написал

5 часов назад, youneuoy сказал:

в отсутствии сообщений процессорное время у тебя отдельный поток будет потреблять(и кажется он будет не один)🙂

Я тебе привел цитаты, с форума и из книги, что это не так, что процессорное время не тратится, в моем конкретном случае, при использовании WaitForSingleObject.

 

47 минут назад, youneuoy сказал:

потому, что ты как минимум с понедельника этим загоняешься😀А мог бы сделать нужную штуку и забыть уже.

Это не загон, это обучение. Поиск лучших вариантов.

 

53 минуты назад, youneuoy сказал:

место простое, задачу можно поставить простую и просто же её разрешить. А ты сам себе палки в колёса пихаешь.

Дай же пообщаться с интересными людьми. Развеяться 🤗.

 

55 минут назад, youneuoy сказал:

В плюсах есть над подобными штуками обёртки для всего, что тебе нужно - thread, atomic, cancellation_token, condition_variable, mutex, scoped_lock, не перечесть всего. Это всё удобнее, чем стандартные

Понял теперь о чем ты. Тут такая ситуация, - я читал Рихтера, читал Щупака, в этих книгах не было разговора об std. В них все про WinAPI. Потому у меня такое восприятие.

Ну и плюс я сам, низкоуровневый любитель. Я хочу работать с "главарями", не с посредниками. Я не люблю за это с#. За то что он за меня решает. Но ты скажешь может быть тогда, пиши на ассемблере. Ассемблер тоже крут, его я тоже люблю. Но С++ интереснее.

 

1 час назад, youneuoy сказал:

Это всё удобнее, чем стандартные виндовые функции, при использовании этого тебе не придётся самостоятельно дописывать логику работы с тем же WaitForSingleObject для конкретной ситуации(а дописываешь ты её в каждом конкретном случае отдельно, не делая никаких обёрток, затрачивая время и усложняя код - 100% есть принцип ооп, "запрещающий" это).

Что-то в этом есть. Но мне хочется самому все организовать. Я бы не сказал что это требует особых усилий. Это достаточно быстро все пишется. Плюс я знакомлюсь с внутренним устройством всех этих систем. С внутренним это относительно, насколько это позволяет Microsoft. Где-то в книге читал что это полезно знать.

Придет время, и я возможно перейду на std. Хотя я и сейчас ее очень часто использую.

  • Спасибо 1
Ссылка на комментарий
Поделиться на другие сайты

Помимо задержки создания/удаления окна, должно еще быть плавное его появление/скрытие. Альфабленд от 0 до 255. Я забыл про этот момент.

Если реализовать плавность в главном потоке, то отзывчивость GUI будет зависеть от того как быстро изменяется прозрачность окна. Ведь при изменении прозрачности нужен Sleep(1), иначе прозрачность будет изменяться мгновенно.

Получается что без создания дополнительного потока, который будет управлять прозрачностью и вдобавок задержкой, не обойтись.

Ссылка на комментарий
Поделиться на другие сайты

5 часов назад, Antonshka сказал:

Если реализовать плавность в главном потоке, то отзывчивость GUI будет зависеть от того как быстро изменяется прозрачность окна.

а изменяется она в зависимости от разницы между временем, когда изменение должно завершиться и временем его начала.

 

5 часов назад, Antonshka сказал:

при изменении прозрачности нужен Sleep(1), иначе прозрачность будет изменяться мгновенно.

не sleep(1), но происходить это должно в цикле, да.

 

5 часов назад, Antonshka сказал:

Получается что без создания дополнительного потока, который будет управлять прозрачностью и вдобавок задержкой, не обойтись.

можно обойтись. Обсуждали ведь на прошлой странице.

 

В 18.08.2022 в 15:47, Antonshka сказал:

Я тебе привел цитаты, с форума и из книги, что это не так, что процессорное время не тратится, в моем конкретном случае, при использовании WaitForSingleObject.

ах, ок. А я имел в виду накладные расходы на существование потока.

В 18.08.2022 в 15:47, Antonshka сказал:

Поиск лучших вариантов

я тебе их и предложил. Ты выше не писал о том, что разные способы изучаешь - ты в один единственный упёрся.

В 18.08.2022 в 15:47, Antonshka сказал:

нял теперь о чем ты. Тут такая ситуация, - я читал Рихтера, читал Щупака, в этих книгах не было разговора об std. В них все про WinAPI. Потому у меня такое восприятие.

Ну и плюс я сам, низкоуровневый любитель. Я хочу работать с "главарями", не с посредниками. Я не люблю за это с#. За то что он за меня решает. Но ты скажешь может быть тогда, пиши на ассемблере. Ассемблер тоже крут, его я тоже люблю. Но С++ интереснее.

угу, получается ты читал книги не про то, что тебе нужно😃Ну или же тебе стоит взять те методы и применить их к новым инструментам.

А желания у тебя странные. Мне казалось, что ты хочешь либу для интерфейса написать. А это проще делать на плюсах. WinAPI хороши для управления виндой, но тебе это нужно по минимуму. C++ и C и WinAPI это не низкоуровневые штуки

В c# ты можешь работать с winapi. И с указателями и т.п., там это всё тоже есть. И c# с плюсами ничего за тебя не решают - ты просто сам пишешь ровно тоже самое, что уже реализовано в их стандартных библиотеках(ну или же в библиотеках сторонних авторов). И я вообще не понимаю как можно любить язык программирования. Также как и компьютер и молоток - это инструменты просто)

В 18.08.2022 в 15:47, Antonshka сказал:

Я бы не сказал что это требует особых усилий.

и тем не менее ты всё там же, где был неделю назад.

В 18.08.2022 в 15:47, Antonshka сказал:

Где-то в книге читал что это полезно знать.

я не уверен в этом. Большая часть подобной информации может пригодиться слишком уж редко.

В 18.08.2022 в 15:47, Antonshka сказал:

Но мне хочется самому все организовать.

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

В 18.08.2022 в 15:47, Antonshka сказал:

Дай же пообщаться с интересными людьми. Развеяться 🤗.

грибной сезон в разгаре. Айда в лес и потом в дискорд хвалиться😜

  • Понравилось 1
Ссылка на комментарий
Поделиться на другие сайты

15 часов назад, youneuoy сказал:

А желания у тебя странные. Мне казалось, что ты хочешь либу для интерфейса написать. А это проще делать на плюсах. WinAPI хороши для управления виндой, но тебе это нужно по минимуму.

Ну лааадно, зааажаааааарится как-нибудь

Спойлер

 

 

15 часов назад, youneuoy сказал:

я тебе их и предложил. Ты выше не писал о том, что разные способы изучаешь - ты в один единственный упёрся.

Я все ждал решения от @Xipho. А он молчит, как партизан.

Все хотел посмотреть на его планировщика.

Ссылка на комментарий
Поделиться на другие сайты

2 часа назад, Antonshka сказал:

Я все ждал решения от @Xipho. А он молчит, как партизан.

Все хотел посмотреть на его планировщика.

Так тебе вроде все расписали уже о_О. Мой планировщик тебе ничего нового не покажет. Не, если очень надо, я набросаю, конечно, но исходя из того, что выше писали, ты там уже ничего нового не увидишь.

Ссылка на комментарий
Поделиться на другие сайты

1 час назад, Xipho сказал:

Так тебе вроде все расписали уже о_О. Мой планировщик тебе ничего нового не покажет. Не, если очень надо, я набросаю, конечно, но исходя из того, что выше писали, ты там уже ничего нового не увидишь.

Я думал у тебя что-то иное.

Что он из себя представляет? Опиши в нескольких словах. Это дополнительный поток, время жизни которого равно времени жизни главного GUI потока, и который обрабатывает очередь задач? Или это просто обработчик задач встроенный в главный GUI поток?

Ты сказал, - "планировщик". Но не сказал что он из себя конкретно представляет. Или и сказал, но мне для понимания этого было не достаточно.

Ссылка на комментарий
Поделиться на другие сайты

2 часа назад, Antonshka сказал:

Это дополнительный поток, время жизни которого равно времени жизни главного GUI потока, и который обрабатывает очередь задач?

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

Ссылка на комментарий
Поделиться на другие сайты

11 часов назад, Xipho сказал:

Да, именно отдельный поток

Почему не главный поток?

Спойлер
В 18.08.2022 в 12:57, Antonshka сказал:

Главный поток должен быть абстрагирован

Ты планировщик можешь хоть в основной поток, хоть в дополнительный воткнуть. Следует абстрагироваться от таких загонов, как абстрагирование, WaitForSingleObject и т.п. И не забывай, что ты всё-таки на плюсах пишешь.

 

Такой планировщик справиться с плавным появлением/скрытием окна? А также с отменой отложенного задания? Думается мне что создать такой планировщик будет непростой задачей. Но сама идея конечно отличная.

Ссылка на комментарий
Поделиться на другие сайты

54 минуты назад, Antonshka сказал:

Почему не главный поток?

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

 

55 минут назад, Antonshka сказал:

Такой планировщик справиться с плавным появлением/скрытием окна?

Если планировщик в отдельном (не GUI потоке), это может вызвать определенные проблемы. В остальном - зависит от тебя. Если ты правильно накидаешь заданий, то почему бы и нет.

 

57 минут назад, Antonshka сказал:

Думается мне что создать такой планировщик будет непростой задачей

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

Ссылка на комментарий
Поделиться на другие сайты

  • 2 недели спустя...

Оказывается в Windows есть ограничение на количество User, GDI, и Kernel объектов, для сессии в общем, и в частности для процесса.

Для User и для GDI, максимальное возможное количество объектов на процесс равно 10 000. Для Kernel цифра побольше. Я открыл 5 PopupMenu и у меня уже более 10 000 GDI объектов. Утечки нет, при закрытии PopupMenu становится около 300. Проверял через ProcessExplorer.

Придется переписывать всю логику обращения с объектами. Переходить на постоянное создание/удаление. Не знаю как сильно это скажется на производительности, но такова реальность.

Еще вместо создания отдельных иконок, придется использовать общий ImageList или собственный битмап, затем уже через StretchBlt рисовать из него.

 

Кстати, ImGUI не использует задержку и плавность для PopupMenu и для ToolTip. Думал тоже убрать, но с ними все же интересней.

 

Изменено пользователем Antonshka
Ссылка на комментарий
Поделиться на другие сайты

×
×
  • Создать...

Важная информация

Находясь на нашем сайте, Вы автоматически соглашаетесь соблюдать наши Условия использования.