April 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [bloc] shape size?

by Igor Stasenko

On 3 April 2016 at 23:30, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 03/04/2016 21:58, Igor Stasenko a Ã©crit : > >> >> >> On 3 April 2016 at 22:32, Thierry Goubier <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com>> wrote: >> >> Le 03/04/2016 20:01, Igor Stasenko a Ã©crit : >> >> >> >> On 3 April 2016 at 20:51, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com> >> <mailto:thierry.goubier@gmail.com >> <mailto:thierry.goubier@gmail.com>>> wrote: >> >> Le 03/04/2016 19:12, Igor Stasenko a Ã©crit : >> >> >> >> On 3 April 2016 at 19:48, Thierry Goubier >> <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com> >> <mailto:thierry.goubier@gmail.com >> <mailto:thierry.goubier@gmail.com>> >> <mailto:thierry.goubier@gmail.com >> <mailto:thierry.goubier@gmail.com> >> >> <mailto:thierry.goubier@gmail.com >> <mailto:thierry.goubier@gmail.com>>>> 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. >> >> 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:). >> > > Well, as Henrik pointed out, not everytime ;) > > 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. >> > > I'm interested to know how you handle scrolling then: how do you define > the step, the length and the position: relative to the number of characters > displayed / start character of the current UI / and knowing the number of > characters in the whole text, so that you are independent of the layout? > > The scroll is defined in delta in pixels. So, scrolling single line - you scroll by top or bottom line height (depending on direction). Scrolling page - you scroll by using height of viewport. No need to count lines of text. And so, i scan text forward or backward until new layout fully covers part of text after such scrolling. And after it deleting portion of layout that became invisible due to scrolling. The layout has anchor point in text - a position. And then dimensions (width and height) and offset (a delta horizontal or vertical relative to perfect condition when a position in text corresponds to 0,0 point in layout ) The only place where i needed to measure text size was to positioning a scrollbar knob to represent its size & vertical position approximately close to where you in text and text size. And i really don't like that, since it requires scanning whole text.. But well... tradeoffs.. It win anyways, since i succeeded to avoid most operations to be bound to text size. And only few left, that you cannot avoid. Regards, > > Thierry > > -- Best regards, Igor Stasenko.

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Thierry Goubier

Le 03/04/2016 22:26, Igor Stasenko a Ã©crit : > > > On 3 April 2016 at 23:00, Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>> wrote: > > Le 03/04/2016 21:51, Henrik Nergaard a Ã©crit : > > A FTTableContainerMorph recreates all its submorphs on every > drawOn:. > > Not correct. > > > Ok. I stand corrected. This is why it is done in #drawOn: and not > #drawSubmorphsOn: > > Submorphs are only recreated when the view of the list has changed > #canRefreshValues, ie if the variable "needsRefreshExposedRows" is > set to true. If this is false nothing will happen in #drawOn: > > If changes is necessary the drawOn: will recreate submorphs for the > current view (showIndex) and set the "needsRefreshedExposedRows" to > false signalling that it is correctly laid out. > > > What is interesting, still, is that submorphs rebuilding (deleting > and recreating them) happens during a #drawOn: call, and that it is > fast enough not to register on the time needed for a world redraw. > > And so I still think it is interesting for Igor to have a look at FT :) > > Only for review purpose, i guess. From what you described, as i wrote in > previous post this is not new to me. I think i seen some kind of > morph(s) that was using same technique in the past. it may be different > in details, of course, but overall idea was same: create and use as many > UI elements, as many fits on the screen, not as many items in the list(s) Yes, probably. Regards, Thierry

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Thierry Goubier

Le 03/04/2016 21:58, Igor Stasenko a Ã©crit : > > > On 3 April 2016 at 22:32, Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>> wrote: > > Le 03/04/2016 20:01, Igor Stasenko a Ã©crit : > > > > On 3 April 2016 at 20:51, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com> > <mailto:thierry.goubier@gmail.com > <mailto:thierry.goubier@gmail.com>>> wrote: > > Le 03/04/2016 19:12, Igor Stasenko a Ã©crit : > > > > On 3 April 2016 at 19:48, Thierry Goubier > <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com> > <mailto:thierry.goubier@gmail.com > <mailto:thierry.goubier@gmail.com>> > <mailto:thierry.goubier@gmail.com > <mailto:thierry.goubier@gmail.com> > > <mailto:thierry.goubier@gmail.com > <mailto:thierry.goubier@gmail.com>>>> 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. > > 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:). Well, as Henrik pointed out, not everytime ;) > 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. I'm interested to know how you handle scrolling then: how do you define the step, the length and the position: relative to the number of characters displayed / start character of the current UI / and knowing the number of characters in the whole text, so that you are independent of the layout? Regards, Thierry

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Igor Stasenko

