Russian Qt Forum

Добрый день

Есть старый класс рисования, конструктор

C++ (Qt)
OldPainter::OldPainter( Window * win )
{
 GrafPtr port = win->GetPort(); 
 ::SetGWorld(port, ::GetMainDevice());   // порт (окно), экран
 //...
}

После этого идет рисование нативными ф-циями, напр PaintRect() и все такое. Поскольку вывод double-buffered, никаких изменений на экране еще не происходит. Потом делается такой финт ушами

C++ (Qt)
OldPainter::~OldPainter( void )
{
 //..
 ::QDFlashPortBuffer(..);
 //..
}

И окно прекрасно обновляется, причем немедленно.

Как же мне это перевести на Qt  ???

Спасибо

Вариант "сохранить логику и переписать на QPainter" не предлагать?

Так а каким образом ее хранить? Покажите на примере (в псевдокоде конечно)

Эм... Без приведённого кода никак, но псевдокод.

Было

Станет

PS если вы умолчали о каких то подводных камнях старого класса или условностей - не обессудьте, сами виноваты :D

Все рисуем в backbuffer, по завершении говорим окну update и в его paintEvent рисуем backbuffer.

Это было бы просто замечательно, перевести код на QPainter не проблема. Но ведь я получу по дюнделю создав QPainter(QWidget *) вне paintEvent? Или есть ходы?

update не вызывает немедленной перерисовки - нужно получить событие. Да, есть repaint, но на OSX он == update

Конечно не вызывает, рисовать на виджет можно только в определенный момент - событие paintEvent. Вы можете только попросить сгенерировать такое событие.

Эмм.. у вас же обычное рисование.

Просто рисуете всё на буфере - картинке и по мере необходимости update с перерисовкой картинки. Есть проблема? Нет проблемы.

Есть ещё способ с installEventFilter - перехватывать paintEvent, но там со сложными виджетами засада, типа view и прочего.

PS опять не вижу проблемы ^.^ Надо очки поменять что ли...

Псевдокод

C++ (Qt)
if (1) {
 OldPainter op(win);
 op.PaintRect(&R);
}   // здесь деструктор вытолкнет нарисованный Rect на экран
while (true) {
// здесь что-то делаем достаточно долго, напр неск секунд
} 

Старый код рассчитывает что экран уже обновлен. Чтобы добиться того же с Qt нужно что-то делать, но что? Вызов processEvents может оказаться совсем не безобиден

Хммм....  ну а так ли уж это бесспорно? Да и рисование в pixMap здесь хорошего впечатления не производит

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

По простому - разбить на итерации. Нужен квадрат - рисуем квадрат.

Было

Стало

По-моему вполне нормально переносится. Месяца три назад помогал одному человеку похожее сделать.

Ничего не произойдет от такого update.
События никто не обрабатывает.

Во 1 это псевдокод.
Во 2 нужна вся картина и тогда уже будем приводит реально работающий код ^.^ Думаю для всех участвующих в обсуждении цикл событий Qt знаком. Как и методы работы с ним.

Добавим processEvent's, или же  ресурсоёмкие действия вынесем в другую функцию, а можно вообще в отдельный поток. Всё что угодно ;)

Когда? Объект op не разрушался.

Для основных платформ (win / X) так.
Внутри вашего top-window вы можете делать что хотите (рисовать на виджеты или QImage или куда хотите), но пользователь это увидит только когда графическая подсистема ОС попросит программу отрисовать его top-window послав ему сообщение.

Ну Qt всегда рисует в QImage - она буфферизирует отрисовку.

Точно, подправил

Даже там где ОС обеспечивает double-buffer? Не уверен. Кстати нативные ф-ции для немедленного обновления есть, причем не одна. Ладно, не суть.

Пожалуйста, "тарахтелку" не включайте  :)

Хорошо, зайдем с др стороны: а как мне добиться получения paintEvent не трогая при этом др события ? 

Это какие?

Вот только repaint вызывает немедленное обновление :)

Да хотя бы
CGContextFlush
CGContextSynchronize
QDFlushPortBuffer

Напр здесь говорят как грамотно флашить
https://developer.apple.com/library/mac/documentation/performance/Conceptual/Drawing/Articles/FlushingContent.html (https://developer.apple.com/library/mac/documentation/performance/Conceptual/Drawing/Articles/FlushingContent.html). Да, и кстати Widget::macCGHandle возвращает тот самый что нужен CG-вызовам. А на бздошном Вындоуз есть как минимум RedrawWindow, (т.е. repaint должен работать) ну ладно, с Вындоуз после

