February 2009 - Pharo-dev - lists.pharo.org

Re: [Pharo-project] Call for UI gripes

by StÃ©phane Ducasse

Tx igor. :) I'm looking for examples to teach people how to benchmark. Stef On Feb 8, 2009, at 5:42 PM, Igor Stasenko wrote: > for automated benchmarking i can imagine something like following: > > benchButton > | browser button canvas time | > browser := OBPackageBrowser openOnClass: Object selector: #yourself. > browser position: 0@0. > button := browser allMorphs detect: [:m | (m > isKindOf:PluggableButtonMorph ) and: [ m label = 'browse' ]]. > > canvas := World assuredCanvas. > time := [1000 timesRepeat: [ button fullDrawOn: canvas ]] timeToRun. > browser delete. > ^ time > > > -- > 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. 8, 2009

Re: [Pharo-project] Call for UI gripes

by Igor Stasenko

for automated benchmarking i can imagine something like following: benchButton | browser button canvas time | browser := OBPackageBrowser openOnClass: Object selector: #yourself. browser position: 0@0. button := browser allMorphs detect: [:m | (m isKindOf:PluggableButtonMorph ) and: [ m label = 'browse' ]]. canvas := World assuredCanvas. time := [1000 timesRepeat: [ button fullDrawOn: canvas ]] timeToRun. browser delete. ^ time -- Best regards, Igor Stasenko AKA sig.

Feb. 8, 2009

Re: [Pharo-project] Call for UI gripes

by Igor Stasenko

2009/2/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: >> >>> Igor could you give us the snippets for the benchmarks. >>> I would like to use them as example for a forthcoming chapter on >>> profiling. >>> >> >> What exactly snippets you want? > > the one where you create the button and how you measure it :) heh.. why i should care to create a button, when i got plenty of them on the screen? :) i simply clicking through morphs until i got button morph halo, and then doing 'inspect morph'. the rest is then trivial, in inspector window you can send any messages to this morph, like: self drawOn: World assuredCanvas. ;) > >> >> I'm using most simple ways to measure performance, including: >> >> [ .... ] timeToRun. >> or >> MessageTally spyOn: [...] >> >> i made a simple class GlobalCounter >> >> to use a >> GlobalCounter increment: 'some id' >> >> in methods i'm interested in and then run some code like following: >> >> GlobalCounter reset. >> mycode run. >> GlobalCounter counters copy "inspect" >> >> GlobalCounter implementation is trivial, i don't think it requires any >> explanation how it works :) >> >>> Stef >>> >>> On Feb 8, 2009, at 2:55 PM, Igor Stasenko wrote: >>> >>>> 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 >>>> >>> >>> >>> _______________________________________________ >>> 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. >> <GlobalCounter.st>_______________________________________________ >> 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. 8, 2009

Re: [Pharo-project] Call for UI gripes

by StÃ©phane Ducasse

> >> Igor could you give us the snippets for the benchmarks. >> I would like to use them as example for a forthcoming chapter on >> profiling. >> > > What exactly snippets you want? the one where you create the button and how you measure it :) > > I'm using most simple ways to measure performance, including: > > [ .... ] timeToRun. > or > MessageTally spyOn: [...] > > i made a simple class GlobalCounter > > to use a > GlobalCounter increment: 'some id' > > in methods i'm interested in and then run some code like following: > > GlobalCounter reset. > mycode run. > GlobalCounter counters copy "inspect" > > GlobalCounter implementation is trivial, i don't think it requires any > explanation how it works :) > >> Stef >> >> On Feb 8, 2009, at 2:55 PM, Igor Stasenko wrote: >> >>> 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 >>> >> >> >> _______________________________________________ >> 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. > <GlobalCounter.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

Feb. 8, 2009

Re: [Pharo-project] Call for UI gripes

by Igor Stasenko

2009/2/8 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr>: > Igor could you give us the snippets for the benchmarks. > I would like to use them as example for a forthcoming chapter on > profiling. > What exactly snippets you want? I'm using most simple ways to measure performance, including: [ .... ] timeToRun. or MessageTally spyOn: [...] i made a simple class GlobalCounter to use a GlobalCounter increment: 'some id' in methods i'm interested in and then run some code like following: GlobalCounter reset. mycode run. GlobalCounter counters copy "inspect" GlobalCounter implementation is trivial, i don't think it requires any explanation how it works :) > Stef > > On Feb 8, 2009, at 2:55 PM, Igor Stasenko wrote: > >> 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 >> > > > _______________________________________________ > 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. 8, 2009

Re: [Pharo-project] Call for UI gripes

by StÃ©phane Ducasse

Igor could you give us the snippets for the benchmarks. I would like to use them as example for a forthcoming chapter on profiling. Stef On Feb 8, 2009, at 2:55 PM, Igor Stasenko wrote: > 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. 8, 2009

[Pharo-project] To do items to help pharo

by StÃ©phane Ducasse

Hi all I'm converting into issues all the problems I got when trying to remove etoy. So if you want to have a look you can now pick up an item and send fix :). Stef

Feb. 8, 2009

[Pharo-project] [ANN] prebuilt #101225

by Marcus Denker

http://gforge.inria.fr/frs/download.php/16975/Pharo0.1Core-10225.zip ChangeLog ========= ------------------ update10219 - adapted #loadOBAlpha and #loadSuperOB to use Universe for all non-OB packages - Popup Menu - FileLlist fix ------------------------------------------------------ update10220 PopupAt script loading time Workspace history ------------------------------------------------------ update10221 unload Collection extensions for now ------------------------------------------------------ update10222 Monticello default size + removeRequiredPackage ------------------------------------------------------ update10223 - Polymorph Added support in UIManager for new choice dialog with message, backwards compatible with other UIManager subclasses. Fix for additions of class methods not being categorised under class name in change trees. Added #morphicPatternPane to FileList for compatability with Pharo (FileList2 functionality has been merged into FileList). Remains present in FileList2 for Squeak, ignore FileList2 warning when loading into Pharo. Added PopupChoiceDialogWindowWithMessage submitted by Alain Plantec, supported via UIManager. Tweaked PopupChoiceDialogWindow to make menu list fill area if smaller than eventual scrollable area. - Clean out all PopUpMenu, FillInTheBlank and SelectionMenu references. Replace them with UIManager standard dialogs. ------------------------------------------------------ update10224 - fix merge in Diff - Clean out all PopUpMenu, FillInTheBlank and SelectionMenu references. Replace them with UIManager standard dialogs. ------------------------------------------------------ update10225 fix + repository problem -- Marcus Denker -- denker(a)iam.unibe.ch http://www.iam.unibe.ch/~denker

Feb. 8, 2009

Re: [Pharo-project] Call for UI gripes

by Igor Stasenko

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.

Feb. 8, 2009

Re: [Pharo-project] Call for UI gripes

by Damien Pollet

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 ? > 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

Feb. 8, 2009