Russian Qt Forum

Доброго времени суток.

Столкнулся с такой ситуацией. Есть главное окно MainWindow, от него выделена память на поток приема информации asio, а от потока приема еще один поток обработки информации(конкретнее отрисовка пикселей в QImage)

Еще от главного окна выделил новый класс для работы с QGrapgicsView. Суть вопроса в том, что я создал массив QImage [16] и хочу передать адрес напрямую в поток обработки, для того чтобы при отрисовки, он сразу или через некоторое время отрисовывал на экран. Создавал в MainWindow и в каждом классе делал указатели, но либо ошибки, либо крашится при запуске. подскажите как лучше сделать.

сейчас картина такая

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

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

А "всё" и не надо, только апдейт гуя раз 5 в секунду (чаще все равно обычно нет смысла).

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


и работать непосредственно в MainWindow?

В MainWindow ничего не надо делать.
В вашем наследнике QGraphicView надо запустить таймер, а в обработчик timeout вставить код, который будет читать данные из asio->imagethread и отображать их на сцене.
Естественно, читаемые данные в imagethread должны быть защищены мьютексом.

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

C++ (Qt)
void SignalSetImage( QImage img );

Главная нитка обновит UI, может спокойно удалять/менять полученный img. То же самое для посылающей. За счет шары копирование состоится только при изменении

Так нельзя делать, от слова "вообще".
Во-первых, частота обновления картинок в нитке может быть очень высокой - в итоге поток гуя "забьется" сигналами и не справится с обработкой, в итоге зависнет наглухо.
Во-вторых, в этом случае нет никакой гарантии, что посылаемый объект не будет изменён во время "простоя" в очереди на обработку. Придётся перед отправкой сигнала делать img.detach(), т.е. deep copy, что опять же ударит по производительности.
Поэтому единственный нормальный вариант - позволить гую самому решать, когда ему обновляться. А это тока через таймер.

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

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

а чего не нативный qthread ?

Я его использую, просто boost asio udp крутится в этом потоке, а так обычный QThread.

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


Наследник от QGraphicView, а не от MainWindow, и как ему читать данные, не имея указателя? желательно не используя сигналы, а на прямую?

Это и была суть вопроса, извините, наверно невнятно все описал.

Тут нет никакой гарантии. Сами на подобное натыкались.
Оригинальные пиксели легко могут быть изменены через поинтер, полученный через QImage::scanLine (как чаще всего и делается), при этом никакой detach() не вызовется.
Только ручками, только хардкор :)

Да ну перестаньте. :)

C++ (Qt)
uchar *QImage::scanLine(int i)
{
    if (!d)
        return 0;
 
    detach();
 
    // In case detach() ran out of memory
    if (!d)
        return 0;
 
    return d->data + i * d->bytes_per_line;
}
 

uchar* linePtr = img.scanLine(0); // тут detach, понятно

linePtr[0] = 0xff;

emit ImageChanged(img); // ушел сигнал...

linePtr[0] = 0xaa; // а тут поменяли - detach в пролете

emit ImageChanged(img); // снова ушел сигнал, но теперь кто есть кто - вопрос...

Вам не кажется, что за такое нужно переводить в разносчики кофе. :)

Поэтому я и предлагаю через таймер обновляццо :)

Через интерфейс, который вернет необходимые данные.
Типа
QImage GetLastImage();

Добавьте этот метод в ваш класс потока и вызывайте его из гуя по таймеру.
В методе возвращайте последнюю полученную картинку.

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

Даже если полезли в пыксели (о чем разговора не было) - передернуть затвор никто не мешал

C++ (Qt)
uchar* linePtr = img.scanLine(0); // тут detach, понятно
linePtr[0] = 0xff;
emit ImageChanged(img); // ушел сигнал...
linePtr = img.scanLine(0);  
...
 

я бы делал так:
1. QUdpSocket и в его событии приема рисовал бы (сразу или N раз в сек)

2. Если вариант 1 тормозит, то
2.1 QUdpSocket и в его событии приема сбор данных в QByteArray
2.2 По накоплению данных (или какому иному условию) - старт потока обработки(рендеренга) или через QtConcurent
2.3 Данные обработаны - сигнал в основной поток с этими данными для отрисовки

QUdpSocket очень плохо принимает данные, поэтому и использую boost.

но все примерно так и есть
Всем спасибо, познал очень много с темы.

Могу спросить, что за проблемы были выявлены с QUdpSocket ?

какой багрепорт это подтверждает ?