Как уже говорили выше - на OSX нет

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

А здесь венда будет посылать сообщения (причем не одно) и отрисовка будет работать в обработчике события.
В иксах также.

Вызов update + processEvents вам не катит? или repaint? В чем отличие от мгновенной отрисовки ? В том, что отрисовка произойдет на полмс позже?

Старое приложение это делает весьма непринужденно - причем как на OSX, так и на Вындоуз. Проблема в том как это в Qt впихнуть

Просто никакой перерисовки не произойдет. Вот как делается сейчас (без Qt)

C++ (Qt)
if (1) {
 OldPainter op(win);
 op.PaintRect(&R);
}   // здесь деструктор вытолкнет нарисованный Rect на экран
while (true) {
// здесь что-то делаем достаточно долго, напр неск секунд
} 

Заменив OldPainter на QPainter мы получим ошибку - ведь этот код не внутри paintEvent. Придется так

C++ (Qt)
PatchPaintParams(&R);   // надо как-то дать знать что делать внутри paintEvent
repaint();
while (true) {
...
 

При этом еще изрядно искромсав paintEvent. Это уже хреново - и это еще очень мягко сказано.
Но и это еще не все - repaint не сработает на OSX, а если "протолкнуть" его с помощью processEvents то др события будут обрабатываться, а на это код после while совсем не рассчитан.

И делает это в конечном итоге в обработчике событий аналогичном paintEvent.
Даже в таких библиотеках как SDL, где пользователю кажется, что он работает напрямую с окном, все происходит через события. Это спрятано внутри.

Может это стоит исправить и дальше спокойно жить? :)

Я тебя не понимаю
Вы сообщеньки читаете? паинтер МОЖЕТ рисовать на чем угодно в любое время, кроме виджетов. Нарисовав на буфере и отдав команду update, вы нарисуете на QImage и paintEvent отрисует этот QImage на виджете. Всё произойдет мгновенно и до while.

PS ну если не верите, сами попробуйте. Вы вот эту цитату написали не попробовав, на одном лишь своём мнении.

Точно нет, напр такие вызовы есть в обработчиках мыши, клавы и др.

Чужой старый код, Сколько всего таких мест - не знаю, найдя первые 10 считать перестал  :)

Полазил в отладчике QPainter::begin(). Есть флажок WA_OutsidePaintEvent, но он годится только чтобы заткнуть варнинги консоли. Самого рисования не происходит т.к. нет контекста (CGContextRef) - а он как раз извлекается из события рисования ОС. Подсунуть вроде можно. Поизучаю как создавать контекст нативными средствами  

Сегодня утром неск раз перепроверил (хотя помнил и раньше). Уверяю Вас, при вызовах update/repaint ну совершенно ничего не происходит :'( И в исходниках есть комменты что на OSX это нормально. Заметим что сейчас в приложении рисование (что мы обсуждаем) происходит поверх старого/текущего, поэтому вариант с pixMap совершенно не привлекателен - где хранить все если простыня со скроллом? А валить все в paintEvent (см мой предыдущий пост) - проще застрелиться

Это не показатель. Все может рисоваться в теневые буферы и на реальный экран выбрасываться при поступлении сообщения от ОС.

Так исходники этой программы есть?
Возможно, она в качестве бекенда для отрисовки использует что-то типа opengl, directx или подобных технологий?
Одной RedrawWindow() дело не закончится, посмотрите ее описание и вы увидите упоминание о всех сообщениях, которые будут слаться главному окну и при обработке которых оно должно все рисовать.

С каким скроллом? :)
Backbuffer размером с окно (не больше и не меньше) и рисовать на него нужно как на обычное окно.

Т.е. у вас OSX. Опять умолчанная информация ) Это не обвинение, а просто собираю портрет вашей программы :D

PS если так хотите заcтрелиться - в Qt как ни странно всё рисуется на QImage в paintEvent :)

Так, ну бычит, правда "с использованием неповторимого местного диалекта" :) Исходник прилагаю, нативняк передрал из Qt. Если кто проверит на какаве (у меня стоит сборка Carbon) - буду благодарен. Если мака нет - см скриншот плюс мои уверения что paintEvent и pixMap полностью отсутствуют. Заметим что рисование не затирает предыдущее - как и требовалось.

