Russian Qt Forum

Добрый день

Вот замечаю что какой-то виджет у меня перерисовывается хотя по моим расчетам не должен. Очень трудно нвйти чем это вызвано. Ну конечно просмотрел все его update и парентов его - ничего. Ставлю breakpont в paintEvent - ничего не дает, событие QEvent::UpdateRequest было извлечено из очереди, ну он и рисует как положено. А поставить точку на update() - так там будет останавливаться мульен раз. Как же отловить мерзавца?

Спасибо

не использовать отладчик, а логировать факт перерисовки (в разных местах) в консоль

красить все виджеты при n перерисовке в красный цвет, а при n+1 в зелёный. "Мерзавец" будет выделяться.

А никак. послать евент может любой, а вот узнать кто его послал как бы нереально.

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

Но это на мой взгляд слишком затратно.

Ну кто перерисовывпется - я и так прекрасно знаю, достаточно печатать в notify. Но вот почему?

Увы, это намертво кладет IDE  :)

а если по-мужски, в голом gdb?

Ммм.. Вопрос - а чем вам мешает лишняя перерисовка?

Мысль интересная, хотя требует изучения подробностей командной строки. Спасибо
Пока ничем, но мириться с этим непрофессионально

Я б на вашем месте не мучался. Т.е. там же идёт цепочка от самого верхнего окна до вашего виджета. Вполне вероятно кто то из них обновляется.

PS мириться с тем, что не мешает - это нормально. А вот когда начинает мешать - вот тогда надо решать вопрос.

Вы еще слишком молоды для таких сентенций :) Не спешите - стать старым пердуном всегда успеете

нормальное мнение нормального человека. А вот поиск выдуманных проблем - это уже болезнь.

PS есть такие мании, люди идеально здоровые ищут у себя болячки и находят ведь.

Если так хочется, можно в paintEvent() флаг завести, и игнорировать те перерисовки, которые кажется вроде бы не нужны. Потом доблестно бороться с глюками, которые вылезут в новых ситуациях.

Мне тоже некоторое время казалось, что paintEvent() слишком часто вызывается. Во-первых, сделал оптимизацию, повыносил оттуда все константные вычисления и прочее что не меняется. Во-вторых, решил, что раз Qt его вызывает, значит ему это зачем-то нужно. Может для каких-то внутренних процедур, которые на экране не видны - кэширования, оптимизаций и т.д.

А так у меня и сделано для QOpenGLWidget :) иначе (в 5.4) работать невозможно

Рекомендации "на основании опыта/здравого смысла" часто показывают отсутствие таковых :) Напр совет "забить на перерисовку" означает что ничего объемного человек еще не рисовал, секунд в paintEvent не имел - однако ж бойко дает общие советы :). И вообще вопрос был "как" ловить, а не "зачем".

Возвращаясь к теме: да, все-таки условный breakpoint в update, в конце-концов заставил его работать. Оказалось QTreeWidget по умолчанию вызывает update при смене фокуса окна. Зачем - хз, ведь фокус самого виджета не меняется. Отключить легко (если знать причину)  

Если б вы сказали о том, что у вас каждая перерисовка тормозит - это повод задуматься. А когда вы пишите, что вас нервирует лишняя - значит дурью маетесь :)
PS мой совет ведь помог?  помог) Так что цените :)

Вот новая проблема, тоже дело упирается в "как поймать".

Есть QOpenGLWidget в котором юзер двигает объекты с помощью мыши. В какой-то момент виден "чужой" кадр, никак не связанный со сценой, но что там - рассмотреть не удается, глаз воспринимает это как помеху/мельтешение. Для начала надо хоть как-то на нем остановиться, но как?

Стандартно - берёте gifcam и записываете с частотой 30 кадров в секунду ) Там кадр спокойно берёте и рассматриваете :)

Ну допустим так я увижу "калечный" кадр - и что с того? Информации о том чем он вызван по-прежнему ноль

Сами себе противоречите. " Для начала надо хоть как-то на нем остановиться, но как?" © ваши слова
Вам нужен кадр :) Увидев кадр можно будет локализовать проблему - откуда он вылез.
Вдруг у вас там кнопка рисуется на весь экран?

А если программно двигать мышь также, как двигает юзер?

Ну допустим QOpenGLWidget весь "чОрный" - или модель залита черным. Ну и что?

Мягко говоря, "трудоемко", а толку не видно. Допустим даже повезло и получили "пробой", но по-прежнему можем его только "лицезреть".

Напрашивается так: рисовать моно-цветом, напр белым. После каждого рисования читать, если "не белый" - останов, печать, т.е. ходы есть. Но как "прочитать" нарисованное для QOpenGLWidget ?  

по-моему вариант только один - писать лог, поставив запись в лог во всех функциях, которые могут повлиять на paintEvent

