Jeremy Sanders wrote: > 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!
I'm also worried by this bug: http://bugreports.qt.nokia.com/browse/QTBUG-4974 There are some funnies in Qt to do with the character positioning and spacing still. Jeremy _______________________________________________ Veusz-discuss mailing list [email protected] https://mail.gna.org/listinfo/veusz-discuss