На Вындоуз пока не знаю, но надеюсь что просто priv->hd = GetDC(..)  и потом конечно ReleaseDC(..)

Я тоже это слышал, и вот сейчас проверил на drawLine. Рисуется нативными вызовами в контексте  полученном из события рисования ОС (а не на QImage/QPixmap). Что есть тот контекст - личное дело ОС, во всяком случае с double-buffered точно не видео. Обобщать этот результат не стоит - конкретный ОС

Точно. Платформопроблемы.
http://qt-project.org/faq/answer/how_does_qtwa_paintonscreen_relate_to_the_backing_store_widget_composition_

Рад, что у вас всё получилось :)

Ну и чего сидим, на Вындоуз не проверяем? (я недавно винт менял, поэтому даже MSVC не стоит). Там должно быть намного проще, см аттач. Ну отрихтуете что надо, хедерок подкинете.

Смысл простой - QPainter'у нужен контекст (HDC в Вындоуз)

Если верить этому, то все должно получиться.
http://forum.vingrad.ru/forum/topic-256400.html

Но сохранится ли изображение если окно скрыть и показать или проехаться другим окном?

Зачем что-то пробовать, если независимо в винде на image рисовать мона? Непонятно.

Что на взятом GetDC можно рисовать нативняком сколько угодно - то ясно, но пройдет ли с QPainter?

Это рисование "до следующего paintEvent", поэтому если скрыть - все пропало. Если проехаться - то надо переключиться на др окно, но это повлечет paintEvent. Если окно сдвинуть вправо и кликнуть, то нарисованный текст будет за пределами экрана. Если теперь окно сдвинуть влево, то на OSX все норм, текст покажется т.к. сидит в буфере, но на Вындоуз нет, опять paintEvent.

Это разные вещи, рисованием на image того же эффекта не достичь. Ну не надо так не надо.     

Ну если такое поведение устраивает... рисовать одно и тоже в нескольких местах.

Попробовал. Ничего не рисует.
QPainter::begin: Paint device returned engine == 0, type: 1

Не понял смысла в
Ведь мы не внутри paintEvent, пейнтер никогда не даст разрешения.
Если брать DC, то и рисовать надо нативными функциями. Но тогда как и предсказывает Old будет "крайне ненадёжное рисование".

И сразу какая-то паника, неумелый пересказ букваря и ссылка на старшего товарища :) Что значит "не даст", кто его спрашивает? Вариант для Вындоуз в аттаче, проверяем

Проверить невозможно в виду версии Qt. Просто нет таких хедеров и методов :) (как я понял из пятой версии вы их тягаете.)

Не вижу смысла в ваших действиях... Приведи пример пожалуйста, для чего это может пригодиться? Чего нельзя сделать стандартными и понятными любому средствами Qt?

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

PPS смотря на ваш код видится мне, что при дальнейшем использовании будут проблемы. Но можно использовать если проект "окончательный" и никогда никуда не будет встроен. Ибо разобраться в получившемся аде будет сложновато :D

Этот пример и был приведен в первом посте темы. Возможно Вас смутило незнакомое API, и Вы не поняли о чем речь (что впрочем не помешало Вам принять активное участие в обсуждении :)). Ладно, попробую объяснить проще. Есть старое (не Qt) приложение использующее такую технику

C++ (Qt)
DrawSomething( Window * );   // нарисовать что-то в окне (с выводом на экран)
DoSomethingLong();            // какие-то длинные вычисления
 

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

Понял что вы не читаете мои сообщения :D

PS если дочитали до сюда, ещё раз объясните чем рисование на системном фоне отличается от рисования на несистемном фоне pixmap в Windows?

Ваше первое сообщение уже давно "решено". В OSX так нельзя. В windows можно. Зачем лезть фиг знает куда?

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

Сейчас тот самый момент, когда "старую технику" нужно заменить новой. :)

Хотелось бы, но как это сделать? Поизучав старый код, вижу 2 типичных случая такого рисования

1) Просто-напросто перерисовать контрол(ы). Это связано с тем что используется старый синхронный подход

C++ (Qt)
while (MouseDown()) {
  // здесь напр EditText должен показать новое значение
}

Он берет контекст и просто вызывает paint контрола сам. Да, в Вындоуз это решается через repaint, но решения для OSX я не нашел. А переделать все драги на событийную схему - нереально пока под Qt вообще не ходит