а чего трудёмкого? запустить нить, которая выдает сигнал, приемник сигнала двигает QCursor - несколько строк

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

можно тоже самое с простой видеозаписью изображения сделать

так ему надо этот лог синхронизировать со сбоем в изображении

Просто двигая мышь (и получая flash) я могу сказать типа "ну вот через 5 (или 10) перерисовок это случилось". Что  изменится от того что точно вычислили "на какой"? Этот "номер кадра" повторяться не будет, в отладчике к нему не привязаться.

Так а что логировать-то? 

А класс QOpenGLFunctions с его glReadPixels не подойдёт?

Что изменится при отлове кадра - вы будете на 1 шаг ближе к решению.
Что изменится при "получении номера кадра" - ещё 1 шаг ближе к мечте.
Что изменится если вы вместо дурацких комментариев проделаете данные вещи - вы будете ближе к решению, чем сейчас :D

Чья б корова не мычала - а Ваша бы точно молчала :) Ну чего тарахтеть если мысленки ни одной?

glReadPixels скопирует текущий буфер, а то что "сейчас отрисовано" (вызовами OpenGL) хранится в текстуре. Потом все соберется и будет сформирован еще буфер который OpenGL вытолкнет на экран. И как прорваться к текстуре - хз

А если выводить на экран номер текущей строки в логе? Тогда если поймать сбой, будет видна текущая строка)

Номер - это содержимое глобальной переменной инкрементируемой в каждом paint(). Номер нарисованного кадра. Когда станет известно его значение при глюке, настроите отладку на это значение. И отладчик остановится где надо.

А откуда предположение что сбой наступает после определенного/фиксированного числа перерисовок? Вот я вывел в консоль "номер рисования" (неуклонно растет). Вожу мышей, сбойнуло - смотрю консоль. Это конечно неточно, но ясно что никакого "периода" нет, наблюдал и через 5 и через 20. Почему-то сбойный кадр никогда не остается на экране, немедленно перекрывается нормальным.

Следующая позиция: ну а что делать когда (допустим) остановился в отладчике? Все вызовы OpenGL уже отработали, что/где искать? Хорошо, допустим даже встал перед началом "плохого" рисования - и что? Код-то отрабатывает одинаковый.

Беда в том что никакого "холста" нет. Напр

C++ (Qt)
glVertex3f(...)

Возможно здесь ошибка, подаваемые данные неверны. Но это (еще/пока) ничего не "отображает". А когда в конце-концов будет виден результат - хз чем он вызван, поезд ушел.

Ели бага раньше не было, то очень помогает git bisect в таких случаях - подходим к проблеме с другой стороны.

Еще один баг типа "хз где искать"

Рисую в окнах с помощью OpenGL. Первые 10-15 минут все норм. Затем почему-то поверх рисуется еще и wireframe, причем как-то грязно (явно не я рисовал). Какие есть мысли?

Углубился в чтение букваря
Так initializeGL() and paintGL() вызываются когда дело дойдет до рисования. А до того как - если мне надо extensions пощупать, текстуры подгрузить и.т.п.?  Ну ладно, предположил что мои артефакты рисования связаны с тем что какие-то glXXX вызываются при неустановленном (или неверно установленном) контексте. Может это и не так, но других соображений нет. Теперь горожу scoped чтобы это отловить...

Тут такая милая вещичка  :)

C++ (Qt)
printf("1: GL error %d\n", glGetError());
glBegin(GL_LINES);
glVertex3f(0, 0, 0);
glVertex3f(1, 1, 1);
printf("2: GL error %d\n", glGetError());
glEnd();
printf("3: GL error %d\n", glGetError());
 

Печатает
Где же ошибка  ???

Номер ошибки не очень информативный, можно попробовать узнать описание ошибки с помощью gluErrorString (https://www.opengl.org/sdk/docs/man2/xhtml/gluErrorString.xml) :)

Сразу видно что кошмары OpenGL Вам не снятся :)  Это ж "invalid operation", какие-то др ошибки бывают редко.

А версия OpenGL какая? Не 3.1+ ли?

На рабочей машине 2.1, но воспроизводится и на другой где 3.3

А линия на экране видна?
Где-то я читал, что начиная с тройки glBegin/glEnd собирались вообще выбросить.

Видна. Эти вызовы уже много лет deprecated, но насчет выбрасывать не слышал. Иногда они очень нужны - напр тот же obj файл ими нарисовать легко, неск строк (пусть и скорость маленькая)

Да вроде в 3.4 уже нет даже упоминания.

А вы с классами QOpenGLDebug... не работали?

Ну тут логика бессильна, вот "правельный ответ" найденный методом втыка
Если закомментировать печать 2, то печать 3 выдаст ноль. Ошибка вызывается самим glGetError, этот вызов недопустим между glBegin/glEnd. И все ошибки случившиеся в этом интервале будут выданы (станут доступны) лишь после вызова glEnd, поэтому печать 2 выдает ноль. Не слабо!  :)

