Benjamin K. Stuhl wrote: > As you said, the thread would spend all its time in > QPainter.drawPicture(). However, I would suggest that rather than firing > off a thread for each redraw, there just be a fixed number (1?) of > drawing threads: each redraw queues a QPicture rendering request tagged > with a widget id. The rendering thread pulls requests off the queue, but > rather than service them in simple FIFO order, on each pull it finds the > most recent request with the given widget id and drops all the older > requests. That at least prevents the thread from ever being more than > one frame behind in its rendering...
Yes - I think you're right. The QPicture idea is turning out a bit harder than I thought though. It has an intrinsic DPI which is the system default (the X DPI is different to the Y DPI on my machine - nasty). When you paint to another painter then it gets scaled by the ratios of the DPIs (in X and Y), probably leading to streching as Veusz assumes that XDPI=YDPI. It will also break the output being the same on each machine as there will be a scaling command in the output, breaking the self test stuff as well. What I'd like is to be able to turn the scaling off and work entirely in the output DPI, but I'm going to have to try to work around the scaling that is going on by scaling the output to cancel it out. The alternative is to write my own QPicture substitute which doesn't do the scaling - that's really tempting but a maintenace pain. If only there was an option for QPicture to not to scale and to set its DPI! Jeremy _______________________________________________ Veusz-discuss mailing list [email protected] https://mail.gna.org/listinfo/veusz-discuss
