Home > Mobile >  Consult a conundrum, qt how under a fb base, a thread drawing waveforms, a thread is the main UI
Consult a conundrum, qt how under a fb base, a thread drawing waveforms, a thread is the main UI

Time:09-19

As we all know, the UI is only one thread, I embedded chip is not very strong, only a FB, the main UI thread for QT, but I have a very critical requirement, there cannot be any card is 40 ms real-time refresh waveform, current waveform map of what resources is not itself, is a few points, but other things are in the main thread drawing, great chance there will be more than 40 ms, and even a few hundred milliseconds, if the waveform of the thread and they together, it must wait, effect is a card of a card, do you have any ideas scheme can solve the problem, change the source code can be, double FB synthetic scheme I also tried, although waveform BuKa, but synthetic rate=refresh rate=frames, and resolution, the result is the overall UI become card, can only give up, have no single UI FB?

CodePudding user response:

Linux system?
Set the thread priority tried?

CodePudding user response:

1/f, bow quoted water response:
Linux system?
Set the thread priority tried?
qthread for Unix systems, thread priority is not set, there are instructions in the qt documentation, and this is not the problem of thread priorities, but how the child thread, the final drawing are inevitably fall on the main thread, drawings of other things to take up much time, turn the waveform is the inevitable result when posted drawing event ends until something else, I hope it's like to open a menu, the menu in the main thread drawing, card 1 second, it a second time, the main thread of the UI are stuck waiting for the pop-up menu, but the wave like a circumstances continue according to the interval of 40 ms drawing marching forward,

CodePudding user response:

Look at the QCoreApplication: : processEvents () there are useless

CodePudding user response:

reference mango black reply: 3/f
see QCoreApplication: : processEvents () has no
this should be of little use, as long as the other controls or the form is the main thread execution of more than 40 ms things, such as a large paintevent window pops up, then the waveform paintevent is sure to wait for anybody else done, only his turn, even if you stick waveform is preferred, but other people matter sooner or later to be dry, dry in the process, how long do, waveform will soon turn, unless like MCU that interrupt nesting, in other words, I think this problem can't from the perspective of event loop to solve,
Throw code, summarize is only one thread, do A thing and do B, do A thing once every 40 ms is triggered, dry only 0.000001 ms, quickly solve, but do B, is likely to 100 ms, then do A will when things come to and was doing B must wait for finish it, just turn A thing, so I said this is A big problem, because the child is not allowed in QT UI thread, the estimate is for the sake of safety, after all, only A framebuffer, we know that if two processes of 1 framebuffer write value at the same time, what will happen? That is for your LCD screen will be crazy,

CodePudding user response:

This is not what data to fill in and map these fundamental questions separately, but the main thread is occupied and not 100% CPU (after all, if 100%, there is no discussion sense), waveform will continue to post, is posted, is to be able to see in the post,

CodePudding user response:

Want to put the time-consuming UI, and want to make the UI refresh quickly, found this framework of trouble to tell me

CodePudding user response:

refer to 6th floor Gong Jianbo response:
and want to put the time-consuming UI, and want to make the UI refresh fast, found this framework trouble tell me
may you didn't understand my problem, the main UI to draw interface controls, is bound to be time consuming, and this takes time, it is very easy to exceed the waveform mapping between, even if all other things in addition to drawing on a child thread, but you must draw interface on the main thread, the beginning of the process, will inevitably put stick waveform process card, so we hope to put the waveform of mapping the child thread, of course, I am Posting just worked in looking for this man, never done this aspect of the people, will feel impossible, or even didn't understand the title, because we have a mature scheme does, but the effect and resolution, and for the memory safety don't conflict in the middle, did some loss efficiency "busywork", result in the desired frames and so to see how others get. Don't get, I feel it is difficult to have ideas, this even wrote a patent, ideas are right, but write very top, see also white look,

CodePudding user response:

Basic most GUI library is only allowed from the main thread to manipulate the UI, you can go in the child thread processing frame buffer, only need to handle your good frames in the main thread cache on the display to the UI

CodePudding user response:

You use qPainter should be it, you can use in the child thread qPainter to drawing with a QPixmap, the main thread to draw this piece of QPixmap, need to be aware of is the time to show you this pixmap and when to go to empty the pixmap, if you don't need continuous real-time rendering, you can draw the two graphics when thread synchronization pixmap, if a pixmap only if there is no mapped, you only need to give this pixmap fill the transparent color, the child thread drawing (or reset) finished, only need to send a signal, in the main thread can refresh interface

CodePudding user response:

references 9 f Italink response:
you use qPainter should be it, you can use in the child thread qPainter to drawing with a QPixmap, the main thread to draw this piece of QPixmap, need to be aware of is the time to show you this pixmap and when to go to empty the pixmap, if you don't need continuous real-time rendering, you can draw the two graphics when thread synchronization pixmap, if a pixmap only if there is no mapped, you only need to give this pixmap fill the transparent color, the child thread drawing (or reset) finished, only need to send a signal, in the main thread to refresh the interface can be
thank you for your answer, but it seems I didn't understand what meaning, refers to the waveform area with a QPixmap? Then the child thread on the pixmap drawing, but the eyes to see the pixmap, the main thread is called drawpixmap draw it to see, that suppose I go to call drawpixmap timer 40 ms, but if the pop up a menu, when the main thread will be to paint this menu, this time waveform drawpixmap is done with this menu and posted on the screen, because they are on a thread, it seems is the waveform will be card, I was waveform like SCM interrupt, time to time, draw force, force the output to the framebuffer, eyes must be posted, see waveform effect is silky, continue to walk,

CodePudding user response:

40 ms refresh animation, frames and not very high, even if you to A real-time rendering the whole screen will not caton, footprint will not very high, A graphic drawing that is pure, not too many processing, real-time rendering is entirely possible, the reason of caton you also know that because caused by blocking the main thread, suppose you corresponding to the main menu (pixmap), A waveform area corresponds to B, use A timer to refresh the interface, in the main thread only responsible for rendering the pixmap, that is the main interface can only come into contact with the two pixmap (from the global perspective, you just wrote A show two pictures of window, right now, the computer performance can be done easily), and you want to draw waveform area, is in the child thread to handle the pixmap processing frequency can be set up by your own it will not lead to blocking the main thread

CodePudding user response:

Answer before I see you, you said A needs 0.01 ms, B May 100 ms, so the main thread may cause caton, 40 ms should not be completed because most of the things you gave them to the main thread (for example, some graphics Settings)

You need to do is, the main thread of 40 ms refreshed regularly, every refresh to draw two pixmap, no matter what is in the pixmap, then what to do is to 0.01 ms in one thread to deal with A corresponding pixmap, in another thread in 100 ms to deal with the corresponding pixmap B, so it can guarantee the thread synchronization also won't appear caton

CodePudding user response:

If you need a higher performance of drawing, can learn Qt encapsulation QOpenGLWidget, but need to 3 d graphics, in the short term is difficult to grasp

CodePudding user response:

reference 13 floor Italink reply:
answer before I see you, you said A needs 0.01 ms, B May 100 ms, so the main thread may cause caton, 40 ms should not be completed because most of the things you gave them to the main thread (for example, some graphics Settings)

You need to do is, the main thread of 40 ms refreshed regularly, every refresh to draw two pixmap, no matter what is in the pixmap, then what to do is to 0.01 ms in one thread to deal with A corresponding pixmap, in another thread in 100 ms to deal with the corresponding pixmap B, so it can ensure thread synchronization also won't appear caton

This has been a bit like I said the first double FB synthetic scheme,
My platform is embedded chip, mononuclear 800 MHZ, Linux system, there is only one framebuffer,
First of all we know, qt own control, is the default paintevent map content, and in the main thread, our own widget painting really realized the pixmap in child thread drawing, and then sent to the main thread, the main thread paintevent call drawpixmap directly, but if you want to use your method, is used for to all qt controls, qpushbutton, such as qwindow want oneself to realize double pixmap update mechanism, but this is obviously not realistic, actually we have many, many projects menu, with a lot of qt's own control, of course, there are our own code to draw qwidget controls,

CodePudding user response:

nullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnullnull
  •  Tags:  
  • Qt
  • Related