GUI и проверка координат мыши

@Optimus11 · Регистрация: 10.01.2017

Author24 — интернет-сервис помощи студентам

Здравствуйте,

Пытаюсь реализовать простой графический интерфейс на основе рисования примитивов с помощью OpenGl(обертки) и получается такая вещь, что при отрисовки каждого кадра - приходится проверять координаты курсора мыши на "столкновение" с каждый элементом GUI: кнопок, менюшек, ползунков.

То есть даже если курсор мыши не двигается и вообще условный пользователь ушел спать, то код, который контролирует GUI, просто будет молотить 30-60 кадров в секунду проверки на "столкновение" всех элементов GUI c курсором мыши.

Это вообще так и делается или это не нормально так тратить процессорное время ?

@nmcf · 03.04.2023, 00:10

По событиям от мыши.

@KSergey9 · 03.04.2023, 09:35

Что есть

Сообщение от Optimus11

проверки на "столкновение" всех элементов GUI c курсором мыши

?
Что за "столкновение" такое? что из него следует, какие действия?
Обычно на мышь программа реагирует по нажатию кнопки - только тогда и есть смысл обрабатывать координаты. Или у вас картинка меняется просто от движения мыши?

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

@NEED-A-JOB · 03.04.2023, 12:05

Сообщение от Optimus11

графический интерфейс на основе рисования примитивов с помощью OpenGl(обертки) ..... каждый элементом GUI: кнопок, менюшек, ползунков

Откуда в OpenGl кнопки, менюшки, ползунки ?

@Optimus11 · 03.04.2023, 12:07 **[ТС]**

Сообщение от KSergey9

Что есть

?
Что за "столкновение" такое? что из него следует, какие действия?
Обычно на мышь программа реагирует по нажатию кнопки - только тогда и есть смысл обрабатывать координаты. Или у вас картинка меняется просто от движения мыши?

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

Я рисую в окне к примеру кнопку - то есть обычный закрашенный прямоугольник с координатами. Положение нарисованной кнопки не меняется.
Курсор мыщи естественно двигается по окну и постоянно меняет координаты. Мне естественно нужно знать зашел ли курсор мыши в область моей нарисованной кнопки. Поэтому каждый кадр приходится высчитывается положение курсора мыши на "столкновение" с моей кнопкой. Это не WinApi или подобные системы - где при клике вызывается колбек.

@Royal_X · 03.04.2023, 12:07

Optimus11, однозначно так нельзя. Зачем вам обрабатывать координаты мыши даже тогда, когда они вам не нужны? Вы же кликаете на какие-то элементы gui, так значит по этому клику и обрабатывайте. Например, в WinAPI можно добавить кейс WM_LBUTTONUP (срабатывает, когда отпускаете нажатую левую кнопку мыши в окне программы) в главную процедуру WindowProc. В таком случае координаты можно получить так:

C++

1 2	xPos = GET_X_LPARAM(lParam); yPos = GET_Y_LPARAM(lParam);

Прим. : Можно, конечно, брать координаты через LOWORD или HIWORD непосредственно, но рекомендовано использовать GET_X_LPARAM и GET_Y_LPARAM из windowsx.h.

@Optimus11 · 03.04.2023, 12:08 **[ТС]**

Сообщение от NEED-A-JOB

Откуда в OpenGl кнопки, менюшки, ползунки ?

на основе рисования примитивов с помощью OpenGl(обертки)... отсюда ?

Добавлено через 57 секунд

Сообщение от Royal_X

Optimus11, однозначно так нельзя. Зачем вам обрабатывать координаты мыши даже тогда, когда они вам не нужны? Вы же кликаете на какие-то элементы gui, так значит по этому клику и обрабатывайте. Например, в WinAPI можно добавить кейс WM_LBUTTONUP (срабатывает, когда отпускаете нажатую левую кнопку мыши в окне программы) в главную процедуру WindowProc. В таком случае координаты можно получить так:

C++

1 2	xPos = GET_X_LPARAM(lParam); yPos = GET_Y_LPARAM(lParam);

