I don't think like I want to hack on the system to get normal time response. I will use #render: when it will gets too slow, even if it breaks the beauty of the code. This is the kind of problem where newbie may think Pharo is slow.
Hilaire Le 05/01/2016 18:59, Ben Coman a écrit : > On Tue, Jan 5, 2016 at 10:20 PM, Hilaire <hila...@drgeo.eu> wrote: >> Le 05/01/2016 14:38, Sven Van Caekenberghe a écrit : >>> The problem can does also be restated: it is really necessary for a tool to >>> convert 1000s of items to strings, even if only 10s are shown at the same >>> time on a screen ? >>> >>> I believe that fast table tries to do better here. >> But I need to show 1000s of them once, all in the same view, at the same >> time. > Is it that the same 1000 strings are being rendered multiple times a > second? I had a similar problem with Roassal 1 with a unicode char > massively slowing down to UI. I managed to achieve fairly normal > response time by cached the Freetype calculated width of the string. > I found the right place to do this by both profiling the whole system, > and just the rendering by wrapping MessaeTally around the code of > fullDrawOn: . > > Then I cache both the string and its calculated length from the > rendering code, then if the cached string is the same as current I > just returned the cached length. > > Sorry I can't be clearer. > cheers -ben > > -- Dr. Geo http://drgeo.eu
