Angus Leeming a écrit :
Abdelrazak Younes <[EMAIL PROTECTED]> writes:
Hum, after thinking a bit more about this, I am maybe wrong here when
the windowing system is an X11 server. Georg's post pushed me to try
using a backing QImage instead of a QPixmap. I cannot feel any speed
difference within Windows but I guess it can make a big difference on
X11. Especially over the network as pointed by Georg. Besides, the code
is cleaner and a bit shorter.
class QWorkArea {
A /// Comment is now incorrect...
/// return the backing pixmap
For my defense it was 6am when I wrote that... (baby sick).
A /// Two thoughts here:
A /// 1. pixmap_.get() will never return 0, so the fact that
A /// you store a (smart) pointer is an implementation detail.
A /// This function should return QPaintDevice&.
A /// 2. Don't use C-style casts. Also, why is a cast necessary anyway?
A /// Doesn't QImage derive from QPaintDevice?
Yes you're right on both items. The casting is not needed at all. I am
going to remove the smart pointer in any case because QPixmap and QImage
are implicitly shared.
A /// Do an old man a favour and rename the underlying store ;-)
boost::scoped_ptr<QImage> pixmap_;
I am just experimenting here, but sure I will do so in the final version.
I think that this change is wrong (QPixmap -> QImage for the cursor). I seeem to
remember in the dim and distant past that we used a QImage and that that
resulted in traffic down an ADSL line. Remember, the underlying pixmap of a
QPixmap is stored on the machine that's doing the drawing, so the flashing
cursor requires only an instruction to switch from one pixmap to the other
rather than sending a new pixmap down the line each time.
Of course, I may well be remembering incorrectly! I'm sure that Martin will have
more details because it was his ADSL line. At least, that's what I remember ;-)
This make a lot of sense indeed. Thanks.
Thanks for the comments Angus,
Abdel.
