Hi, David Odin <David@xxxxxxxxxxx> 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 though). 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. Sven
