- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Call for UI gripes

by Igor Stasenko

2009/2/10 Bill Schwab <BSchwab(a)anest.ufl.edu>: > Sig, > > Is it something that could be themed? Then it could be present in the "expensive" themes and left out for a limited theme that would hopefully still look nice, have robust focus behavior, but seeks to be as fast as possible. > A shadow drawing can be controlled by property #hasDropShadow of morph. To allow theme to decide it, morph should ask theme about it. > Bill > > > > > Wilhelm K. Schwab, Ph.D. > University of Florida > Department of Anesthesiology > PO Box 100254 > Gainesville, FL 32610-0254 > > Email: bschwab(a)anest.ufl.edu > Tel: (352) 273-6785 > FAX: (352) 392-7029 > >>>> siguctua(a)gmail.com 02/10/09 7:11 AM >>> > 2009/2/10 David RÃ¶thlisberger <squeak(a)webcitas.ch>: >> Hi Igor, >> >>> OB is quite complex thing, and its hard to understand what it does for >>> outsider :) >>> >>> I just identified a few points, which can improve rendering speed by a >>> certain amount: >> [...] >>> - default. >>> 60 ms >>> >>> - with override in SystemWindow>>drawDropShadowOn: aCanvas to do nothing: >>> 51 ms >>> >>> - with override in OBMonticelloPackageNode>>classCategories to return >>> cached collection >>> 45 ms >>> >> >> I incorporated into OB a patch that is following your idea concerning caching of >> class cats in package nodes. I did it differently than you but the results are even >> better now. >> > > Great! In my patch i didn't care about correctness or whatever, it was > simply to outline what possible can be done to improve rendering > speed. > >> Can you take care of integrating the SystemWindow patch into Pharo? >> > > you mean override of SystemWindow>>drawDropShadowOn: ? > Its not really correct override. Shadow should be drawn, if it there. > And by default , to draw shadow, it using Morph>>drawOn: method with > special shadow canvas. For system window it means that a rectangular > area with dimensions of morph is filled with shadow color, shifted by > shadowOffset. > To improve its speed, we could clip a shadow rectangle to not visit > pixels which is covered my system window contents, only pixels which > are outside of it and 'dropping' shadow. > > I can implement such method, but concerning integration - i'm not in > charge here :) > > What is interesting about shadows, that by default a shadow offset is > 1 pixel wide: > shadowOffset: 1@1 > > this means that unless you using magnifying glass on you display, you > can't really tell if there shadow drawn or not. > Since visual difference is minimal, do anyone can tell, why wasting so > much CPU cycles on it? :) > > >> Thanks, >> David >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

Feb. 10, 2009

[Pharo-project] Problem with linux VM and Pharo

by Damien Cassou

