- Pharo-dev - lists.pharo.org

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

by Henrik Nergaard

-----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Thierry Goubier Sent: Sunday, April 3, 2016 9:52 PM To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] [bloc] shape size? 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. When pointing it out, I totally agree. Will fix that ;) > 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. No there won't be that complexity, I was thinking of mouse-over not the selection; apologies. There is another reason for moving it into the container, but that reason is not public. Ah, Yes; even/odd color difference per row. > 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 > Best regards, Henrik

April 3, 2016

Bloc, Athens, Pharo5 advice

by J.F. Rick

Hi everybody, I've been off doing a seaside project which really had me using Pharo more than doing anything new to develop for it. Now, I'm in the project where I get to do some more fun stuff on multi-touch interfaces in Pharo. It seems like Pharo has made major progress in that direction so I'd like to take advantage of this progress and also contribute to it. But, I'm a bit confused about the current state, whether it is usable for my project, and how I can contribute to it. First, a little about the hardware I will be working with. At home (development), I have a Dell XPS27 running Ubuntu. It has native multi-touch capabilities. At work (deployment), I have a Mac Mini (OS X) hooked up to a 4k display and get multi-touch information through TUIO. In the past, I used a separate program to turn the Dell touch input into TUIO and then process it inside Pharo (pretty easy). It seems like I should use OSWindow support these days to deal with native input on the Dell and then modify my TUIO adaptor to create those events. Is that correct? If so, how do I get started on that? Do I need a special VM? Is the OSWindow code in Pharo5 or do I need other packages? Last time around (~2 years ago), I started using Athens for rendering multi-touch graphics and it worked fairly well (great fast vector rendering). It seems like Athens has been put into Bloc, which is a framework to replace Morphic. OSWindow support also seems to be linked to Bloc. Is Bloc solid enough where I could use it to create an application? If it is fairly far along, I'd be happy to use it and contribute back to it. Again, is this just in Pharo5 or do I have to load different packages? Is there any documentation I can look at (code examples are fine)? I've already looked at the things I found on Google. Anyway, I'd appreciate any advice on how to get up to speed and perhaps how I can contribute. At minimum, I have some existing multi-touch applications that I could share, thereby giving good demos of Pharo multi-touch capabilities. Cheers, Jeff

April 3, 2016

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

by Damien Pollet

On 3 April 2016 at 12:27, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > However, in most UI of applications (in web, mobile) it is extremely rare > that clipping or event handling areas differ from drawing one (visual one - > one that user sees in the end). A counter-example that immediately comes to mind is Pharo's icon. You could imagine a minimal version of it with just the circle/wave/splash and the striped lighthouse inside (in the current icon, that has been filled with some semi-transparent whiteish gradient). The visual shape has voids (inside the circle, in between the stripesâ¦) but the click-collision mask is basically a full disc. I'm pretty sure an early version of the icon had the same shape for rendering and click-catching, and you had to aim for the small opaque regions in itâ¦ -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

April 3, 2016

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

by Thierry Goubier

Le 03/04/2016 23:31, Igor Stasenko a Ã©crit : > > > On 4 April 2016 at 00:18, Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@gmail.com>> wrote: > > > The scroll is defined in delta in pixels. So, scrolling > single line > - you scroll by top or bottom line height (depending on > direction). > > > You wrote a dedicated scrollbar? The standard one is [0, 1.0] with a > constant step whatever the direction so it's hard to make the > difference in height between the top line or the bottom line. > > > Yes. I, of course did not made it dedicated only for text. But i guess > text is only single user of it so far. Ok. > But it could be worth subclassing ScrollBar for that purpose. > > > Unfortunately, my cognitive capacity was not that high at that moment, > in order to understand how ScrollBar is working and what needs to be > done in order to adapt it to my text model. Or maybe because when i was > looking at its implementation the only thing i was thinking is not to > run screaming in terror. :) > Pick one explanation, that suits you best :) I'm using the same explanation when I see some widgets. I wanted to use a button for expand/unexpand in a tree, looked at the variants of ButtonMorphs (and three state button morphs and...), got a headache and just took a normal Morph with a custom handler :( > Or maybe i lying here.. i could be 'scroll up/down' until > next/previous > line are fully visible in layout. (There's of course an edge > case, when > line height is bigger than viewport height) > > > That edge case is complex to handle... > > 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 ) > > > Understood for the scan forward or backward. > > 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. > > > What do you scan in the text? Do you compute a complete pixel height > of the text or some approximation? > > > Well, for scrollbars it is just counting lines of text. For layout , it > is of course, fully precise text layout & kerning yadda yadda. Understood. Thanks again for all the explanations. Thierry

April 3, 2016

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

by Igor Stasenko

On 4 April 2016 at 00:18, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > >> The scroll is defined in delta in pixels. So, scrolling single line >> - you scroll by top or bottom line height (depending on direction). >> > > You wrote a dedicated scrollbar? The standard one is [0, 1.0] with a > constant step whatever the direction so it's hard to make the difference in > height between the top line or the bottom line. > Yes. I, of course did not made it dedicated only for text. But i guess text is only single user of it so far. > > But it could be worth subclassing ScrollBar for that purpose. Unfortunately, my cognitive capacity was not that high at that moment, in order to understand how ScrollBar is working and what needs to be done in order to adapt it to my text model. Or maybe because when i was looking at its implementation the only thing i was thinking is not to run screaming in terror. Pick one explanation, that suits you best :) > > > Or maybe i lying here.. i could be 'scroll up/down' until next/previous >> line are fully visible in layout. (There's of course an edge case, when >> line height is bigger than viewport height) >> > > That edge case is complex to handle... > > 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 ) >> > > Understood for the scan forward or backward. > > 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. >> > > What do you scan in the text? Do you compute a complete pixel height of > the text or some approximation? > Well, for scrollbars it is just counting lines of text. For layout , it is of course, fully precise text layout & kerning yadda yadda. > > Thanks, > > Thierry > > -- Best regards, Igor Stasenko.

April 3, 2016

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

by Thierry Goubier

Le 03/04/2016 22:46, Igor Stasenko a Ã©crit : > > > On 3 April 2016 at 23:41, Igor Stasenko <siguctua(a)gmail.com > <mailto:siguctua@gmail.com>> wrote: > > > > On 3 April 2016 at 23:30, Thierry Goubier <thierry.goubier(a)gmail.com > <mailto:thierry.goubier@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> > <mailto:thierry.goubier@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>> > <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 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>>> > <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 > <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). You wrote a dedicated scrollbar? The standard one is [0, 1.0] with a constant step whatever the direction so it's hard to make the difference in height between the top line or the bottom line. But it could be worth subclassing ScrollBar for that purpose. > Or maybe i lying here.. i could be 'scroll up/down' until next/previous > line are fully visible in layout. (There's of course an edge case, when > line height is bigger than viewport height) That edge case is complex to handle... > 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 ) Understood for the scan forward or backward. > 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. What do you scan in the text? Do you compute a complete pixel height of the text or some approximation? Thanks, Thierry

April 3, 2016

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

by Igor Stasenko

On 3 April 2016 at 23:41, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > 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). > Or maybe i lying here.. i could be 'scroll up/down' until next/previous line are fully visible in layout. (There's of course an edge case, when line height is bigger than viewport height) > 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. > -- Best regards, Igor Stasenko.

April 3, 2016

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