David Odin <[EMAIL PROTECTED]> writes:

> - have the checkerboard fixed to the window for images and previews.
> Imho, the later is nicer, but Sven told me it could make the scrolling
> and panning of the main image window much slower.

It wouldn't affect the plug-in previews since there we redraw the full
preview on scrolling anyway (this implementation detail could change

In the image window however I expect a very noticeable slowdown for
scroll operations. What we are doing in the display code is to use
gdk_scroll_window(). This is most easily explained using an example:
Say you scroll 10 pixels to the right. What happens is that we copy
the content of the window 10 pixels to the left using a
screen-to-screen blit. This is usually implemented as an operation
that is performed entirely on the graphics card so it uses almost no
CPU cycles. Only an area of 10 pixels width actually needs to be
redrawn. If we would decouple the checkerboard from the image, we'd
have to redraw the whole image display on every scroll operation.

Only if we would let the graphics card do the composition onto the
checkerboard, we could consider to link the checkerboard to the
window. Modern graphics card are able to do that but GDK lacks an API
to use that functionality and there are also certainly people using
GIMP on older hardware which doesn't do alpha compositing in hardware.

It would still be interesting to hear about people's preferences. So
please ignore my technical comments and tell us what which behaviour
you would prefer from a user's point of view.

Gimp-developer mailing list

Reply via email to