On 3 April 2016 at 23:00, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 03/04/2016 21:51, Henrik Nergaard a Ã©crit : > >> A FTTableContainerMorph recreates all its submorphs on every >>> drawOn:. >>> >> Not correct. >> > > Ok. I stand corrected. This is why it is done in #drawOn: and not > #drawSubmorphsOn: > > Submorphs are only recreated when the view of the list has changed >> #canRefreshValues, ie if the variable "needsRefreshExposedRows" is >> set to true. If this is false nothing will happen in #drawOn: >> >> If changes is necessary the drawOn: will recreate submorphs for the >> current view (showIndex) and set the "needsRefreshedExposedRows" to >> false signalling that it is correctly laid out. >> > > What is interesting, still, is that submorphs rebuilding (deleting and > recreating them) happens during a #drawOn: call, and that it is fast enough > not to register on the time needed for a world redraw. > > And so I still think it is interesting for Igor to have a look at FT :) > > Only for review purpose, i guess. From what you described, as i wrote in previous post this is not new to me. I think i seen some kind of morph(s) that was using same technique in the past. it may be different in details, of course, but overall idea was same: create and use as many UI elements, as many fits on the screen, not as many items in the list(s) > Regards, > > Thierry > > -- Best regards, Igor Stasenko.

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Yuriy Tymchuk

> On 03 Apr 2016, at 21:58, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 3 April 2016 at 22:32, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com>> wrote: > Le 03/04/2016 20:01, Igor Stasenko a Ã©crit : > > > On 3 April 2016 at 20:51, Thierry Goubier <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com> > <mailto:thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>> wrote: > > Le 03/04/2016 19:12, Igor Stasenko a Ã©crit : > > > > On 3 April 2016 at 19:48, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com> <mailto:thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>> > <mailto:thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com> > > <mailto:thierry.goubier@gmail.com <mailto:thierry.goubier@gmail.com>>>> 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.

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Thierry Goubier

Le 03/04/2016 21:51, Henrik Nergaard a Ã©crit : >> A FTTableContainerMorph recreates all its submorphs on every >> drawOn:. > Not correct. Ok. I stand corrected. This is why it is done in #drawOn: and not #drawSubmorphsOn: > Submorphs are only recreated when the view of the list has changed > #canRefreshValues, ie if the variable "needsRefreshExposedRows" is > set to true. If this is false nothing will happen in #drawOn: > > If changes is necessary the drawOn: will recreate submorphs for the > current view (showIndex) and set the "needsRefreshedExposedRows" to > false signalling that it is correctly laid out. What is interesting, still, is that submorphs rebuilding (deleting and recreating them) happens during a #drawOn: call, and that it is fast enough not to register on the time needed for a world redraw. And so I still think it is interesting for Igor to have a look at FT :) Regards, Thierry

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Igor Stasenko

On 3 April 2016 at 22:32, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > Le 03/04/2016 20:01, Igor Stasenko a Ã©crit : > >> >> >> On 3 April 2016 at 20:51, Thierry Goubier <thierry.goubier(a)gmail.com >> <mailto:thierry.goubier@gmail.com>> wrote: >> >> Le 03/04/2016 19:12, Igor Stasenko a Ã©crit : >> >> >> >> On 3 April 2016 at 19:48, Thierry Goubier >> <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com> >> <mailto:thierry.goubier@gmail.com >> >> <mailto:thierry.goubier@gmail.com>>> 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. > 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.

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Thierry Goubier

