Re: [Pharo-project] Call for UI gripes
Gary, 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. 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. That leads to a question I should ask: Gwenael, without asking you to do anything just yet, is your updated parser in a state that it can installed and used? How hard is that to do? Would it be easy for you? Are you able and willing to make it available? What would I have to give up? It's a long story, but tripping over underscores is a problem for a couple of things I would like to do. Bill Wilhelm K. Schwab, Ph.D. University of Florida Department of Anesthesiology PO Box 100254 Gainesville, FL 32610-0254 Email: bschwab@anest.ufl.edu Tel: (352) 273-6785 FAX: (352) 392-7029
gazzaguru2@btinternet.com 02/07/09 11:19 AM >>> Really no other gripes?
Regards, Gary ----- Original Message ----- From: "Gary Chambers" <gazzaguru2@btinternet.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Saturday, January 31, 2009 1:42 PM Subject: Re: [Pharo-project] Call for UI gripes On Vista with each theme I get: Watery2 5200 SoftSqueak 4651.6 StandardSqueak 4082.8 Vistary 5378.4 Watery 4979.6 StandardSqueak compares relatively favourably with Squeak 3.9. Nicer looking widgets do take more cpu of course ;-) With FreeType and Arial fonts: Watery2 6621.6 SoftSqueak 5871.4 StandardSqueak 5391.0 Vistary 7081.8 Watery 6521.8 Goes to show that you can't get something for nothing! Regards, Gary. ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Saturday, January 31, 2009 10:05 AM Subject: Re: [Pharo-project] Call for UI gripes
on mac os 9.0 :)
Stef
On Jan 31, 2009, at 1:29 AM, Igor Stasenko wrote:
2009/1/31 Michael Rueger <m.rueger@acm.org>:
On Fri, Jan 30, 2009 at 9:26 PM, Adrian Lienhard <adi@netstyle.ch> wrote:
On my machine I get:
Squeak 3.9: 3800ms Pharo #084: 2950ms Pharo #213: 5200ms
#084 is before Polymorph was added and #213 is the most recent version.
BTW, with OB: 8590ms.
ouch...
any obvious hotspots?
i think its not very fair to compare OB with old browser. You need more cycles to draw icons for methods, show categories in tree, not in a simple list etc. etc. If you want a real 'ouch' then compare it with MVC browser :)
Michael
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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. Ramon Leon http://onsmalltalk.com
2009/2/7 Ramon Leon <ramon.leon@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor :) do you have some code so that we make progress on that side. On Feb 7, 2009, at 8:23 PM, Igor Stasenko wrote:
2009/2/7 Ramon Leon <ramon.leon@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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?!?!
hehe, good point. The reason why OB does heavy string processing is, simply said, that packages and class categories are not first class, but stupid strings... To for instance find out to which Monticello package a class cat belongs (or vice-versa) we have to do string processing, to not show the package name of a class cat (eg. 'Kernel-Classes' are displayed as 'Classes' in the tree below package 'Kernel') we have to do string processing, and so on, and so on. As there are many packages with many class cats, this sums up. So if we had real packages in Pharo as first class entities, OB would be much faster and simpler to maintain. Right now, OB models packages and class cats itself, has to take the information from both the Monticello's working copy managers and the SystemOrganizer. This is a mess and a huge pain, but what can we do. We should really invest in bringing real packages to Pharo. David
2009/2/10 David Röthlisberger <squeak@webcitas.ch>:
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?!?!
hehe, good point. The reason why OB does heavy string processing is, simply said, that packages and class categories are not first class, but stupid strings... To for instance find out to which Monticello package a class cat belongs (or vice-versa) we have to do string processing, to not show the package name of a class cat (eg. 'Kernel-Classes' are displayed as 'Classes' in the tree below package 'Kernel') we have to do string processing, and so on, and so on. As there are many packages with many class cats, this sums up.
So if we had real packages in Pharo as first class entities, OB would be much faster and simpler to maintain. Right now, OB models packages and class cats itself, has to take the information from both the Monticello's working copy managers and the SystemOrganizer. This is a mess and a huge pain, but what can we do. We should really invest in bringing real packages to Pharo.
Right, i had an impression, that so much string processing going from the need to build a tree from class category names. But again, there is no excuse in doing this each time you need a tree. Thanks to system notifier we have a ways to determine when category tree needs to be rebuilt, so it can be built once and stay cached until user add/remove/rename category.
David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
But again, there is no excuse in doing this each time you need a tree. Thanks to system notifier we have a ways to determine when category tree needs to be rebuilt, so it can be built once and stay cached until user add/remove/rename category.
yes, right. Packages are cached for a long time and also their classes and extended classes. And now also the class cats per package, which is a small share though. But it's good to cache iy anyway. David
2009/2/10 David Röthlisberger <squeak@webcitas.ch>:
But again, there is no excuse in doing this each time you need a tree. Thanks to system notifier we have a ways to determine when category tree needs to be rebuilt, so it can be built once and stay cached until user add/remove/rename category.
yes, right. Packages are cached for a long time and also their classes and extended classes. And now also the class cats per package, which is a small share though. But it's good to cache iy anyway.
Also, note, that you need only one instance of such tree in image . You don't have to build this tree over and over again for each browser window on screen :)
David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Igor Stasenko schrieb:
2009/2/10 David Röthlisberger <squeak@webcitas.ch>:
But again, there is no excuse in doing this each time you need a tree. Thanks to system notifier we have a ways to determine when category tree needs to be rebuilt, so it can be built once and stay cached until user add/remove/rename category. yes, right. Packages are cached for a long time and also their classes and extended classes. And now also the class cats per package, which is a small share though. But it's good to cache iy anyway.
Also, note, that you need only one instance of such tree in image . You don't have to build this tree over and over again for each browser window on screen :)
In a way, yes. But then OB would basically do what the system itself should do, namely modeling packages. I would rather invest in a genuine package model in the system itself than let OB build its own persistent package model. A browser should by definition browse an existing model and not primarily create, maintain, and make persistently accessible a system's model. This would be like a shadow model to what the system otherwise uses, Sounds odd to me, although from a performance point of view it would make sense. David
2009/2/10 David Röthlisberger <squeak@webcitas.ch>:
Igor Stasenko schrieb:
2009/2/10 David Röthlisberger <squeak@webcitas.ch>:
But again, there is no excuse in doing this each time you need a tree. Thanks to system notifier we have a ways to determine when category tree needs to be rebuilt, so it can be built once and stay cached until user add/remove/rename category. yes, right. Packages are cached for a long time and also their classes and extended classes. And now also the class cats per package, which is a small share though. But it's good to cache iy anyway.
Also, note, that you need only one instance of such tree in image . You don't have to build this tree over and over again for each browser window on screen :)
In a way, yes. But then OB would basically do what the system itself should do, namely modeling packages. I would rather invest in a genuine package model in the system itself than let OB build its own persistent package model. A browser should by definition browse an existing model and not primarily create, maintain, and make persistently accessible a system's model. This would be like a shadow model to what the system otherwise uses, Sounds odd to me, although from a performance point of view it would make sense.
Well, OB using own tree of meta-nodes (OBXXXXNode & subclasses) to model different data structures and they relations. Should we expect from squeak/pharo to use same model? I think no. So, even if some day we will have categories as first class objects in system, you still will need to map them to own objects.
David
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Also, note, that you need only one instance of such tree in image . You don't have to build this tree over and over again for each browser window on screen :) In a way, yes. But then OB would basically do what the system itself should do, namely modeling packages. I would rather invest in a genuine package model in the system itself than let OB build its own persistent package model. A browser should by definition browse an existing model and not primarily create, maintain, and make persistently accessible a system's model. This would be like a shadow model to what the system otherwise uses, Sounds odd to me, although from a performance point of view it would make sense.
Well, OB using own tree of meta-nodes (OBXXXXNode & subclasses) to model different data structures and they relations. Should we expect from squeak/pharo to use same model? I think no. So, even if some day we will have categories as first class objects in system, you still will need to map them to own objects.
yes, but that won't be problematic in terms of performance anymore when we can rely on an efficient package model. The traditional system browser not showing packages (no matter whether based on OB or the old Browser class) does not need to use caching or even provide its own persistent shadow system model. Instead it just provides a view on the system model, as it should be. Because what the browser does is really simple: It traverses a tree from packages (or class cats in case of the system browser) down to methods. There shouldn't be a huge overhead if the system model provides efficient access to the entities and its sub-entities (eg. transitions from packages to class cats, to classes, to extended classes, etc.). David
I'll make the drop shadows themable for system windows. The default way Morphic does drop shadows is quite inefficient. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/2/8 Gary Chambers <gazzaguru2@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@gmail.com> To: <Pharo-project@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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@gmail.com>:
2009/2/8 Gary Chambers <gazzaguru2@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@gmail.com> To: <Pharo-project@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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.
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@gmail.com>:
2009/2/8 Gary Chambers <gazzaguru2@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@gmail.com> To: <Pharo-project@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/2/8 Stéphane Ducasse <stephane.ducasse@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@gmail.com>:
2009/2/8 Gary Chambers <gazzaguru2@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@gmail.com> To: <Pharo-project@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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@gmail.com>:
2009/2/8 Gary Chambers <gazzaguru2@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@gmail.com> To: <Pharo-project@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/2/8 Stéphane Ducasse <stephane.ducasse@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@gmail.com>:
2009/2/8 Gary Chambers <gazzaguru2@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@gmail.com> To: <Pharo-project@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
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.
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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Rounded things are tricky to do with no direct support in canvas/balloon. Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@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@gmail.com>:
2009/2/8 Gary Chambers <gazzaguru2@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@gmail.com> To: <Pharo-project@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/2/10 Gary Chambers <gazzaguru2@btinternet.com>:
Rounded things are tricky to do with no direct support in canvas/balloon.
I did some experimenting to draw a rounded rects using balloon bezier curves.. I was disappointed in speed :( Moreover, if border is drawn w/o antialiasing, it looks very ugly and inaccurate. Also, balloon using different bordering logic. It does not insets border inside a shape's area, instead it using a shape segment as a guide to draw a border around it , i.e. if you drawing a horizontal line at y=0 with border width = 3, then border will fill y=-1, y=0 , y=1 . You can look a results on attached images. A code used to draw them: (RoundedRectShape new rect: (10@10 corner: 100@100)) drawOn: World assuredCanvas -- Best regards, Igor Stasenko AKA sig.
Indeed. For the drop shadow I am sneakily using the RoundedBorder (part of Polymorph) for the bottom-right corner when that corner is rounded for a window. No antialisaing, of course, but looks ok-ish... Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, February 10, 2009 2:43 PM Subject: Re: [Pharo-project] Call for UI gripes
2009/2/10 Gary Chambers <gazzaguru2@btinternet.com>:
Rounded things are tricky to do with no direct support in canvas/balloon.
I did some experimenting to draw a rounded rects using balloon bezier curves.. I was disappointed in speed :(
Moreover, if border is drawn w/o antialiasing, it looks very ugly and inaccurate.
Also, balloon using different bordering logic. It does not insets border inside a shape's area, instead it using a shape segment as a guide to draw a border around it , i.e. if you drawing a horizontal line at y=0 with border width = 3, then border will fill y=-1, y=0 , y=1 .
You can look a results on attached images. A code used to draw them: (RoundedRectShape new rect: (10@10 corner: 100@100)) drawOn: World assuredCanvas
-- Best regards, Igor Stasenko AKA sig.
--------------------------------------------------------------------------------
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
When I here that I'm like puzzled. We never said that we will not integrate code that speed up pharo. We started with marcus to clean morphic and there are certainly a large place for possible improvement. Now if you wait that we do it. May be it will happen or may be not. Because we have also quite busy agenda. Stef On Feb 7, 2009, at 6:31 PM, Ramon Leon wrote:
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.
Ramon Leon http://onsmalltalk.com
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
2009/2/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
When I here that I'm like puzzled. We never said that we will not integrate code that speed up pharo. We started with marcus to clean morphic and there are certainly a large place for possible improvement. Now if you wait that we do it. May be it will happen or may be not. Because we have also quite busy agenda.
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: a test code: MessageTally spyOn:[self fullDrawOn: World assuredCanvas]. where 'self' is a mid-sized browser window displayed on screen, non-obstructed with another morphs (Watery 2 theme). - 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 so, here we won 15 ms, which is 1/4 of total rendering time by changing just two methods. Of course, numbers may vary for different browser sizes (more time spent on fills), and different data viewed (more lists traversal etc). I'm attached the changeset with patched method, but i'm not sure about cache - it should be updated when user adds new category, and i don't know how to hook to such events to flush the cache. I think that people who know OB better could do that with ease.
Stef
On Feb 7, 2009, at 6:31 PM, Ramon Leon wrote:
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.
Ramon Leon http://onsmalltalk.com
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
Yes I imagine OB is a bit complex :) On Feb 8, 2009, at 10:27 AM, Igor Stasenko wrote:
2009/2/7 Stéphane Ducasse <stephane.ducasse@inria.fr>:
When I here that I'm like puzzled. We never said that we will not integrate code that speed up pharo. We started with marcus to clean morphic and there are certainly a large place for possible improvement. Now if you wait that we do it. May be it will happen or may be not. Because we have also quite busy agenda.
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:
a test code: MessageTally spyOn:[self fullDrawOn: World assuredCanvas].
where 'self' is a mid-sized browser window displayed on screen, non-obstructed with another morphs (Watery 2 theme).
- 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
so, here we won 15 ms, which is 1/4 of total rendering time by changing just two methods. Of course, numbers may vary for different browser sizes (more time spent on fills), and different data viewed (more lists traversal etc).
I'm attached the changeset with patched method, but i'm not sure about cache - it should be updated when user adds new category, and i don't know how to hook to such events to flush the cache. I think that people who know OB better could do that with ease.
Stef
On Feb 7, 2009, at 6:31 PM, Ramon Leon wrote:
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.
Ramon Leon http://onsmalltalk.com
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig. <OB-render-speedup. 1.cs>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Some measures: i turning off drawing a specific pane (panexx setProperty: #errorOnDraw toValue: true) in OB browser window, and then do [self fullDrawOn: World assuredCanvas] timeToRun to determine which pane takes most time to draw: - everything on (Watery 2 theme) 50ms - turning off drawing a package pane (1st one) 37ms ( - 13 ms) - turning off drawing a class list pane (2nd one) 30ms ( -7 ms) - turning off drawing a category list pane (3rd one) 26ms (-4 ms) - turning off drawing a method list pane (4th one) 20ms (-6 ms) - turning off drawing an enchanced button pane (a row of buttons in the middle of window) 10ms (-10 ms) - turning off drawing a method source pane 8ms (-2 ms) -- ATM there was 4 lines of text at this stage there are a little left to turn off - a window is covered by an areas filled with red color. Let us assume that 8ms is our sacrifice to draw a window :) The numbers speak for themselves, and indicating which areas need attention to improve rendering speed. -- Best regards, Igor Stasenko AKA sig.
tx igor On Feb 8, 2009, at 12:49 PM, Igor Stasenko wrote:
Some measures:
i turning off drawing a specific pane (panexx setProperty: #errorOnDraw toValue: true) in OB browser window, and then do [self fullDrawOn: World assuredCanvas] timeToRun to determine which pane takes most time to draw:
- everything on (Watery 2 theme) 50ms
- turning off drawing a package pane (1st one) 37ms ( - 13 ms)
- turning off drawing a class list pane (2nd one) 30ms ( -7 ms)
- turning off drawing a category list pane (3rd one) 26ms (-4 ms)
- turning off drawing a method list pane (4th one) 20ms (-6 ms)
- turning off drawing an enchanced button pane (a row of buttons in the middle of window) 10ms (-10 ms)
- turning off drawing a method source pane 8ms (-2 ms) -- ATM there was 4 lines of text
at this stage there are a little left to turn off - a window is covered by an areas filled with red color. Let us assume that 8ms is our sacrifice to draw a window :) The numbers speak for themselves, and indicating which areas need attention to improve rendering speed.
-- Best regards, Igor Stasenko AKA sig.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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. Can you take care of integrating the SystemWindow patch into Pharo? Thanks, David
2009/2/10 David Röthlisberger <squeak@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
I can implement such method, but concerning integration - i'm not in charge here :)
Our motto is if code is there and people agree this is integrated :) So go :)
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? :)
sounds small indeed. Stef
Thanks, David
_______________________________________________ Pharo-project mailing list Pharo-project@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
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@gmail.com> To: <Pharo-project@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
Hi gary do you need some icons? What size? because I should draw some of them for david too. Stef On Feb 10, 2009, at 2:32 PM, Gary Chambers wrote:
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@gmail.com> To: <Pharo-project@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
For taskbar/window menu images? If so 16x16 and take your pick of all the common tools/windows. The ones we currently use are shown in the attached png (mostly the MenuIcons small variety). Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, February 10, 2009 2:59 PM Subject: Re: [Pharo-project] Call for UI gripes Hi gary do you need some icons? What size? because I should draw some of them for david too. Stef On Feb 10, 2009, at 2:32 PM, Gary Chambers wrote:
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@gmail.com> To: <Pharo-project@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
for david I imagine that I'm doing them in 14x14. But I can check some in 16*16 I 'm also really confused by the diff merge icons so do you have a list of what is needed? Stef On Feb 10, 2009, at 4:17 PM, Gary Chambers wrote:
For taskbar/window menu images? If so 16x16 and take your pick of all the common tools/windows.
The ones we currently use are shown in the attached png (mostly the MenuIcons small variety).
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr
To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, February 10, 2009 2:59 PM Subject: Re: [Pharo-project] Call for UI gripes
Hi gary
do you need some icons? What size? because I should draw some of them for david too.
Stef On Feb 10, 2009, at 2:32 PM, Gary Chambers wrote:
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@gmail.com> To: <Pharo-project@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project <TaskbarIcons.png>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
For diff/merge the icons currently represent: green left arrow - modification: use existing definition/code-fragment (code fragment compositing still not implemented... not easy). green right arrow - modification: use incoming definition/code-fragment red X - removal green tick - addition Regards, Gary ----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr> To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, February 10, 2009 3:22 PM Subject: Re: [Pharo-project] Call for UI gripes for david I imagine that I'm doing them in 14x14. But I can check some in 16*16 I 'm also really confused by the diff merge icons so do you have a list of what is needed? Stef On Feb 10, 2009, at 4:17 PM, Gary Chambers wrote:
For taskbar/window menu images? If so 16x16 and take your pick of all the common tools/windows.
The ones we currently use are shown in the attached png (mostly the MenuIcons small variety).
Regards, Gary
----- Original Message ----- From: "Stéphane Ducasse" <stephane.ducasse@inria.fr
To: <Pharo-project@lists.gforge.inria.fr> Sent: Tuesday, February 10, 2009 2:59 PM Subject: Re: [Pharo-project] Call for UI gripes
Hi gary
do you need some icons? What size? because I should draw some of them for david too.
Stef On Feb 10, 2009, at 2:32 PM, Gary Chambers wrote:
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@gmail.com> To: <Pharo-project@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project <TaskbarIcons.png>_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
While we are at it I have noticed that SystemWindow>>passivate deliberately draw the World (old behaviour). Having done a few simple benchmarks it seems that better performance is achieved when it is not drawn then, in contradiction to the implication of "clean damage now, so dont merge this rect with new top window". That's on my machine. Can some of you give it a go with the "self world displayWorld" removed and we'll see if it a worthwhile thing to change? Regards, Gary ----- Original Message ----- From: "Igor Stasenko" <siguctua@gmail.com> To: <Pharo-project@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@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
On Sat, Feb 7, 2009 at 17:58, Bill Schwab <BSchwab@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
----- Original Message ----- From: "Damien Pollet" <damien.pollet@gmail.com> To: <Pharo-project@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@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@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
participants (7)
-
Bill Schwab -
Damien Pollet -
David Röthlisberger -
Gary Chambers -
Igor Stasenko -
Ramon Leon -
Stéphane Ducasse