darrinm wrote
On my Mac, Pharo's UI performance (e.g. window dragging, scrolling, any kind of animation) is quite a bit less than the rest of the system. I expect high frame rates for such basic things. It impacts everything I do and makes me sad.
I'm still learning and would like to know:
1) Is this also the case on Linux and Windows? 2) I'm reading that Pharo's GUI is not hardware accelerated. Is this the primary issue with UI performance? 3) If so, is work to incorporate hardware acceleration in progress? 4) If so, how can I help?!
- darrinm
----- Cheers, Sean -- View this message in context: http://forum.world.st/GPU-accelerated-GUI-tp4760898p4761007.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Would be good that this guy posts here because I do not have this slack on my machine.
darrinm wrote
On my Mac, Pharo's UI performance (e.g. window dragging, scrolling, any kind of animation) is quite a bit less than the rest of the system. I expect high frame rates for such basic things. It impacts everything I do and makes me sad.
I'm still learning and would like to know:
1) Is this also the case on Linux and Windows? 2) I'm reading that Pharo's GUI is not hardware accelerated. Is this the primary issue with UI performance? 3) If so, is work to incorporate hardware acceleration in progress? 4) If so, how can I help?!
- darrinm
----- Cheers, Sean -- View this message in context: http://forum.world.st/GPU-accelerated-GUI-tp4760898p4761007.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
2014-05-31 8:12 GMT+02:00 stepharo <stepharo@free.fr>:
Would be good that this guy posts here because I do not have this slack on my machine.
darrinm wrote
On my Mac, Pharo's UI performance (e.g. window dragging, scrolling, any kind of animation) is quite a bit less than the rest of the system. I expect high frame rates for such basic things. It impacts everything I do and makes me sad.
I'm still learning and would like to know:
1) Is this also the case on Linux and Windows?
Yes
2) I'm reading that Pharo's GUI is not hardware accelerated. Is this the
primary issue with UI performance? 3) If so, is work to incorporate hardware acceleration in progress? 4) If so, how can I help?!
There are different issues there.
One is that the Morphic-based UI is slow. You can see it by using the old MVC instead of Morphic which goes faster. Recently Morphic got slower on Pharo and it is now slower than in Squeak. It may be due to refactoring on Morphic in order to get it better, it may not be. I guess this is temporary. The second thing is that BitBlt is slow for 2 reasons: it is bit based and not vector based and its implementation half in the VM half in the image forces to copy a huge number of bits that could be avoided So the answer is that you need to contribute to the refactoring of Morphic or to Athens. GUI hardware acceleration is clearly not the problem yet. Clement
- darrinm
----- Cheers, Sean -- View this message in context: http://forum.world.st/GPU-accelerated-GUI- tp4760898p4761007.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
We could try to organize a task force on that matter. I will try to submit some proposals later, but now I want to prepare a delicious cake. Hilaire Le 31/05/2014 10:48, Clément Bera a écrit :
The second thing is that BitBlt is slow for 2 reasons: it is bit based and not vector based and its implementation half in the VM half in the image forces to copy a huge number of bits that could be avoided
So the answer is that you need to contribute to the refactoring of Morphic or to Athens.
GUI hardware acceleration is clearly not the problem yet.
-- Dr. Geo http://drgeo.eu
On Sat, May 31, 2014 at 11:33 AM, Hilaire Fernandes < hilaire.fernandes@gmail.com> wrote:
We could try to organize a task force on that matter. I will try to submit some proposals later, but now I want to prepare a delicious cake.
Ha, cool. I am cleaning the home :-) Jokes aside, it is true that the Pharo UI is quite slow. I do not have issues on my Core i7 PC but on my Core2Duo Mac it shows... There are enough benefits to having a software UI (flexibility etc) to suffer that. But there is for sure room for improvement. As resolutions go higher, this problem will only get worse. Where would one have to start looking for performance improvements? Phil
Hilaire
Le 31/05/2014 10:48, Clément Bera a écrit :
The second thing is that BitBlt is slow for 2 reasons: it is bit based and not vector based and its implementation half in the VM half in the image forces to copy a huge number of bits that could be avoided
So the answer is that you need to contribute to the refactoring of Morphic or to Athens.
GUI hardware acceleration is clearly not the problem yet.
-- Dr. Geo http://drgeo.eu
Its not about having issues or not having issues, its about how much performance you consume for the GUI alone. I have installed both CPU performance monitor for 2.0GHZ Core2Duo iMac and my new i5 3.2 Ghz iMac. Moving a system browser window in the old iMac spikes the CPUs to 50-70% while moving the window in the new iMac is down to 20%. Of course the old imac is 7 years old the new one is 5 months old. The question here is "does it really worth doing something about it ?" . Sure if you a creating the new CryEngine in Pharo it would be a major problem or any 3d game app that taxes even modern CPUs. But for non demanding usage even if pharo community does absolutely nothing this 20% will shrink down to 10% then 5% , 2.5% and eventually 1%. This has been also a major argument point for cpython. People used to complain A LOT about cpython's performance in old cpus, cause lets face it in some scenarios and many scenarios it was a BIG problem BUT nowday those voices are getting more and more quieter because CPUs have become insanely fast and there is no indication this will stop now. So on the subject of whether we need GPU accelerated GUI at large as a community I would say "Definetly Not" ,Morphic is messy enough as it is, lets not make it more complex..... please ! I am not saying that GPU acceleration does not have its merits, I am using Blender for 3d modeling and its new render engine Cycles makes uses of CUDA and its SWEET , I can almost have real time rendering, not final quality , but still good enough to see how it would look in the final render. Real time rendering to a 3d artist is like live coding to a coder. Its like Christmas vacation in Santa Claus Toy Factory. But on the other hand none stops anyone from implementing a third party library that runs pharo headless and then uses the OS to open a new window completely bypassing morphic and taking advantage of GPU. I don't think we need to make Morphic more complex than it already is. Pharo should be first about simplicity and then performance. But then if you can improve performance of Morphic and yet keep it simple enough please be my guest. On Sat, May 31, 2014 at 1:47 PM, phil@highoctane.be <phil@highoctane.be> wrote:
On Sat, May 31, 2014 at 11:33 AM, Hilaire Fernandes < hilaire.fernandes@gmail.com> wrote:
We could try to organize a task force on that matter. I will try to submit some proposals later, but now I want to prepare a delicious cake.
Ha, cool. I am cleaning the home :-)
Jokes aside, it is true that the Pharo UI is quite slow. I do not have issues on my Core i7 PC but on my Core2Duo Mac it shows...
There are enough benefits to having a software UI (flexibility etc) to suffer that.
But there is for sure room for improvement.
As resolutions go higher, this problem will only get worse.
Where would one have to start looking for performance improvements?
Phil
Hilaire
Le 31/05/2014 10:48, Clément Bera a écrit :
The second thing is that BitBlt is slow for 2 reasons: it is bit based and not vector based and its implementation half in the VM half in the image forces to copy a huge number of bits that could be avoided
So the answer is that you need to contribute to the refactoring of Morphic or to Athens.
GUI hardware acceleration is clearly not the problem yet.
-- Dr. Geo http://drgeo.eu
On Sat, May 31, 2014 at 4:13 AM, kilon alios <kilon.alios@gmail.com> wrote:
Its not about having issues or not having issues, its about how much performance you consume for the GUI alone.
I have installed both CPU performance monitor for 2.0GHZ Core2Duo iMac and my new i5 3.2 Ghz iMac. Moving a system browser window in the old iMac spikes the CPUs to 50-70% while moving the window in the new iMac is down to 20%. Of course the old imac is 7 years old the new one is 5 months old.
The question here is "does it really worth doing something about it ?" .
It is true that I can write all the words I want to say with a dull pencil but I prefer a nice sharp one :). How the interface feels is important.
Sure if you a creating the new CryEngine in Pharo it would be a major problem or any 3d game app that taxes even modern CPUs. But for non demanding usage even if pharo community does absolutely nothing this 20% will shrink down to 10% then 5% , 2.5% and eventually 1%. This has been also a major argument point for cpython. People used to complain A LOT about cpython's performance in old cpus, cause lets face it in some scenarios and many scenarios it was a BIG problem BUT nowday those voices are getting more and more quieter because CPUs have become insanely fast and there is no indication this will stop now.
Today's machines are thousands of times faster than the ones Smalltalk originally ran on. How much faster is its UI now? I don't think Moore's Law is going to fix the problem. So on the subject of whether we need GPU accelerated GUI at large as a
community I would say "Definetly Not" ,Morphic is messy enough as it is, lets not make it more complex..... please !
I agree. It should become less complex. Complexity makes it hard to improve performance. I am not saying that GPU acceleration does not have its merits, I am using
Blender for 3d modeling and its new render engine Cycles makes uses of CUDA and its SWEET , I can almost have real time rendering, not final quality , but still good enough to see how it would look in the final render. Real time rendering to a 3d artist is like live coding to a coder. Its like Christmas vacation in Santa Claus Toy Factory.
Sounds awesome. But on the other hand none stops anyone from implementing a third party
library that runs pharo headless and then uses the OS to open a new window completely bypassing morphic and taking advantage of GPU. I don't think we need to make Morphic more complex than it already is. Pharo should be first about simplicity and then performance. But then if you can improve performance of Morphic and yet keep it simple enough please be my guest.
Fast new windows for 3D would be great and I want my development environment to be fluid, responsive, and powerful too. Today it feels sluggish and weighs on me.
On Sat, May 31, 2014 at 1:47 PM, phil@highoctane.be <phil@highoctane.be> wrote:
On Sat, May 31, 2014 at 11:33 AM, Hilaire Fernandes < hilaire.fernandes@gmail.com> wrote:
We could try to organize a task force on that matter. I will try to submit some proposals later, but now I want to prepare a delicious cake.
Ha, cool. I am cleaning the home :-)
Jokes aside, it is true that the Pharo UI is quite slow. I do not have issues on my Core i7 PC but on my Core2Duo Mac it shows...
There are enough benefits to having a software UI (flexibility etc) to suffer that.
But there is for sure room for improvement.
As resolutions go higher, this problem will only get worse.
Where would one have to start looking for performance improvements?
Phil
Hilaire
Le 31/05/2014 10:48, Clément Bera a écrit :
The second thing is that BitBlt is slow for 2 reasons: it is bit based and not vector based and its implementation half in the VM half in the image forces to copy a huge number of bits that could be avoided
So the answer is that you need to contribute to the refactoring of Morphic or to Athens.
GUI hardware acceleration is clearly not the problem yet.
-- Dr. Geo http://drgeo.eu
2014-06-01 14:44 GMT-03:00 Darrin Massena <darrin@massena.com>:
Today's machines are thousands of times faster than the ones Smalltalk originally ran on. How much faster is its UI now? I don't think Moore's Law is going to fix the problem.
It has ups and downs, if you get a Squeak 3.8 image and run it in a 2Ghz computer, the UI will be fast, even Pharo 1.4 had a faster interface that 3.0. You get a Cuis image and it's super fast. I find Pharo 3.0 UI to be slower than before, but not slow. It feels like if Pharo had the mobile browsers 300ms tap delay too (https://developers.google.com/mobile/articles/fast_buttons?hl=de-DE#toucheve...) As said before, Morphic is slower than MVC too. I always wondered why more money is put into Morphic, instead of trying something else (MVC, MVP, MVVM, etc.). Maybe it's cheaper to fix it than to make it again. Regards!
You get a Cuis image and it's super fast.
What machine are you running on? I just gave the 2009 image of Cuis a try on my current-model Mac Pro (3.6 GHz, 6 cores, tons of RAM) and honestly just dragging a window around was terribly slow. Just guessing, I'd say 10 FPS or less which probably half what I see with Pharo. Is the VM a factor? Should I try a different one? Thanks. -- View this message in context: http://forum.world.st/GPU-accelerated-GUI-tp4760898p4761231.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I couldn't tell exactly, I haven't used Cuis in the last year or so, but at that time (Pharo 2 was new) it was the faster of the three brothers (Pharo/Squeak/Cuis). Maybe that changed lately and Cuis got slower too. Apparently it is very easy to bloat Morphic. Regards, Esteban A. Maringolo 2014-06-01 21:07 GMT-03:00 darrinm <darrin@massena.com>:
You get a Cuis image and it's super fast.
What machine are you running on? I just gave the 2009 image of Cuis a try on my current-model Mac Pro (3.6 GHz, 6 cores, tons of RAM) and honestly just dragging a window around was terribly slow. Just guessing, I'd say 10 FPS or less which probably half what I see with Pharo.
Is the VM a factor? Should I try a different one?
Thanks.
-- View this message in context: http://forum.world.st/GPU-accelerated-GUI-tp4760898p4761231.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Yes. Reading what Juan Vuletich is working on for the next Morphic there is a lot said about things I imagine would negatively impact performance if a lot of deliberate effort isn't made to offset them. On Sun, Jun 1, 2014 at 5:12 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I couldn't tell exactly, I haven't used Cuis in the last year or so, but at that time (Pharo 2 was new) it was the faster of the three brothers (Pharo/Squeak/Cuis).
Maybe that changed lately and Cuis got slower too. Apparently it is very easy to bloat Morphic.
Regards,
Esteban A. Maringolo
2014-06-01 21:07 GMT-03:00 darrinm <darrin@massena.com>:
You get a Cuis image and it's super fast.
What machine are you running on? I just gave the 2009 image of Cuis a try on my current-model Mac Pro (3.6 GHz, 6 cores, tons of RAM) and honestly just dragging a window around was terribly slow. Just guessing, I'd say 10 FPS or less which probably half what I see with Pharo.
Is the VM a factor? Should I try a different one?
Thanks.
-- View this message in context: http://forum.world.st/GPU-accelerated-GUI-tp4760898p4761231.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
I don't know how long will it take to revamp Morphic, last time I saw a demo of it at Smalltalks conference (~circa 2007/8), it was really promising, but didn't hear about it again. Regards, Esteban A. Maringolo 2014-06-01 21:24 GMT-03:00 Darrin Massena <darrin@massena.com>:
Yes. Reading what Juan Vuletich is working on for the next Morphic there is a lot said about things I imagine would negatively impact performance if a lot of deliberate effort isn't made to offset them.
On Sun, Jun 1, 2014 at 5:12 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
I couldn't tell exactly, I haven't used Cuis in the last year or so, but at that time (Pharo 2 was new) it was the faster of the three brothers (Pharo/Squeak/Cuis).
Maybe that changed lately and Cuis got slower too. Apparently it is very easy to bloat Morphic.
Regards,
Esteban A. Maringolo
2014-06-01 21:07 GMT-03:00 darrinm <darrin@massena.com>:
You get a Cuis image and it's super fast.
What machine are you running on? I just gave the 2009 image of Cuis a try on my current-model Mac Pro (3.6 GHz, 6 cores, tons of RAM) and honestly just dragging a window around was terribly slow. Just guessing, I'd say 10 FPS or less which probably half what I see with Pharo.
Is the VM a factor? Should I try a different one?
Thanks.
-- View this message in context: http://forum.world.st/GPU-accelerated-GUI-tp4760898p4761231.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Quoting Ben Coman <btc@openinworld.com>:
Esteban A. Maringolo wrote:
I don't know how long will it take to revamp Morphic, last time I saw a demo of it at Smalltalks conference (~circa 2007/8), it was really promising, but didn't hear about it again. Regards, Esteban A. Maringolo
It seems Juan was concerned about his new methods being patented by someone else. Maybe we'll see more again publically soon. http://forum.world.st/Morphic-3-defensive-disclosure-td4727197.html
cheers -ben Â
Â
Thanks Ben. That's true, the most important ideas are already protected. I hope to have a working version before the end of this year. There will be some performance impact, mostly due to the use of Float geometry instead of SmallInteger. Hopefully Eliot's Spur with immediate Floats will compensate for that. But I have done some benchmarks, and the Morphic 3 graphics engine is twice as fast as Cairo, and almost as fast as AGG (Anti-Grain Geometry). Cheers, Juan Vuletich
Hi Esteban, Quoting "Esteban A. Maringolo" <emaringolo@gmail.com>:
I couldn't tell exactly, I haven't used Cuis in the last year or so, but at that time (Pharo 2 was new) it was the faster of the three brothers (Pharo/Squeak/Cuis).
Maybe that changed lately and Cuis got slower too. Apparently it is very easy to bloat Morphic.
Regards,
Esteban A. Maringolo
We are _not_ bloating Morphic in Cuis. Just download a recent image and see for yourself.
2014-06-01 21:07 GMT-03:00 darrinm <darrin@massena.com>:
You get a Cuis image and it's super fast.
What machine are you running on? I just gave the 2009 image of Cuis a try on my current-model Mac Pro (3.6 GHz, 6 cores, tons of RAM) and honestly just dragging a window around was terribly slow. Just guessing, I'd say 10 FPS or less which probably half what I see with Pharo.
Is the VM a factor? Should I try a different one?
Thanks.
-- View this message in context: http://forum.world.st/GPU-accelerated-GUI-tp4760898p4761231.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.
Cheers, Juan Vuletich
Hi Darrin, Quoting darrinm <darrin@massena.com>:
You get a Cuis image and it's super fast.
What machine are you running on? I just gave the 2009 image of Cuis a try on my current-model Mac Pro (3.6 GHz, 6 cores, tons of RAM) and honestly just dragging a window around was terribly slow. Just guessing, I'd say 10 FPS or less which probably half what I see with Pharo.
Is the VM a factor? Should I try a different one?
Thanks.
I don't have a Mac at hand right now, but on this I5 Windows 7 notebook, dragging Cuis windows (full content, not just a frame) is smoother and more free of artifacts than doing the same with native Windows windows (for example, file explorers). You might try with the latest Cog VM. In any case, the speed advantage of Cuis morphic can better be seen by opening a FileList on a very large file and scrolling, or scrolling very large lists, or resizing browser windows (with all layout being recalculated 'live'). In any case, you are welcome to continue this discussion at http://jvuletich.org/mailman/listinfo/cuis_jvuletich.org , the Cuis mail list. Cheers, Juan Vuletich
It depends what you measure. If you measure classBrowser opening then nautilus is slower because it is doing more stuff. Now we invested a lot in - cleaning morphic and we will continue. We fixed broken rectangles (around 150 creation), added Margin to avoid ifTrue: removed many of the totally useless extensions. Now we do it step by step because it takes time and we try to understand what we remove!!! - in Spec, spec is a MVP like system. Now building one takes time and ben did a great job. Now we should check if he will continue or not (it depends on him and his job). We should probably do a pass on Spec. Alain Plantec is rewriting core morphic from scratch and it is quite fast. He just shows me this after how he can package halos as a separate package. Now the risk is high because Alain does not have the amount of time he would like to work on that. So if you really want to help make a benchmark showing the difference between 1.4 and 3.0 on a **concrete** case. Without that we cannot make progress. Stef
Today's machines are thousands of times faster than the ones Smalltalk originally ran on. How much faster is its UI now? I don't think Moore's Law is going to fix the problem. It has ups and downs, if you get a Squeak 3.8 image and run it in a 2Ghz computer, the UI will be fast, even Pharo 1.4 had a faster interface that 3.0. You get a Cuis image and it's super fast.
I find Pharo 3.0 UI to be slower than before, but not slow. It feels like if Pharo had the mobile browsers 300ms tap delay too (https://developers.google.com/mobile/articles/fast_buttons?hl=de-DE#toucheve...)
As said before, Morphic is slower than MVC too. I always wondered why more money is put into Morphic, instead of trying something else (MVC, MVP, MVVM, etc.). Maybe it's cheaper to fix it than to make it again.
Regards!
2014-06-02 16:51 GMT-03:00 stepharo <stepharo@free.fr>:
It depends what you measure. If you measure classBrowser opening then nautilus is slower because it is doing more stuff.
If adding more features degrades performance in a human perceivable way then it's slowing down. (I mean, if slowdown is linear as extra features are added). The trade-offs might be worth it (as indeed they are).
So if you really want to help make a benchmark showing the difference between 1.4 and 3.0 on a **concrete** case. Without that we cannot make progress.
Fair enough. I'll do so :) Next time I won't say it feels slower (but not slow) until I get an appropriate benchmark. Regards, -- Esteban.
I'm learning and would love to hear ideas about how best to benchmark Smalltalk rendering. I tried this very crude test in a Workspace: loops := 100. rect := Display boundingBox. a := Time millisecondsToRun: [ loops timesRepeat: [ Display forceToScreen: rect. ]. ]. Transcript show: a / loops asFloat; cr. With a full-screen window on a current model Mac Pro with stock Pharo 3 image and VM it reports 47 ms/update. On my Surface Pro 2 (Windows 8) it is takes only 1.1 ms. I'm kind of shocked by that number in comparison. It's a lower resolution screen but still. I know full screen updates are not the norm for many applications but they're still very important. Also keep in mind this is just the low level screen update, no Morphic overhead. Ideally the display update takes less than a millisecond to leave time for all the higher level rendering. For performance assessment I'd like to have a nice Frames Per Second graph running in the corner as well as repeatable test cases matching common uses (scrolling, full updates, partial updates, empty window, densely packed grid, text editor, etc) that could be run across platforms. After that I wonder about profiling. Can accurate timed traces be done from top to bottom? I imagine it would at least get murky at the VM boundary. I also noticed logic to limit display updates to 50 times a second, presumably to minimize CPU usage. CPU usage would also be reduced by optimizing rendering but in any case I'd like to see an update rate synchronized with the video rate or faster (60 or more). That would minimize tearing and allow for no perceivable UI lag. On Mon, Jun 2, 2014 at 3:48 PM, Esteban A. Maringolo <emaringolo@gmail.com> wrote:
2014-06-02 16:51 GMT-03:00 stepharo <stepharo@free.fr>:
It depends what you measure. If you measure classBrowser opening then nautilus is slower because it is doing more stuff.
If adding more features degrades performance in a human perceivable way then it's slowing down. (I mean, if slowdown is linear as extra features are added). The trade-offs might be worth it (as indeed they are).
So if you really want to help make a benchmark showing the difference between 1.4 and 3.0 on a **concrete** case. Without that we cannot make progress.
Fair enough. I'll do so :) Next time I won't say it feels slower (but not slow) until I get an appropriate benchmark.
Regards,
-- Esteban.
Can we collect somewhere in the web the information you mentioned and other more accurate? Ideally a wiki. Is there a dedicated place for Pharo? The wiki bugtracker? I guess most of us does not know where to look at for improvement. Asking to a newbie to contribute does not really help if we can't provide direction. Hilaire Le 31/05/2014 10:48, Clément Bera a écrit :
One is that the Morphic-based UI is slow. You can see it by using the old MVC instead of Morphic which goes faster. Recently Morphic got slower on Pharo and it is now slower than in Squeak. It may be due to refactoring on Morphic in order to get it better, it may not be. I guess this is temporary.
The second thing is that BitBlt is slow for 2 reasons: it is bit based and not vector based and its implementation half in the VM half in the image forces to copy a huge number of bits that could be avoided
So the answer is that you need to contribute to the refactoring of Morphic or to Athens.
-- Dr. Geo http://drgeo.eu
I would like to try (again) a wiki for Pharo. Problem is that they obsolete very fast, and information there become unusable⦠I suppose we need a âwiki overseerâ (or several) to ensure we keep it in track⦠anyway, I want to try a wiki for Pharo, because there is a lot of information that fits better there (like this and a lot other). Esteban On 31 May 2014, at 10:01, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
Can we collect somewhere in the web the information you mentioned and other more accurate? Ideally a wiki. Is there a dedicated place for Pharo? The wiki bugtracker? I guess most of us does not know where to look at for improvement. Asking to a newbie to contribute does not really help if we can't provide direction.
Hilaire
Le 31/05/2014 10:48, Clément Bera a écrit :
One is that the Morphic-based UI is slow. You can see it by using the old MVC instead of Morphic which goes faster. Recently Morphic got slower on Pharo and it is now slower than in Squeak. It may be due to refactoring on Morphic in order to get it better, it may not be. I guess this is temporary.
The second thing is that BitBlt is slow for 2 reasons: it is bit based and not vector based and its implementation half in the VM half in the image forces to copy a huge number of bits that could be avoided
So the answer is that you need to contribute to the refactoring of Morphic or to Athens.
-- Dr. Geo http://drgeo.eu
Hello, Typically for a new contribution, one write a new task in the bugtracker and then fix it (here: https://pharo.fogbugz.com/). The 2 issues I mentioned, Morphic and BitBlt performance are well-known issues in the Pharo team. Some projects have been started to solve these issues: a refactoring of Morphic and Athens. To what I understood, Athens is supposed to replace the bottom layer of Morphic, BitBlt should be replaced by Cairo (binded with NativeBoost) and the top layer of Morphic should be refactored. A guy was hired to work on these projects, but he left after a month and the Pharo team lost over 65keuros. So the 2 projects got kind of delayed, we're sorry about it. I think you should talk directly to the the persons responsible for these projects to know what to do to help. The Morphic refactoring is leaded by Stephane Ducasse (and/or Alain Plantec ?) and Athens is leaded by Igor Stasenko. They can tell you on what to do to improve the UI. I know that recently Igor was working on a new/cleaner/faster TextEditor. Stef and Alain have committed several changes to Morph during the past years. I cannot tell you what to do on these projects because I am working on Smalltalk code execution speed improvement (Cog JIT performance) and I am not deeply aware of recent advancements on these specific projects. So please Ask Stef or Igor. PS: I was reading again my previous mail, I realized that Athens relies on Cairo so it probably uses GPU accelerated GUI. Clément 2014-05-31 15:01 GMT+02:00 Hilaire Fernandes <hilaire.fernandes@gmail.com>:
Can we collect somewhere in the web the information you mentioned and other more accurate? Ideally a wiki. Is there a dedicated place for Pharo? The wiki bugtracker? I guess most of us does not know where to look at for improvement. Asking to a newbie to contribute does not really help if we can't provide direction.
Hilaire
Le 31/05/2014 10:48, Clément Bera a écrit :
One is that the Morphic-based UI is slow. You can see it by using the old MVC instead of Morphic which goes faster. Recently Morphic got slower on Pharo and it is now slower than in Squeak. It may be due to refactoring on Morphic in order to get it better, it may not be. I guess this is temporary.
The second thing is that BitBlt is slow for 2 reasons: it is bit based and not vector based and its implementation half in the VM half in the image forces to copy a huge number of bits that could be avoided
So the answer is that you need to contribute to the refactoring of Morphic or to Athens.
-- Dr. Geo http://drgeo.eu
I know the points you described but my point was really it could help -- as Esteban rephrased it -- if we have a place to write down stuff/idea/things to do/technical info related to Pharo improvement. It is helpful to point someone to as a starting point. PS: As far as I knwo Cairo is only software based no hw accelerated. Le 31/05/2014 16:37, Clément Bera a écrit :
Hello,
Typically for a new contribution, one write a new task in the bugtracker and then fix it (here: https://pharo.fogbugz.com/).
The 2 issues I mentioned, Morphic and BitBlt performance are well-known issues in the Pharo team. Some projects have been started to solve these issues: a refactoring of Morphic and Athens. To what I understood, Athens is supposed to replace the bottom layer of Morphic, BitBlt should be replaced by Cairo (binded with NativeBoost) and the top layer of Morphic should be refactored.
A guy was hired to work on these projects, but he left after a month and the Pharo team lost over 65keuros. So the 2 projects got kind of delayed, we're sorry about it.
I think you should talk directly to the the persons responsible for these projects to know what to do to help. The Morphic refactoring is leaded by Stephane Ducasse (and/or Alain Plantec ?) and Athens is leaded by Igor Stasenko. They can tell you on what to do to improve the UI. I know that recently Igor was working on a new/cleaner/faster TextEditor. Stef and Alain have committed several changes to Morph during the past years.
I cannot tell you what to do on these projects because I am working on Smalltalk code execution speed improvement (Cog JIT performance) and I am not deeply aware of recent advancements on these specific projects. So please Ask Stef or Igor.
PS: I was reading again my previous mail, I realized that Athens relies on Cairo so it probably uses GPU accelerated GUI.
Clément
2014-05-31 15:01 GMT+02:00 Hilaire Fernandes <hilaire.fernandes@gmail.com <mailto:hilaire.fernandes@gmail.com>>:
Can we collect somewhere in the web the information you mentioned and other more accurate? Ideally a wiki. Is there a dedicated place for Pharo? The wiki bugtracker? I guess most of us does not know where to look at for improvement. Asking to a newbie to contribute does not really help if we can't provide direction.
Hilaire
Le 31/05/2014 10:48, Clément Bera a écrit : > One is that the Morphic-based UI is slow. You can see it by using the > old MVC instead of Morphic which goes faster. Recently Morphic got > slower on Pharo and it is now slower than in Squeak. It may be due to > refactoring on Morphic in order to get it better, it may not be. I guess > this is temporary. > > The second thing is that BitBlt is slow for 2 reasons: it is bit based > and not vector based and its implementation half in the VM half in the > image forces to copy a huge number of bits that could be avoided > > So the answer is that you need to contribute to the refactoring of > Morphic or to Athens. >
-- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu
On 31 mai 2014, at 20:21, Hilaire Fernandes <hilaire.fernandes@gmail.com> wrote:
I know the points you described but my point was really it could help -- as Esteban rephrased it -- if we have a place to write down stuff/idea/things to do/technical info related to Pharo improvement. It is helpful to point someone to as a starting point.
A good place to discuss and write down ideas and co could be fogbugz' "discussion" feature. I once set up several discussion topics there but nobody filled them yet.
PS: As far as I knwo Cairo is only software based no hw accelerated.
Le 31/05/2014 16:37, Clément Bera a écrit :
Hello,
Typically for a new contribution, one write a new task in the bugtracker and then fix it (here: https://pharo.fogbugz.com/).
The 2 issues I mentioned, Morphic and BitBlt performance are well-known issues in the Pharo team. Some projects have been started to solve these issues: a refactoring of Morphic and Athens. To what I understood, Athens is supposed to replace the bottom layer of Morphic, BitBlt should be replaced by Cairo (binded with NativeBoost) and the top layer of Morphic should be refactored.
A guy was hired to work on these projects, but he left after a month and the Pharo team lost over 65keuros. So the 2 projects got kind of delayed, we're sorry about it.
I think you should talk directly to the the persons responsible for these projects to know what to do to help. The Morphic refactoring is leaded by Stephane Ducasse (and/or Alain Plantec ?) and Athens is leaded by Igor Stasenko. They can tell you on what to do to improve the UI. I know that recently Igor was working on a new/cleaner/faster TextEditor. Stef and Alain have committed several changes to Morph during the past years.
I cannot tell you what to do on these projects because I am working on Smalltalk code execution speed improvement (Cog JIT performance) and I am not deeply aware of recent advancements on these specific projects. So please Ask Stef or Igor.
PS: I was reading again my previous mail, I realized that Athens relies on Cairo so it probably uses GPU accelerated GUI.
Clément
2014-05-31 15:01 GMT+02:00 Hilaire Fernandes <hilaire.fernandes@gmail.com <mailto:hilaire.fernandes@gmail.com>>:
Can we collect somewhere in the web the information you mentioned and other more accurate? Ideally a wiki. Is there a dedicated place for Pharo? The wiki bugtracker? I guess most of us does not know where to look at for improvement. Asking to a newbie to contribute does not really help if we can't provide direction.
Hilaire
Le 31/05/2014 10:48, Clément Bera a écrit :
One is that the Morphic-based UI is slow. You can see it by using the old MVC instead of Morphic which goes faster. Recently Morphic got slower on Pharo and it is now slower than in Squeak. It may be due to refactoring on Morphic in order to get it better, it may not be. I guess this is temporary.
The second thing is that BitBlt is slow for 2 reasons: it is bit based and not vector based and its implementation half in the VM half in the image forces to copy a huge number of bits that could be avoided
So the answer is that you need to contribute to the refactoring of Morphic or to Athens.
-- Dr. Geo http://drgeo.eu
-- Dr. Geo http://drgeo.eu
Like this https://pharo.fogbugz.com/default.asp?spec ? Le 01/06/2014 00:23, Camille Teruel a écrit :
I once set up several discussion topics there but nobody filled them yet.
-- Dr. Geo http://drgeo.eu
If nobody has time to curate the information then an issue tracker is probably the way to go. At least then tidbits of information would be gathered in one stream with timestamps so one can gauge relevance. For example, I'm doing some performance measurements and would post them to a GUI performance issue if there was one and others were following/contributing to it. When people ask about a topic in the forums they could be directed toward the relevant issue. On Sat, May 31, 2014 at 6:01 AM, Hilaire Fernandes < hilaire.fernandes@gmail.com> wrote:
Can we collect somewhere in the web the information you mentioned and other more accurate? Ideally a wiki. Is there a dedicated place for Pharo? The wiki bugtracker? I guess most of us does not know where to look at for improvement. Asking to a newbie to contribute does not really help if we can't provide direction.
Hilaire
Le 31/05/2014 10:48, Clément Bera a écrit :
One is that the Morphic-based UI is slow. You can see it by using the old MVC instead of Morphic which goes faster. Recently Morphic got slower on Pharo and it is now slower than in Squeak. It may be due to refactoring on Morphic in order to get it better, it may not be. I guess this is temporary.
The second thing is that BitBlt is slow for 2 reasons: it is bit based and not vector based and its implementation half in the VM half in the image forces to copy a huge number of bits that could be avoided
So the answer is that you need to contribute to the refactoring of Morphic or to Athens.
-- Dr. Geo http://drgeo.eu
participants (13)
-
Ben Coman -
Camille Teruel -
Clément Bera -
Darrin Massena -
darrinm
-
Esteban A. Maringolo -
Esteban Lorenzano -
Hilaire Fernandes -
J. Vuletich (mail lists) -
kilon alios -
phil＠highoctane.be -
Sean P. DeNigris -
stepharo