Community
Participate
Working Groups
Build Identifier: HEAD We have a diagram where we use panning tool to pan on the diagram. Whilst developing this diagram, we have discovered the painting process is quite jumpy and flickering only if panning is done on both X and Y axises. Looking at the code for FigureCanvas, there is an obvious optimization if scrollTo results in scrolling in only on X or Y direction. With the patch we perceive a highly noticeable better performance when scroll is in arbitrary direction (panning). Hope this improvement makes its way into gef sources. Reproducible: Always Steps to Reproduce: 1. use the panning tool in examples 2. pay attention to jumpy / flickering paint performance as user pans in both X and Y direction 3. try the same with scroll bars (which scrolls only on one axis at a time) 4. apply the patch and repeat 1,2,3.
Created attachment 179377 [details] patch to use scroll optimization more as possible
doesn't calling scrollToX and then scrollToY cause the canvas to paint in the intermediate position?
(In reply to comment #2) > doesn't calling scrollToX and then scrollToY cause the canvas to paint in the > intermediate position? In theory yes. But in practise actual painting occurs 'deferred' therefore no actual painting occurs in intermediate phase. Is that the right answer or am I interpreting the question wrong?
(In reply to comment #3) > In theory yes. But in practise actual painting occurs 'deferred' therefore no > actual painting occurs in intermediate phase. > > Is that the right answer or am I interpreting the question wrong? From Canvas#scroll: * In addition, outstanding * paint events are flushed before the source area is copied to * ensure that the contents of the canvas are drawn correctly. So the 'deferred' paint from the first scroll call is forced to occur before the next call to scroll can proceed.
Randy, Obviously I am no UI expert and I appreciate your knowledge in the area. However, in our case this solution does speed up scrolls in arbitrary directions drastically and we cannot spot any distortion in the way the diagram is painted. I assume the discussion we are currently having is whether with this solution in intermediate states after scrollX will be shifted afterwards with ScrollY - therefore supposedly we'll end up with a distorted canvas, am I right? If that's the discussion, I do get a perfect drawing on the screen plus a huge performance gain.
No, I wasn't suggesting that the final result would be distorted. I was just saying the user might briefly see the intermediate position before seeing the final position. If you were animating a diagonal scroll, it might look like stair-steps instead of a straight line.
(In reply to comment #6) > No, I wasn't suggesting that the final result would be distorted. I was just > saying the user might briefly see the intermediate position before seeing the > final position. If you were animating a diagonal scroll, it might look like > stair-steps instead of a straight line. Oh I see what you mean... Yes that's the case currently. I'll see if I can avoid that...
Randy, I experimented using gc.copyArea which (at least for windows) has the exact same behaviour - If scrolled in both directions the whole viewport is asked to repaint. I see no way of asking canvas to paint only the damaged horizontal and vertical border inset to paint - correct? Nevertheless I see a great gain in drawing smoothly in case of panning with this approach and I think it would be a good idea to make this at least configurable. On the if I do understand your concern in animated implementation, THE intermediate state might be the state might be the animation step, if I do get this correctly then I doubt that this is the case since scroll(s) will issue synchronous paint events. Meanwhile I also noticed that in case of a diagonal scroll (panning), the viewport is invalidated which at least invalidates the connections and makes the update manager go through a series of calculations. These are my 2c. I managed to stick in a self-overriden FigureCanvas which implements the behaviour I like in the patch. In the meantime my immediate requirement is satisfied. whether GEF may benefit from this experiences, it is up to you. Again, thanks for providing your valuable thoughts on this issue and feel free to reject if you disagree... Regards, Hasan Ceylan