2) Подсветить что-то. Напр юзверь попал в айтем. Опять взял контекст, отрисовал напрямую именно этот айтем и обвел его рамочкой. Юзверь отпустил мышь - ну сделал inval(), пришел штатный paint, что айтем выбран он понимает, а о рамочке ничего не знает - ну так она и не нужна, мышь-то уже отпущена.

Перекрытие окна само по себе не опасно, т.к. double-buffer. А событие paint не придет пока не отдал управление. Все бычит.

Объяснить не могу т.к. без понятия что то за системный/несистемный фоны ??? Поверьте, все Ваши сообщения я прочитал и пытался рассматривать их конструктивно - но пока без особого успеха :) Прикрепляю маленький скриншот дабы показать что требуется   

Кхм. Я вас главное понял. Вопрос закрываем.

А конечная точка - да, на OSX решайте костылями.
На windows переписывайте нормально, с помощью paintEvent.

В OSX это неизбежное зло(как вывод этой темы), а в windows всё это просто реализуемо.

Тогда я попрошу Вас ответить за свои слова: воспроизведите скриншот из моего предыдущего поста - в принципе конечно, "пиксель в пиксель" не требуется

Задачу приведите. Полную. Типа "чтобы рисовалась надпись в любой момент в нужном месте окна при нажатии мышкой".

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

Нормальная формулировка, только "нужное место" включает и занятое контролами (см скриншот). Платформа Вындоуз. Жду Вашего кода. Спасибо.

https://drive.google.com/file/d/0B_mrvcleB88yZTVJMU9oLTlNYjg/edit?usp=sharing
С фильтрами мудрить не стал, нет времени на отладку, но мысль ясна я думаю.

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

- нужно следить чтобы он пропускал события через себя
- нужно следить чтобы он был все время самым верхним и покрывал все (напр при resize)
- нужно его зачищать а когда?
и.т.д.

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

Мое мнение - в данном случае надо подходить более принципиально/идейно. Рисование double-buffered, (пусть в одном случае средствами ОС, в др средствами Qt) - значит и надо рисовать прямо в буфере, если такая необходимость возникла. И неважно что там в букваре пишут. А пытаться решить это еще одним (triple) буфером - безыдейно и обречено на "ловлю блох" ("костыль" в молодежных терминах)

Ну ничего, ответили кодом - уже молодец  :)

Кхм...
1) Рисование "поверх" подразумевает наличие нескольких слоёв для контроля, собственно, рисования. Думаю вы лучше меня это знаете.

2) Достаточно модифицировать пример из Шлее или Бланшета (не помню точно у кого) для пропуска сообщений. Этот функционал я не сделал, ибо его нужно отлаживать, а времени не особо было.

3)Как ни странно, следить "чтоб он был самым верхним" очень легко и просто - мы же следим за пропуском событий. Так что п.2 включает в себя п.3.

4) Зачищать когда хотите. Ибо вы получаете полную власть над слоем. Что угодно, хоть чёртиков рисуйте, хоть ангелов стирайте.

5) Могу. У меня есть картинка родителя. И у меня есть холст для рисования поверх. Далее уже дело техники.
Получить картинку, инвертировать цвета и нарисовать поверх - спокойно. Придётся часто обновлять в зависимости от области. Но это будет уже затратно и стоит задуматься "а оно нам надо?" ©.
В общем реализуемо, но малополезно.


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


7) Мы хотим рисовать под виджетом (сам виджет), на виджете (контролы) и над виджетом (поверхность). По здравому смыслу надо всё разделять, что мы и делаем, как благоразумные программисты.
3 сущности, как вы правильно и заметили. Мы же не дикари всё пихать в одну котомку.

Задача выполнена? Да. (возразите?)
Затратно? Нет.
Получили ещё один класс? Ради этого тема и была создана. Та малая толика, что он съест компенсируется выполнением задачи.

Само-плагиат? Ничего подобного. К тому же это один из рекомендованных разработчиками Qt способов рисования поверх виджета. Ссылку не приведу за давностью времени, но данная тема обсуждалась ещё на Qt 4.6+ на англицком языке. Тогда у меня руки не дошли попробовать.

Там предлагался ещё способ, я к сожалению не помню какой. Других способов "контролируемого" рисования поверх виджета пока нет.

PS кстати идейный подход вас не смущает смешиванием сущностей?

PPS ваш способ кстати использует хедеры Qt 5.* . Так что я пока не видел примера работающего кода.

