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
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?
- QPixmap * pixmap() const { return pixmap_.get(); }
+ QPaintDevice * paintDevice() const { return (QPaintDevice*)
pixmap_.get(); }
A /// Do an old man a favour and rename the underlying store ;-)
boost::scoped_ptr<QImage> pixmap_;
};
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 ;-)
class QScreen {
/// our owning widget
QWorkArea & owner_;
-// QRegion nocursor_region_;
-// QRegion hcursor_region_;
-// QRegion vcursor_region_;
+ QImage nocursor_;
+ QImage hcursor_;
+ QImage vcursor_;
- QPixmap nocursor_pixmap_;
- QPixmap hcursor_pixmap_;
- QPixmap vcursor_pixmap_;
-
// <at> { the cursor pixmap position/size
int cursor_x_;
int cursor_y_;
};
Angus
