> If I add an Image to Live it gets: > Added to queue as normal > processed to correct size. > Moved to low > more then likely if is requested in get_bytes > Move to High > processed > returned by function call. Well, it depends what you do. If you sent one image (directly) live the byte stream is requested (before the qimage). Thus the priority is set to urgent and the byte stream and qimage a generated in one go.
If you add it to the service the qimage is generated and the priority is set to low. Then the byte stream is generated (if there are not other qimages left to be generated). > This seems a lot of messing around when just processing with resize and > convert should be faster! I do not think so. The thread is processing as long as there is something to process. Setting/changing priorities is just a trivial thing and does not have any impact on the performance. Let's play the game for a few images: 1) Added to the service 2) Thread starts to process the QImages 3) Item is sent live 4) Thread request the byte stream 5) The other QImages are requested and if not present they are generated 6) OpenLP is ready... 7) Look at your CPU load -> the thread will still be processing, but the interface can respond to the user's action I sent 20 images live. The UI was able to respond after: branch: 30s trunk: 60s -- https://code.launchpad.net/~googol-hush/openlp/image-queue/+merge/65875 Your team OpenLP Core is subscribed to branch lp:openlp. _______________________________________________ Mailing list: https://launchpad.net/~openlp-core Post to : [email protected] Unsubscribe : https://launchpad.net/~openlp-core More help : https://help.launchpad.net/ListHelp
