> On 03 Apr 2016, at 21:58, Igor Stasenko <[email protected]> wrote: > > > > On 3 April 2016 at 22:32, Thierry Goubier <[email protected] > <mailto:[email protected]>> wrote: > Le 03/04/2016 20:01, Igor Stasenko a écrit : > > > On 3 April 2016 at 20:51, Thierry Goubier <[email protected] > <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>>> wrote: > > Le 03/04/2016 19:12, Igor Stasenko a écrit : > > > > On 3 April 2016 at 19:48, Thierry Goubier > <[email protected] <mailto:[email protected]> > <mailto:[email protected] <mailto:[email protected]>> > <mailto:[email protected] <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>>> wrote: > > Le 03/04/2016 17:33, stepharo a écrit : > > If you want to change clicking behaviour you need to > override > one single > method. > > > Everything you wrote with unreadable amount of > characters is > for nothing. > > I see clearly point of Igor. And for me it > feels very > logical. > With such design you can lively change > clipping area and > interaction area for any morph (element) on > screen. > > > In short, i see only two cases where indeed, morph > requires > a nothing > of shapes to define: > - clipping region(s) > - ui interaction region(s) > > but for drawing? nooooo... really? who cares what > you draw > there? > draw anything, in any possible way you see fit.. > compose, > decompose, > recombine, blend and mix.. that's the whole purpose of > drawing and be > artistic and be able to express yourself in any > possible way > you want :) > Why nailing and formalizing things that are tend to > be hardly > formalizable and more than that, unnecessary. > That's my main concern about current design. > > > I agree. > I do not see why people are forced to create a submorph > just to > change > the rendering. > If you want to change it dynamically you can for > example pass a > different shape. > > > I don't see the problem with subclassing a morph. > > Me neither. But do you confusing subclassing and submorph > compositing? > > > Let me return you the question then: do you do a composition of > submorphs if you're trying to get a different drawOn:? > > Who, me? No. Maybe i was just misunderstood your reply. > Because what i was tried to demonstrate in previous post(s) that there's > simply no easy way to expose all possible drawing operations via > composition of morphs (or composition of any other kind of elements), > unless, of course you will lift full feature set of Athens to the level > of composition.. > As result you will get a full feature set that Athens provides, plus > extra complexity. > Sounds like thing to do, no? :) > > Agreed :) > > Oh, ok, that's true FastTable does it for the selection... changing > background color by encapsulating a row in another Morph with the > right background color. > > Well, i don't know what is FastTable beast are.. so i cannot comment on > this one. > > I think FastTable is something you should have a look at. Esteban did > something really interesting there. > > In FT, Submorphs are only created when they are about to be displayed: Pharo > can easily create hundreds of morphs on every redraw cycle. So FT performance > is O(k) where k is the number of rows to display on screen (typical k is > ~25), and is O(1) regarding the length of the list (almost: there is a point, > for very large tree-like structures, where just iterating over the structure > becomes the main performance limitation: see FTTree). > > Sounds like right way to do it. There's no point to keep million UI elements > for million items in list, since you never render them all at once on the > screen. So, practical approach is to create as many UI elements as fits on > the screen, but not as many you have in list.
I think that Cocoa list does that. When a list item goes out of the screen it’s sent to a pool, and when a new one has to be displayed they take any one from that pool and re-initialize. > > A FTTableContainerMorph recreates all its submorphs on every drawOn:. I've > played with different variants (do not recreate all submorphs, for example) > but you don't see any performance difference (on the time needed for a > drawOn:). > > Yeah, i did similar thing in TxText - also create morph(s) only for part of > text which is currently displayed.. and basically it is same idea for TxText > itself: it calculates layout only for a portion of text, the portion that > currently displayed, but never for whole text, which can be megabytes long. > Thus, it guarantees that overall performance are bound to the area, covered > by UI control that displays the text, but not to text size. > > > Regards, > > Thierry > > > > > -- > Best regards, > Igor Stasenko.
