On Jul 17, 2007, at 10:09, Christiaan Hofman wrote: > But the whole point /is/ to change the page /before/ doing the > animation. Otherwise there is nothing to animate: it needs to have an > image of both the state before and after, and only after that can > there be an animation.
Yeah, even I realize(d) that :). Getting bitmap imagereps of the pages might work as well (unless presentation mode allows zooming?). > I don't think the window can draw before the animation starts, the > redraw is only done at the end of the event loop, right? That's generally true for things like setNeedsDisplay:, but in this case isn't it reliant on an implementation detail of PDFView's goToNextPage: and goToPreviousPage:? It would be possible for those to tickle the runloop or even flush the window, since they're opaque IBActions. PDFView on Tiger makes things harder to figure out because of its timer. > Otherwise we > could also temporarily disable the flushWindow in > prepareForAnimationWithTransitionStyle:..., to be sure the window > does not flush. That does seem to fix the problem. thanks, Adam ------------------------------------------------------------------------- This SF.net email is sponsored by DB2 Express Download DB2 Express C - the FREE version of DB2 express and take control of your XML. No limits. Just data. Click to get it now. http://sourceforge.net/powerbar/db2/ _______________________________________________ skim-app-develop mailing list skim-app-develop@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/skim-app-develop
