[Pharo-project] [newbies] How can I diagnose kinetic scrolling screen flicker?
Hello all, in my (first) pharo programm, I have a pane with apx 100 Morphs. The pane can be zoomed and scrolled both vertically and horizontally. The horizontal scrolling means scrolling time and is self-written. I implemented some sort of kinetic scrolling using the mouse wheel, where a scroll destination is set and in a step method I halve the distance to the destination with each step. This looks kind of nice, but not nice enough. Scrolling is not as smooth as I had hoped. Sometimes there is a delay between the wheel move and the display actually showing some motion. Also I have the impression, that not all parts of the pane are redrawn at the same time. Morphs which are exactly below each other, appear minimally skewed during the scroll. Strange enough the zooming, which has to do about the same underlying geometry calculations is a lot more snappy (but not kinetic). Likewise the vertical scrolling which used a StandardScrollPane appears more snappy. I looks like using a stepper is the root of the problem. I just could not figure out where the time goes. I put a MessageTally into the step method, only to find out, that doing 1000 steps takes less than a second. So the problem must be elsewehere. Any ideas would be much appreciated. -- Martin
Don't know how to solve your smooth zooming problem, but have a look at Dr Geo: zooming is very smooth there! - Francisco On 1 May 2012, at 12:24, Martin Drautzburg <Martin.Drautzburg@web.de> wrote:
Hello all,
in my (first) pharo programm, I have a pane with apx 100 Morphs. The pane can be zoomed and scrolled both vertically and horizontally. The horizontal scrolling means scrolling time and is self-written. I implemented some sort of kinetic scrolling using the mouse wheel, where a scroll destination is set and in a step method I halve the distance to the destination with each step.
This looks kind of nice, but not nice enough. Scrolling is not as smooth as I had hoped. Sometimes there is a delay between the wheel move and the display actually showing some motion. Also I have the impression, that not all parts of the pane are redrawn at the same time. Morphs which are exactly below each other, appear minimally skewed during the scroll.
Strange enough the zooming, which has to do about the same underlying geometry calculations is a lot more snappy (but not kinetic). Likewise the vertical scrolling which used a StandardScrollPane appears more snappy.
I looks like using a stepper is the root of the problem. I just could not figure out where the time goes. I put a MessageTally into the step method, only to find out, that doing 1000 steps takes less than a second. So the problem must be elsewehere.
Any ideas would be much appreciated.
-- Martin
Ensuring your drawOn: is fast is crucial for good frame-rate. Try profiling all processes, that should reveal something.. On Tue, May 1, 2012 at 6:24 AM, Martin Drautzburg <Martin.Drautzburg@web.de> wrote:
Hello all,
in my (first) pharo programm, I have a pane with apx 100 Morphs. The pane can be zoomed and scrolled  both vertically and horizontally. The horizontal scrolling means scrolling time and is self-written. I implemented some sort of kinetic scrolling using the mouse wheel, where a scroll destination is set and in a step method I halve the distance to the destination with each step.
This looks kind of nice, but not nice enough. Scrolling is not as smooth as I had hoped. Sometimes there is a delay between the wheel move and the display actually showing some motion. Also I have the impression, that not all parts of the pane are redrawn at the same time. Morphs which are exactly below each other, appear minimally skewed during the scroll.
Strange enough the zooming, which has to do about the same underlying geometry calculations is a lot more snappy (but not kinetic). Likewise the vertical scrolling which used a StandardScrollPane appears  more snappy.
I looks like using a stepper is the root of the problem. I just could not figure out where the time goes. I put a MessageTally into the step method, only to find out, that doing 1000 steps takes less than a second. So the problem must be elsewehere.
Any ideas would be much appreciated.
-- Martin
On Wednesday, 2. May 2012 01:28:19 Chris Muller wrote:
Ensuring your drawOn: is fast is crucial for good frame-rate.
Try profiling all processes, that should reveal something..
Thanks. Did that (kind of). I appears that I had some kind of layout loop, where an owner morph rearranges its children in a self written #doLayoutIn: method. However the child morphs seem to issue a #layoutChanged when moved. The thing is: I have to scroll an infinite horizontal "ribbon", and I am sure that changed horizontal positions of submorphs do not cause any parent to require re-layouting (other than clipping). I ended up overwriting #position: in the child morphs, such that #layoutChanged is no longer called and I let the parent rearrange its submorphs in a #timeChanged method rather than #doLayout. But I am still not happy with the code. You don't just move submorphs around with the usual #left: #right methods and friends when a parent morph enforces a particular layout, right?
On Wednesday, 2. May 2012 01:28:19 Chris Muller wrote:
Ensuring your drawOn: is fast is crucial for good frame-rate.
Try profiling all processes, that should reveal something..
How exactly do I do this? I tried to get some profiles of my method, but I don't see the actual drawing. When I add a #displayWorldSafely I have the feeling that morphic redraws everything and I see redraws of the Browser etc. -- Martin
participants (3)
-
Chris Muller -
Francisco Garau -
Martin Drautzburg