Пример как это работает

C++ (Qt)
OldPainter painter(window);
Rect R = GetControlRect(comboBox);
for (int i = 0; i < 100; ++i) {
 DoSomething(i);
 painter.FillRect(&R, i);
}
Inval(&R);
 

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

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

В любом случае спасибо за "толчок" для написания фоновой рисовалки. Хотел попробовать что-то в этом духе года с 2011, но всё время откладывал и забывал :)

PS было интересно ^.^

А как во время итераций обрабатываются остальные события вроде нажатия на кнопку отмены текущей операции?

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

Этого никто не отменял, и об этом я создал др топик  :)
http://www.prog.org.ru/index.php?topic=26251.msg187843#msg187843 (http://www.prog.org.ru/index.php?topic=26251.msg187843#msg187843)

Ох уж эти обобщения... "Часто встречается"... У кого часто встречается? Кому это надо? :)
Посмотрите как реализован DnD в том же Qt, там нет таких странных ограничений.
С какой стати сообщения не должны извлекаться и обрабатываться?

Old, прошу вас, остановитесь :D Тема уже почти почти завершена :D

Правда интересно, почему нам непонятные требования пытаются выдать за само собой разумеющиеся. :)
В принципе, как всегда... но я не перестаю удивляться. :)

"нам" - за всех не расписывайтесь :) Есть портируемое приложение которое делает вещи так, и наивно думать что все будет "так же как в Qt". Еще более наивно "следовать Qt примерам-образцам" пытаясь подогнать приложение под них.

А вы пишете для кого-то конкретно? Указывайте это, иначе вы пишете нам всем. :)

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

Не буду холиварить, но поддержу Old.
Ибо если один у нас ходит кверх ногами, это не повод всех переучивать в принудительном порядке. Проще прописать этому "одному" лечебных процедур.

PS вы всегда можете скрыть реализацию от приложения. И только вы будете знать как жутко вы обманываете бедную и беззащитную программу.

Ну вот Вы уже и грубите :) А что же плохого делает приложение? Конечно, рисовать так необязательно, но что в этом некорректного/неграмотного? Я лично ничего не нашел, в обоих используемых ОС это 100% легально. Хорошо, давайте "переделаем по Qt-шному", но никаких Ваших предложений я не видел. Чего ж теперь Вы жопу вспомнили?  :)

Причем здесь приложение?
Меня удивила формулировка "часто встречается" и "перерисовывать надо, а события обрабатывать нет".
Это абсурдные требования, которые вы решили представить как само собой разумеющиеся.
Именно это я прокомментировал.

Никакого "Qt-шного" нет, это штатное рисование для большинства (если не всех) платформ.
Или на маках не нужно обрабатывать сообщение типа paintEvent?

Почему абсурдные? Вот была API ф-ция WaitMouseUp, потом ее заменили на что-то типа TrackMouseLocation (не помню точно). Аналогичный ф-ционал есть на Вындоуз. В любом случае он позволяет разобраться с драгом до упора. При этом я могу лить в очередь события вызванные драгом. А разрешив обработку я попадаю в ситуацию когда событие пришло, но ничего сделать с ним нельзя (драг активен). Не говоря уже о том что размазывать контекст драга по неск событиям - дело муторное.

Даже чисто теоретически - вторичный цикл событий применять можно и нужно. И вторичный цикл имеет полное право интересоваться лишь небольшим числом событий. Так что нечего понты гнать и разлагать (активно подпевающую) молодежь  :)   

Что значит "разобраться с драгом до упора"?

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

Какое событие пришло и почему с ним сделать ничего нельзя?

Мне даже страшно представить, что вы имеете ввиду.

Какой вторичный цикл? Для чего он нужен?

Понты гоните вы, своими абсурдными заявлениями типа "часто встречается".
А молодежь подпевает потому, что понимает абсурдность ваших заявлений. ;)

По поводу "так что же из этого вышло"

Хотя "асинхронное рисование" (вне paintEvent) и работает - счастья немного. Нет свободы действий. Напр начал рисовать асинхронно, получил контекст, создал QPainter, все вроде норм. НО я не могу звать processEvents т.к. получаю paintEvent когда контекст уже захвачен асинхронно. И эта ситуация тупиковая, ее не разрулить.

Пришлось все подгонять под paintEvent. Этому посвящено уже полтора месяца, сделано примерно 30%. Ну, бывает и так.