Terry Alexis Lurie <[EMAIL PROTECTED]> writes: > It looks as though the buffer is blocking and copying in the bitmap > 100% before switching back to other tasks. So if the copy is not as > fast as the scrolling action, then the scroll lags while it > completes.
[...] > My thoughts are: > > 1) Find out where the bitmap copy-in operation is and make it > cancellable. Cancel if further scroll action requested > 2) You guys have done a good job with the wireframe ZOOM_PANNING > which is nice and quick. Maybe I could make an option to switch that > into the scroll action instead. > 3) A cheap cache with a mem-resident downsampled image. This is what > Adobe Ilustrator does when scrolling. > > 4) Some combination of those three. > Hi Terry, great that you want to go fix this! The code doing the bitmap scaling/setup is in module goodies, goodies/source/graphic/grfmgr?.cxx, to be specific. There's already some buffering going on, but it's clearly possible to extend that with a lo-res bitmap for fast repaint. You can poll for pending user input via Application::AnyInput() from vcl, so, doing that in the bitmap interpolation outer loop should make that cancellable - problem is to get the GraphicManager code to be called again eventually, to repaint with the full-blown bitmap. Have a look at svx/source/svdraw/svdograf.cxx, which implements the Draw/Impress graphic shape. There's already a timer-based demand-loading feature, you might borrow from that to have a timer call the graphic shape again, after the scrolling has finished. Hope that gets you started, feel free to ask again, on freenode irc #dev.openoffice.org, here or on the [EMAIL PROTECTED] mailing list! Cheers, -- Thorsten --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
