Re: Problem ... very slow scrolling.

[Fred Kiefer]

Hi Richard,

I am propably the fifth in this list to point out that your wish is
already granted:
NSCopyBits() is (and was so for a long time) directly implemented via
XCopyArea. This is the way DPScomposite is implemented for all simple
operations. The question now is why scrolling still looks so slow? This
can only be caused by the new areas being drawn. As I never used
GWorkspace I cannot test this myself.

Cheers
Fred

Richard Frith-Macdonald wrote:
> 
> I work with non-gui stuff, so I don't look at the GNUstep gui stuff as
> much as I should,
> and when I do, it's on a fast machine.
> 
> I just started using GWorkspace with the icon view, and when scrolling a
> window full of
> icons is can clearly see the display updating.
> 
> Now, a scrollview is supposed to do a fast copy using NSCopyBits() so
> that slow updates
> should not be seen.
> 
> Looking at the code for NSCopyBits(), it uses DPScomposite, which (in
> the xgps backend)
> grabs an image from the source, manipulates it (alpha support etc), puts
> the result in
> another image and writes that to the destination.  This means that, far
> >from NSCopyBits()
> being a fast function to shift parts of a view around, it's actually
> rather slow.
> 
> Would it be possible to check for the case of a simple copy operation,
> and optimise this
> case (perhaps using XCopyArea()) so that scrolling was quick?
> 
> Anyone with the appropriate skills want to volunteer to do this?