Прим. : Можно, конечно, брать координаты через LOWORD или HIWORD непосредственно, но рекомендовано использовать GET_X_LPARAM и GET_Y_LPARAM из windowsx.h.

Ну я знаю как устроено в WInApi - но я же в данном случае его не использую.

@Royal_X · 03.04.2023, 12:12

Сообщение от Optimus11

Ну я знаю как устроено в WInApi - но я же в данном случае его не использую.

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

@Optimus11 · 03.04.2023, 12:29 **[ТС]**

Сообщение от Royal_X

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

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

@Ygg · 03.04.2023, 12:36

Сообщение от Optimus11

Это вообще так и делается или это не нормально так тратить процессорное время ?

Мне думается, что это нормально. Так оно и должно работать в игрушках. Оконная событийная модель тут не работает. Всё построено на одном цикле, в который помещаются обновления и рисование. При обновлении происходит анализ текущего состояния манипуляторов (мышь, клавиатура, джойстик и т.д.) и интерпретация этого состояния в соответствии с текущим окружением. В игре мышь может не двигаться, но при этом могут двигаться игровые объекты и попадать под текущую позицию мыши. Логика работы может требовать какой-нибудь динамической подсветки объекта под курсором. Если же говорить про оконный интерфейс в различных игровых меню, то там придётся самостоятельно "превращать" состояния манипуляторов в собственные "события".

@Royal_X · 03.04.2023, 12:45

Сообщение от Optimus11

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

для таких случаев все проверки можно сделать не в 30-60 кадров в секунду, а в 5 кадров в секунду, а то и меньше. Это можно сделать с помощью таймера.

Добавлено через 3 минуты
Ygg, да, но даже в игровых движках не все проверки лепят в update или physics_update, которые обновляются 60 и более кадров в секунду. От грамотной разработки зависит уровень оптимизации. Потом еще многие жалуются, мол игра вроде простая, но железо очень грузится даже на топовых девайсах.

Добавлено через 5 минут
я встречал тормознутую игры, где разраб использовал рейкастинг в 60 кадров в секунду, в то время, как в этом не было необходимости. Поверьте, пользователю особо не важно, когда всплывет его подсказка при наведении на графический элемент - через 200 мс или 20 мс.

@Optimus11 136 / 49 / 5 Регистрация: 10.01.2017 Сообщений: 1,894
		1
	GUI и проверка координат мыши 02.04.2023, 16:37. Показов 600. Ответов 10 Метки нет (Все метки) Здравствуйте, Пытаюсь реализовать простой графический интерфейс на основе рисования примитивов с помощью OpenGl(обертки) и получается такая вещь, что при отрисовки каждого кадра - приходится проверять координаты курсора мыши на "столкновение" с каждый элементом GUI: кнопок, менюшек, ползунков. То есть даже если курсор мыши не двигается и вообще условный пользователь ушел спать, то код, который контролирует GUI, просто будет молотить 30-60 кадров в секунду проверки на "столкновение" всех элементов GUI c курсором мыши. Это вообще так и делается или это не нормально так тратить процессорное время ? 0

@nmcf 7803 / 6567 / 2988 Регистрация: 14.04.2014 Сообщений: 28,706
	03.04.2023, 00:10	2
	По событиям от мыши. 0

@KSergey9 576 / 477 / 100 Регистрация: 05.08.2022 Сообщений: 2,626
	03.04.2023, 09:35	3
	Что есть Сообщение от Optimus11 проверки на "столкновение" всех элементов GUI c курсором мыши ? Что за "столкновение" такое? что из него следует, какие действия? Обычно на мышь программа реагирует по нажатию кнопки - только тогда и есть смысл обрабатывать координаты. Или у вас картинка меняется просто от движения мыши? Впрочем, выше уже сказали, что обрабатывать надо только события мыши, надеюсь в вашем фреймворке они есть. 0

@NEED-A-JOB 118 / 86 / 35 Регистрация: 07.11.2022 Сообщений: 355
	03.04.2023, 12:05	4
	Сообщение от Optimus11 графический интерфейс на основе рисования примитивов с помощью OpenGl(обертки) ..... каждый элементом GUI: кнопок, менюшек, ползунков Откуда в OpenGl кнопки, менюшки, ползунки ? 0