Hi Henrik, Le 03/04/2016 21:32, Henrik Nergaard a Ã©crit : > I changed it mostly because it was messing up the color when you did > mouse-over (required to check the owner color to set it correctly when > there was a selection, the code was ugly and with corner cases). Ok. > Encapsulating a morph with another morph just for a background color > is kind of waste IMO. Causing unnecessary overhead for > rendering/layout/eventHandling etc... Rendering maybe a bit. Layout, maybe a bit. Event handling? Oh well, row morphs contents are already a tree of morphs at least 3 deep, what will be the effect of one more doing nothing? > Mesurable? Donât think I checked, but in the long run there is less allocations, less layout etc.. I guess that, given how FT works, it is hidden in the number of Morph creation per drawOn: :) > I would also argue that > ------------------ > (highligtedRowIndexes includes: rowIndex) ifTrue: [ > row selectionColor: (self owner colorForSelection: > primarySelectionIndex = rowIndex) ]. > ----------------- > Is better than > ----------------- > > rowSubviews add: ((highligtedRowIndexes includes: rowIndex) > ifTrue: [ > "IMPORTANT: I need to set owner to nil because otherwise it will trigger an > invalidation of the owner when adding morph to selectionMorph, causing an > infinite loop" > self > toSelectionRow: (row privateOwner: nil) > primary: primarySelectionIndex = rowIndex ] > ifFalse: [ row ]) ]. > ----------------------- I like the game with #privateOwner: in the FT code. Tells you a lot about ownership in Morphic :) At the same time, your new code isn't very clear. It is written just as the setting of a theme property where in fact it is setting the row as selected. > Selection could be and drawn by the container, but then again you > would need much more code and special logic (updating the damageRecorder > with correct rectangles when selection changes for example) than to just > extend and specialize one morph to be a row. I'm doing the selection draw by container, and, honestly, there is none of the complexity you describe. Selection is a model operation anyway, so it usually triggers a redraw (because selection may move you elsewhere, if the model so chooses); if you have some caching in place (that FT hasn't), you gain a bit upon redraw, but nothing noticeable. There is another reason for moving it into the container, but that reason is not public. > I would much rather prefer one specialized morph doing its thing, than encapsulate it. I think the FTTableRowMorph has other duties anyway, so giving him that additional role is fine. Regards, Thierry > Best regards, > Henrik > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Thierry Goubier > Sent: Sunday, April 3, 2016 8:58 PM > To: Pharo Development List <pharo-dev(a)lists.pharo.org> > Subject: Re: [Pharo-dev] [bloc] shape size? > > Le 03/04/2016 20:00, Henrik Nergaard a Ã©crit : >> >>> Let me return you the question then: do you do a composition of >>> submorphs if you're trying to get a different drawOn:? >> >>> 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. >> >> Did, not anymore. >> >> FTTableRowMorph>>#selectionColor: > > Had to check the following code to be sure: > > (highligtedRowIndexes includes: rowIndex) ifTrue: [ > row selectionColor: (self owner colorForSelection: > primarySelectionIndex = rowIndex) ]. > > Was there a measurable inpact when changing that? > > Because I have now three ways of doing this, and all of them have trade-offs. For example the one above suppose that row items are a specific kind of Morph, i.e. FTTableRowMorph; one could do without a dedicated Morph subclass for rows and display the selection as a transparent colored rectangle over the row; this is what I do. > > Thierry >

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Henrik Nergaard

>A FTTableContainerMorph recreates all its submorphs on every drawOn:. Not correct. Submorphs are only recreated when the view of the list has changed #canRefreshValues, ie if the variable "needsRefreshExposedRows" is set to true. If this is false nothing will happen in #drawOn: If changes is necessary the drawOn: will recreate submorphs for the current view (showIndex) and set the "needsRefreshedExposedRows" to false signalling that it is correctly laid out. Best regards, Henrik -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Thierry Goubier Sent: Sunday, April 3, 2016 9:32 PM To: Pharo Development List <pharo-dev(a)lists.pharo.org> Subject: Re: [Pharo-dev] [bloc] shape size? 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). 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:). Regards, Thierry

April 3, 2016

Re: [Pharo-dev] [bloc] shape size?

by Thierry Goubier

Le 03/04/2016 20:01, Igor Stasenko a Ã©crit : > > > On 3 April 2016 at 20:51, Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>> wrote: > > Le 03/04/2016 19:12, Igor Stasenko a Ã©crit : > > > > On 3 April 2016 at 19:48, Thierry Goubier > <thierry.goubier(a)gmail.com <mailto:thierry.goubier@gmail.com> > <mailto:thierry.goubier@gmail.com > <mailto:thierry.goubier@gmail.com>>> 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). 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:). Regards, Thierry

April 3, 2016