Why does instantiating QPixmap in a second thread block/slow main?



  • While a secondary thread is instantiating a big (32 megapixels) image, the main is blocked/slow.
    In this example code, main responsiveness is tested by logging mouseMoveEvent.
    Left-click starts a second thread which instantiates QPixmap. While this is happening, only a few mouseMoveEvent are logged.
    Right-click starts a cpu-bound thread. While the cpu-bound thread is running, many mouseMoveEvent are logged.
    test log on pastebin.com
    Why does this happen? How can I avoid it?

    import time
    import threading
    import sys
    
    from PyQt5 import Qt, QtCore
    
    def instantiate_qpixmap():
        pic_data = open('32megapixels.jpg', 'rb').read()
        print('{} - START QPIXMAP (ident {})'.format(time.time(), threading.get_ident()))
        for i in range(25):
            Qt.QPixmap().loadFromData(pic_data)
        print('{} - END QPIXMAP'.format(time.time()))
    
    def cpu_bound_work():
        print('{} - START CPU-BOUND (ident {})'.format(time.time(), threading.get_ident()))
        for i in range(100000000):
            a = i + 1
        print('{} - END CPU-BOUND'.format(time.time()))
    
    
    class widget(Qt.QWidget):
        
        def mouseMoveEvent(self, event):
            print('{} - pos {}'.format(time.time(), event.screenPos()))
    
        def mousePressEvent(self, event):
            if event.buttons() == QtCore.Qt.LeftButton:
                print('{} - LEFT (ident {})'.format(time.time(), threading.get_ident()))
                threading.Thread(target=instantiate_qpixmap).start()
                print('{} - LEFT launched'.format(time.time()))
            else:
                print('{} - RIGHT (ident {})'.format(time.time(), threading.get_ident()))
                threading.Thread(target=cpu_bound_work).start()
                print('{} - RIGHT launched'.format(time.time()))
    
    
    app = Qt.QApplication(sys.argv)
    
    wid = widget()
    wid.show()
    
    sys.exit(app.exec_())
    


  • Be vairwee vairwee careful you are going down a vairwee deep wabbit hole :)

    I state that because their are elements of QGui that will not work any where but within the Main Thread much like you cannot put anything that inherits from QWidgets into a secondary thread - so if its hanging this may be the reason if its just running slow not sure but it could still be related to this issue.

    Also they strongly suggest that you do not use PyQt with python threading but instead use QThread



  • About "no QGui outside main", I have indeed found people saying that e.g. creating QPixmaps in a thread or It is not safe to use QPixmap outside the gui Thread
    Where is the documentation about this? I don't even get the warning.
    How do I speed up my software? I suppose instantiating a QPixmap does the heavy jpg -> raster transformation which I suppose is slowing down my software. Would it be possible to do the transformation in another object (QImage?) in a secondary thread?



  • The documentation is here Threads and QObjects
    «Although QObject is reentrant, the GUI classes, notably QWidget and all its subclasses, are not reentrant. They can only be used from the main thread.»
    I suppose QPaintDevice (inherite by both QPixmap and QImage) is one of the "GUI classes".
    So maybe I could do the jpg->raster transformation with something non-GUI (non-Qt) and pass the data to main.



  • Okay in order to speed things up you are now going to have to enter the land of multiprocessing which will mean not only learning and understanding multiprocessing but how to use QThreads to facilitate communication between your two processes. After you have dug into multiprocessing and how to implement it and have a basic understanding post another question with any questions you have on that and I will help you with any issues you might be having -- just finished going through that pain myself and finally have 2 Processes, 6 Threads, and 2 Pipes function properly and that is just for one application.


Log in to reply