@Optimus11 136 / 49 / 5 Регистрация: 10.01.2017 Сообщений: 1,894
	03.04.2023, 12:07 [ТС]	5
	Сообщение от KSergey9 Что есть ? Что за "столкновение" такое? что из него следует, какие действия? Обычно на мышь программа реагирует по нажатию кнопки - только тогда и есть смысл обрабатывать координаты. Или у вас картинка меняется просто от движения мыши? Впрочем, выше уже сказали, что обрабатывать надо только события мыши, надеюсь в вашем фреймворке они есть. Я рисую в окне к примеру кнопку - то есть обычный закрашенный прямоугольник с координатами. Положение нарисованной кнопки не меняется. Курсор мыщи естественно двигается по окну и постоянно меняет координаты. Мне естественно нужно знать зашел ли курсор мыши в область моей нарисованной кнопки. Поэтому каждый кадр приходится высчитывается положение курсора мыши на "столкновение" с моей кнопкой. Это не WinApi или подобные системы - где при клике вызывается колбек. 0

@Royal_X 4144 / 1969 / 958 Регистрация: 01.06.2021 Сообщений: 6,973 Записей в блоге: 6
	03.04.2023, 12:12	8
	Сообщение от Optimus11 Ну я знаю как устроено в WInApi - но я же в данном случае его не использую. но вы же когда рисуете, вы же нажимаете на кнопку мыши? значит берите координаты и делайте все проверки только когда нажата кнопка мыши. 1

@Optimus11 136 / 49 / 5 Регистрация: 10.01.2017 Сообщений: 1,894
	03.04.2023, 12:29 [ТС]	9
	Сообщение от Royal_X но вы же когда рисуете, вы же нажимаете на кнопку мыши? значит берите координаты и делайте все проверки только когда нажата кнопка мыши. Да я думал об этом, проблема возникает, когда нужно сделать небольшие эффекты типа изменения цвета при наведении на элемент GUI или всплывающая подсказка. 0

@Ygg 2710 / 864 / 327 Регистрация: 10.02.2018 Сообщений: 2,044
	03.04.2023, 12:36	10
	Сообщение от Optimus11 Это вообще так и делается или это не нормально так тратить процессорное время ? Мне думается, что это нормально. Так оно и должно работать в игрушках. Оконная событийная модель тут не работает. Всё построено на одном цикле, в который помещаются обновления и рисование. При обновлении происходит анализ текущего состояния манипуляторов (мышь, клавиатура, джойстик и т.д.) и интерпретация этого состояния в соответствии с текущим окружением. В игре мышь может не двигаться, но при этом могут двигаться игровые объекты и попадать под текущую позицию мыши. Логика работы может требовать какой-нибудь динамической подсветки объекта под курсором. Если же говорить про оконный интерфейс в различных игровых меню, то там придётся самостоятельно "превращать" состояния манипуляторов в собственные "события". 1

@Royal_X 4144 / 1969 / 958 Регистрация: 01.06.2021 Сообщений: 6,973 Записей в блоге: 6
	03.04.2023, 12:45	11
	Сообщение от Optimus11 проблема возникает, когда нужно сделать небольшие эффекты типа изменения цвета при наведении на элемент GUI или всплывающая подсказка. для таких случаев все проверки можно сделать не в 30-60 кадров в секунду, а в 5 кадров в секунду, а то и меньше. Это можно сделать с помощью таймера. Добавлено через 3 минуты Ygg, да, но даже в игровых движках не все проверки лепят в update или physics_update, которые обновляются 60 и более кадров в секунду. От грамотной разработки зависит уровень оптимизации. Потом еще многие жалуются, мол игра вроде простая, но железо очень грузится даже на топовых девайсах. Добавлено через 5 минут я встречал тормознутую игры, где разраб использовал рейкастинг в 60 кадров в секунду, в то время, как в этом не было необходимости. Поверьте, пользователю особо не важно, когда всплывет его подсказка при наведении на графический элемент - через 200 мс или 20 мс. 2