Уже разбираюсь, спасибо за наводку

Нема GL_KHR_debug экстеншна  :'( :'( :'(

Еще один "молодой интересный", с OpenGL не связан. Одно из окон (типовое, ничем не примечательное) почему-то показывается (после show) "замороженным" и не реагирует на нажатия. Ладно, в mousePressEvent добавляю такую печать

C++ (Qt)
qDebug() << "win" << this << "parent" << parentWidget()
		 <<	"global" << e->globalPos()
		 << "local"  << e->pos();
 
qDebug() << "frameGeometry" << frameGeometry()
		 << "mapFromGlobal" << mapFromGlobal(e->globalPos());
 

Получаю вывод
На экране показывается верно (окно 640x480 стоит в центре экрана 1024х768), а (frame)Geometry печатает не то (по X никак не ноль). И mapFromGlobal выдает бред.

Растерялся солдат...

Решилось довольно просто - помогло наблюдение за QEvenr::Move. Псевдокод

C++ (Qt)
QWidget * win = new QWidget;
win->setGeometry(100, 100, 640. 480);
WId id = win->winId();    // это калечит 
// win->move(100, 100);   // это лечит
win->show();

При создании системного окна (др show) оно почему-то располагается как ОС решит (хотя позиция уже задана явно). Если потом не сделать move/setGrometry, то окно остается "в интересном положении" - рисуется верно но колбасит координаты. Хотя может на Вындоуз и работает, там не проверял

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

Еще один. Открывается модальный диалог (опять-таки, самый рядовой) и первый клик мыши почему-то игнорируется. Не всегда, но примерно в 50% случаев. Второй день придумываю тестовые печати. Наконец допер распечатать qApp->activeModalWidget. Во блин, оно NULL. Модальности это почему-то не мешает, но с событиями конечно чушь. MouseButtonPress получает окно что под диалогом, но там отлуп - теперь модальность появилась. Как можно было ее потерять  ???

Thoughts?

Ну... как бы, если что-то происходит "примерно в 50% случаев", то с вероятностью близко к 100% где-то есть неинициализированная переменная.  :D

Но в Qt 4.7, с которым сейчас работаю, такого глюка с модальностью не замечал. Хотя модальными диалогами пользуюсь не редко. Делал и на 5.каком-то, тоже всё было нормально.

Так что проблемный код в студию...

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

"Пропажа"  нажатия мыши связана с вызовом этого диалога по double-click из предыдущего окна (хотя делается это через сигнал с QueuedConnection). Все норм если тот же самый диалог я открываю по клавише. В сбойной ситуации при нажатии мыши на кнопку никаких событий не приходит вообще. При отпускании кнопки мыши приходит 3 (MouseButtonRelease) причем окну (не виджету) - и все, дальнейших событий нет.

На OSX (Qt 5.4) тестовый пример полностью воспроизводит ситуацию: запустить и double-click в  окно (ну в область клиента конечно). Появляется модальный диалог, тыкаете в его клиентскую часть. Ничего не происходит, mousePressEvent нет (вот он баг). Опять тыкаете - все норм.

На Win7 (Qt 5.3.2) - баг не воспроизводится, "утерянного" нажатия нет

У меня похожее было некогда с MFC - в окно первоначально не попадал фокус ввода. Первый клик ставил его в окно, второй отрабатывался окном уже как сигнал. У OSX и Win управление фокусом ввода совершенно разное.

А если тоже самое не кодом, а в Дизайнере нарисовать - ведь всё нормально работает?  ;) Я вообще всё в Дизайнере рисую, у меня ТЬМА окон и все достаточно сложные, если кодом их делать - проще застрелиться. Ни разу подобной проблемы не встречал, хотя есть и модальные окна, и не модальные. Правда и делаю пока только в Win, переносить в Lin буду потом-потом...

В тестовом примере фокуса нет, да и было бы событие мыши - а его нет. 

А Вы тоже работаете на OSX? Ой как хорошо, будет с кем посоветоваться! Ах нет, это Вы просто так сказали... очень жаль  :'(

Не заслуживает проверки, какая разница "где/как создано" если баг в событиях мыши. 

Я с Linux работаю. Идеология ввода *NIXовая, как и у OSX, и тоже очень отличается от Win. Предыдущая версия моего софта работала в Linux в KDE и GNOME, без каких-либо проблем с фокусом. То есть, всё работало один-в-один. Но я всё рисую в Дизайнере.


А вот это совершенно зря. Очень может быть, что при создании в дизайнере что-то учитывается, и баг не проявится. Останется только сравнить и найти - что учитывается.  ;D Или написать баг-репорт на bugreports.qt.io ...  ;)