Every 5 minutes or so, my VM crashes and prints: squeak: /tmp/squeak-svn/platforms/unix/vm/sqUnixMemory.c:172: uxGrowMemoryBy: Assertion `newDelta >= 0' failed. Aborted I'm using Squeak VM from SVN. Does that happen to anyone else? -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Bill Schwab

Gary, Space to sides of the buttons?? Perhaps unrelated, but I have been thinking of something similar while poking at Damien's recent dev image. Bottom line, I switched to Soft Squeak and was pleased to see that the OB buttons didn't look quite as (pardon me) UGLY<g> (sorry, but that needed to be said) as they did not long ago. It's getting quite nice. The problem was not the buttons so much as an awkward combination of shape, size and mismatching background color behind them. It would help even more to "do the same thing to the code buttons that has been done to the classes buttons." I hope that makes some sense. Take a look at the browser in soft squeak. Note two rows of buttons "in the middle." The upper row looks nicer than the lower row; a tweak of background color would help a lot, I think?? Soft squeak is a nice theme, and (I assume OB changes) have helped it a lot; it was hard on the eyes for a little while. In replying to something not long ago, you mentioned the range of themes and how they differ in color handling. In particular, Soft Squeak lets the tool colors show through. I have an idea for using that to advantage. The clay rose tint to the debugger is great - it does just the right psychological thing without being too strong. The browser color could be nicer; of course it can be set, but I think we should find another default. I recall playing with blues some time ago, but it can't be too strong due to the label text color. Anybody have any ideas? While I might be setting us up for even more drawing and a speed hit (ignore this if you fear that), it might be nice to render the tool-specific title bar icon in the task bar. That way, we could use the same color for browsers and workspaces, and still have them stand out by icon. The debugger would keep its color, as might the preference browser and other "special purpose" tools. Just some ideas. Thanks for the great work! Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> gazzaguru2(a)btinternet.com 02/10/09 8:25 AM >>> ----- Original Message ----- From: "Damien Pollet" <damien.pollet(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, February 08, 2009 1:52 PM Subject: Re: [Pharo-project] Call for UI gripes > On Sat, Feb 7, 2009 at 17:58, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: >> I suppose I could suggest replacing some of the button bars with more >> compact iconic toolbars. Things like debugging over, into, etc. lend >> themselves well to that. The world menu will not make much sense if we >> ever get one window per shell. > > it was probably already said, but could the other buttons in the > browser use the squarish buttons from the task bar rather than the > current rounded ones that waste a bit of space ? > At present the space to the sides must be reserved as the rounded state of the buttons is not known at the time of creation/initial-layout. I'll have a go at making it more adaptable. >> The biggest concern I have right now is speed. I'm not saying Pharo is >> too slow; I'm simply admitting that I do not know whether it is fast >> enough for some of the things I want to do. > > Agreed. Actually I'm wondering if a very sleek minimalistic theme > would be nice* flat colors, simple lines, very limited complicated > stuff like gradients or shaders* provided the typography, widget > spacing, and color choices are done with taste, I think it can look > quite nice, and would even be more usable than a more flashy theme. > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Gary Chambers

The about-to-be-put-on-SqueakSource version of Polymorph now has theme rendered drop shadow for SystemWindows. A small improvement in speed since CornerRounder still applies to the actual window morph. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Tuesday, February 10, 2009 12:11 PM Subject: Re: [Pharo-project] Call for UI gripes > 2009/2/10 David RÃ¶thlisberger <squeak(a)webcitas.ch>: >> Hi Igor, >> >>> OB is quite complex thing, and its hard to understand what it does for >>> outsider :) >>> >>> I just identified a few points, which can improve rendering speed by a >>> certain amount: >> [...] >>> - default. >>> 60 ms >>> >>> - with override in SystemWindow>>drawDropShadowOn: aCanvas to do >>> nothing: >>> 51 ms >>> >>> - with override in OBMonticelloPackageNode>>classCategories to return >>> cached collection >>> 45 ms >>> >> >> I incorporated into OB a patch that is following your idea concerning >> caching of >> class cats in package nodes. I did it differently than you but the >> results are even >> better now. >> > > Great! In my patch i didn't care about correctness or whatever, it was > simply to outline what possible can be done to improve rendering > speed. > >> Can you take care of integrating the SystemWindow patch into Pharo? >> > > you mean override of SystemWindow>>drawDropShadowOn: ? > Its not really correct override. Shadow should be drawn, if it there. > And by default , to draw shadow, it using Morph>>drawOn: method with > special shadow canvas. For system window it means that a rectangular > area with dimensions of morph is filled with shadow color, shifted by > shadowOffset. > To improve its speed, we could clip a shadow rectangle to not visit > pixels which is covered my system window contents, only pixels which > are outside of it and 'dropping' shadow. > > I can implement such method, but concerning integration - i'm not in > charge here :) > > What is interesting about shadows, that by default a shadow offset is > 1 pixel wide: > shadowOffset: 1@1 > > this means that unless you using magnifying glass on you display, you > can't really tell if there shadow drawn or not. > Since visual difference is minimal, do anyone can tell, why wasting so > much CPU cycles on it? :) > > >> Thanks, >> David >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 10, 2009

Re: [Pharo-project] [ANN][Dev-Images] February 2009 versions

by Bill Schwab

Damien, If it is really not a problem, I would like to try it. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> damien.cassou(a)gmail.com 02/10/09 8:16 AM >>> On Tue, Feb 10, 2009 at 1:58 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Is there a Pharo-web link? Apologies if I'm missing the obvious. I'm not generating pharo-web images because nobody asked as far as I remember. Do you want one? (that won't cost much don't worry :-)) -- Damien Cassou http://damiencassou.seasidehosting.st _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 10, 2009

Re: [Pharo-project] another slice for popups cleaning and somequestions

by Gary Chambers

The UIManager remains, at present, netural to the specific implementation, be it Polymorph, Morphic or otherwise. Regards, Gary ----- Original Message ----- From: "StÃ©phane Ducasse" <stephane.ducasse(a)inria.fr> To: <Pharo-project(a)lists.gforge.inria.fr>; <alain.plantec(a)free.fr> Sent: Monday, February 09, 2009 8:59 AM Subject: Re: [Pharo-project] another slice for popups cleaning and somequestions > > On Feb 8, 2009, at 11:57 PM, Alain Plantec wrote: > >> Hi all, >> I've uploaded another slice for popup and co cleaning >> (SLICE-MorePopUpAndCustomMenuCleaning-alain_plantec.1) >> - it Removes last PopUpMenu references. >> - it Removes some of CustomMenu uses (wherever it is possible to >> replace >> it with a simpler UIManager dialog). > > Excellent >> >> >> I've three questions: >> - EmphasizedMenu is never used, can we remove it ? > > I imagine > >> - MorphicUIManager is subclassed by PSUIManager which is now the >> default UIManager. Several MorphicUImanager methods are >> redefined in PSUIManager. So I guess one can simply remove >> MorphicUIManager versions. Is it ok to do so ? (as an example, >> #chooseDirectory:from:, in MorphicUIManager, the code is using >> FileList >> but now we have the PSUIManager version) > > this is the question of how far Polymorph should be integrated. > For me I would really remove the old code when it is not good. > > Ideally I would like to see what can be moved from polymorph to base > Morphic > in the case we would like to have several Polymorph like frameworks. > Then I would clean part of Morphic that are not used or left over of > experiements. > > But this would be good to discuss that > >> - last unrelated question, I've also seen that ListParagraph is never >> used, can we remove it ? > > Do not know > >> >> >> now I am about to see how to kill MVCMenuMorph > > Good >> >> >> cheers >> alain >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Gary Chambers

----- Original Message ----- From: "Damien Pollet" <damien.pollet(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, February 08, 2009 1:52 PM Subject: Re: [Pharo-project] Call for UI gripes > On Sat, Feb 7, 2009 at 17:58, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: >> I suppose I could suggest replacing some of the button bars with more >> compact iconic toolbars. Things like debugging over, into, etc. lend >> themselves well to that. The world menu will not make much sense if we >> ever get one window per shell. > > it was probably already said, but could the other buttons in the > browser use the squarish buttons from the task bar rather than the > current rounded ones that waste a bit of space ? > At present the space to the sides must be reserved as the rounded state of the buttons is not known at the time of creation/initial-layout. I'll have a go at making it more adaptable. >> The biggest concern I have right now is speed. I'm not saying Pharo is >> too slow; I'm simply admitting that I do not know whether it is fast >> enough for some of the things I want to do. > > Agreed. Actually I'm wondering if a very sleek minimalistic theme > would be niceâ¦ flat colors, simple lines, very limited complicated > stuff like gradients or shadersâ¦ provided the typography, widget > spacing, and color choices are done with taste, I think it can look > quite nice, and would even be more usable than a more flashy theme. > > -- > Damien Pollet > type less, do more [ | ] http://people.untyped.org/damien.pollet > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Gary Chambers

Rounded things are tricky to do with no direct support in canvas/balloon. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua(a)gmail.com> To: <Pharo-project(a)lists.gforge.inria.fr> Sent: Sunday, February 08, 2009 1:55 PM Subject: Re: [Pharo-project] Call for UI gripes > I'm also want to play with rounding and compare the efficiency of > drawing an initially rounded shape (by using curves) instead of > hacking , which CornerRounder does. > > I took a single rounded button and measured how fast it get drawn and > what parts of drawing process takes what time: > > 100 times > - fulldraw 80ms > - (1) draw 18ms (simple fill a rectangle) > - (2) fulldraw w/o rounding 51ms (almost same as a fulldraw but w/o > use of CorderRounder) > > so, CornerRounder takes 30ms for itself (from total 80ms). > I think if we initially draw a rounded shape, we could have better > numbers , i hoping that drawing a filled rectangular shape and filled > rounded rectangular shape could have much less difference (much less > than 30ms). > It's a bit expensive to spend 3/8 of total rendering time for such > little fancy thing :) > > 2009/2/8 Igor Stasenko <siguctua(a)gmail.com>: >> 2009/2/8 Gary Chambers <gazzaguru2(a)btinternet.com>: >>> I'll make the drop shadows themable for system windows. >>> The default way Morphic does drop shadows is quite inefficient. >>> >> >> Right, i think it would be wise to provide own implementation of >> drawDropShadowOn: for SystemWindow, to draw simple rectangle (or group >> of rectangles to avoid excessive fills) since we know that >> systemwindow is rectangular beforehead. >> >> >>> Regards, Gary >>> >>> ----- Original Message ----- >>> From: "Igor Stasenko" <siguctua(a)gmail.com> >>> To: <Pharo-project(a)lists.gforge.inria.fr> >>> Sent: Saturday, February 07, 2009 7:23 PM >>> Subject: Re: [Pharo-project] Call for UI gripes >>> >>> >>>> 2009/2/7 Ramon Leon <ramon.leon(a)allresnet.com>: >>>>>> The biggest concern I have right now is speed. I'm not >>>>>> saying Pharo is too slow; I'm simply admitting that I do not >>>>>> know whether it is fast enough for some of the things I want to do. >>>>> >>>>> +10 to this. >>>>> >>>>> The UI is looking really great lately, but overall the experience is >>>>> it's >>>>> just too slow. Cracking open a raw squeak base image reminds me how >>>>> snappy >>>>> the UI used to be. Not really complaining, it's totally bearable, but >>>>> it'd >>>>> sure be nice if the pretty UI was quick and snappy, and you are >>>>> asking. >>>>> >>>> Sure thing >>>> MessageTally spyOn:[self fullDrawOn: World assuredCanvas] "where self >>>> is an OB system window morph" >>>> >>>> 16.7% {10ms} BalloonEngine>>copyLoopFaster >>>> 11.7% {7ms} SimpleBorder>>frameRectangle:on: >>>> 6.7% {4ms} Array(SequenceableCollection)>>select: >>>> 5.0% {3ms} ByteString(String)>>= >>>> 5.0% {3ms} SmallInteger(Number)>>to:by:do: >>>> 5.0% {3ms} GrafPort(BitBlt)>>primDisplayString:from:to:map:xTable:kern: >>>> 5.0% {3ms} BorderStyle>>frameRectangle:on: >>>> 3.3% {2ms} ByteSymbol>>species >>>> 3.3% {2ms} ByteString class(String class)>>new: >>>> >>>> total 61ms. >>>> >>>> some hot points crying to be optimized: >>>> cache the OBMonticelloPackageNode>>classCategories , which get >>>> rebuilt each time you draw the window. >>>> this can make following numbers much smaller: >>>> 5.0% {3ms} ByteString(String)>>= >>>> 6.7% {4ms} Array(SequenceableCollection)>>select: >>>> 3.3% {2ms} ByteString class(String class)>>new: >>>> >>>> Making SystemWindow>>drawDropShadowOn: to do nothing makes a >>>> difference: >>>> >>>> [10 timesRepeat: [self fullDrawOn: World assuredCanvas ]] timeToRun >>>> with shadows: 530 >>>> without: 473 >>>> ~ 10% speedup >>>> >>>> Changing the theme makes some difference (no shadows/with shadows): >>>> - Watery 2: 50/60 ms >>>> - Standard Squeak: 38/43 ms >>>> - Soft Squeak: 46/55 ms >>>> - Vistary: 56/62ms >>>> (keep in mind these numbers are polluted with messageTally) >>>> >>>> As to me, the theme variancy is quite acceptable - a most complex >>>> theme (with transulency) is drawn just 50% slower than most simple >>>> one. >>>> >>>> As for, >>>> 3.3% {2ms} ByteString class(String class)>>new: >>>> >>>> Total count of ByteString>>new: calls during >>>> GlobalCounter reset. >>>> self fullDrawOn: World assuredCanvas. >>>> GlobalCounter counters copy inspect >>>> >>>> is 7146, >>>> which again makes me look suspicious at OB here.. Hey! Are we drawing, >>>> or processing a text?!?! >>>> >>>> >>>>> Ramon Leon >>>>> http://onsmalltalk.com >>>>> >>>>> >>>>> _______________________________________________ >>>>> Pharo-project mailing list >>>>> Pharo-project(a)lists.gforge.inria.fr >>>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 10, 2009

Re: [Pharo-project] [ANN][Dev-Images] February 2009 versions

by Damien Cassou

On Tue, Feb 10, 2009 at 1:58 PM, Bill Schwab <BSchwab(a)anest.ufl.edu> wrote: > Is there a Pharo-web link? Apologies if I'm missing the obvious. I'm not generating pharo-web images because nobody asked as far as I remember. Do you want one? (that won't cost much don't worry :-)) -- Damien Cassou http://damiencassou.seasidehosting.st

Feb. 10, 2009

Re: [Pharo-project] Call for UI gripes

by Bill Schwab

Sig, Is it something that could be themed? Then it could be present in the "expensive" themes and left out for a limited theme that would hopefully still look nice, have robust focus behavior, but seeks to be as fast as possible. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab(a)anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029 >>> siguctua(a)gmail.com 02/10/09 7:11 AM >>> 2009/2/10 David RÃ¶thlisberger <squeak(a)webcitas.ch>: > Hi Igor, > >> OB is quite complex thing, and its hard to understand what it does for >> outsider :) >> >> I just identified a few points, which can improve rendering speed by a >> certain amount: > [...] >> - default. >> 60 ms >> >> - with override in SystemWindow>>drawDropShadowOn: aCanvas to do nothing: >> 51 ms >> >> - with override in OBMonticelloPackageNode>>classCategories to return >> cached collection >> 45 ms >> > > I incorporated into OB a patch that is following your idea concerning caching of > class cats in package nodes. I did it differently than you but the results are even > better now. > Great! In my patch i didn't care about correctness or whatever, it was simply to outline what possible can be done to improve rendering speed. > Can you take care of integrating the SystemWindow patch into Pharo? > you mean override of SystemWindow>>drawDropShadowOn: ? Its not really correct override. Shadow should be drawn, if it there. And by default , to draw shadow, it using Morph>>drawOn: method with special shadow canvas. For system window it means that a rectangular area with dimensions of morph is filled with shadow color, shifted by shadowOffset. To improve its speed, we could clip a shadow rectangle to not visit pixels which is covered my system window contents, only pixels which are outside of it and 'dropping' shadow. I can implement such method, but concerning integration - i'm not in charge here :) What is interesting about shadows, that by default a shadow offset is 1 pixel wide: shadowOffset: 1@1 this means that unless you using magnifying glass on you display, you can't really tell if there shadow drawn or not. Since visual difference is minimal, do anyone can tell, why wasting so much CPU cycles on it? :) > Thanks, > David > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list Pharo-project(a)lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 10, 2009