May 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] GPU accelerated GUI

by Hilaire Fernandes

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

May 31, 2014

Re: [Pharo-dev] [Vm-dev] Re: Initial versions for OSWindow and Woden

by David T. Lewis

On Sat, May 31, 2014 at 08:34:47PM +0800, btc(a)openinworld.com wrote: > > Hi Ronie, This is really exciting (and I've cross-posted to vm-dev). I > guess this will help multi-monitor displays to have a window on each > monitor? > > Ronie Salgado wrote: > >Hello There, > > > >I have been working in OSWindow, which is a cross platform API for > >dealing with native operating system windows. This API requires using > >a custom VM and the library SDL2. > > > >With this API, even the main Pharo window is handled almost completely > >in image side using NativeBoost. > > > >The only support required from the VM is a small periodical check in > >the heartbeat about the presence of events. This no more than 10 lines > >of code. > > Is there much you needed to change/delete from the existing VM window > initialization. Since the VM is shared with other Smalltalk platforms, > how compatible would this be to maintain in parallel with the existing > VM windows initialization? > cheers -ben > What are the 10 lines of code required to provide the VM support? Dave > > > >This is currently working very well in my Linux machine, so I need to > >start testing this stuff. > > > >For Windows, soon I will be building the custom VM. My last built was > >very dirty and I want to do something more clean. > > > >For Mac OS X, I don't have one for testing. But Alex is going allow me > >to borrow one for some time. So be patience. > > > >As for Woden, it is a new 3D graphics engine that I started making. > >This one requires currently support of OSWindow and also shows some > >cool stuffs. > > > >As for prebuilt versions of the VM with OSWindow support along with > >preloaded images for both, OSWindow and Woden. And screenshots. > > > >Well, I am putting them here: http://ronie.cl/OSWindow/ > > > >Greetings, > >Ronie

May 31, 2014

Re: [Pharo-dev] Dark Theme in Pharo 4

by phil＠highoctane.be

Hi, Have a look at the DawnTheme, which builds upon the dark one and changes the various colors etc. There is less stuff in there, you may learn faster with that. I did. Phil â

May 31, 2014

Re: [Pharo-dev] Initial versions for OSWindow and Woden

by btc＠openinworld.com

Hi Ronie, This is really exciting (and I've cross-posted to vm-dev). I guess this will help multi-monitor displays to have a window on each monitor? Ronie Salgado wrote: > Hello There, > > I have been working in OSWindow, which is a cross platform API for > dealing with native operating system windows. This API requires using > a custom VM and the library SDL2. > > With this API, even the main Pharo window is handled almost completely > in image side using NativeBoost. > > The only support required from the VM is a small periodical check in > the heartbeat about the presence of events. This no more than 10 lines > of code. Is there much you needed to change/delete from the existing VM window initialization. Since the VM is shared with other Smalltalk platforms, how compatible would this be to maintain in parallel with the existing VM windows initialization? cheers -ben > > This is currently working very well in my Linux machine, so I need to > start testing this stuff. > > For Windows, soon I will be building the custom VM. My last built was > very dirty and I want to do something more clean. > > For Mac OS X, I don't have one for testing. But Alex is going allow me > to borrow one for some time. So be patience. > > As for Woden, it is a new 3D graphics engine that I started making. > This one requires currently support of OSWindow and also shows some > cool stuffs. > > As for prebuilt versions of the VM with OSWindow support along with > preloaded images for both, OSWindow and Woden. And screenshots. > > Well, I am putting them here: http://ronie.cl/OSWindow/ > > Greetings, > Ronie

May 31, 2014

Re: [Pharo-dev] Dark Theme in Pharo 4

by Esteban Lorenzano

hi, there is a default, #textColor in the themes and for the colorisation, you can find the definitions in SHTextStylerST80>>#darkStyleTable Esteban On 31 May 2014, at 06:53, kilon alios <kilon.alios(a)gmail.com> wrote: > great to know > > Where exactly is the color of the font for code ? I cant find it. > > > On Thu, May 29, 2014 at 3:19 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 29 May 2014, at 09:01, Sergi Reyner <sergi.reyner(a)gmail.com> wrote: > >> 2014-05-29 9:11 GMT+01:00 kilon alios <kilon.alios(a)gmail.com>: >> I would also like to take a deep look and see if with your help can document the theming. You think that themes now are more coder friendly or is Dark theme still a hack ? >> >> (just noticed it right now): Try to revert to a "regular" theme and tell me what color is the text cursor, that should partially answer your question :D > > no, it is not a hack. > Dark theme is a combination of two things: a refactor to move out hardcoded colors (they are everywhere) and the theme itself. > the cursor color is also a hardcoded value someplace there (not the fault of the theme :P). > > but... #installFullTheme should be used between dark and lighter themes to restore all values. > If you choose dark theme, to go back you should first execute: > > Pharo3Theme installFullTheme. > > that should restore everything as before. > > so wellâ¦ I do not like the theme design, but the dark theme is following its guidelines. Then is not a hack, but it has some limitations :) > also, thatâs why it is integrated in Pharo4 and not in Pharo3â¦ most probably it need some iterations until is ready. > > Esteban > >> >> Cheers, >> Sergi > >

May 31, 2014

Re: [Pharo-dev] GPU accelerated GUI

by kilon alios

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(a)highoctane.be <phil(a)highoctane.be> wrote: > On Sat, May 31, 2014 at 11:33 AM, Hilaire Fernandes < > hilaire.fernandes(a)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 >> >> >> >

May 31, 2014

Re: [Pharo-dev] GPU accelerated GUI

by phil＠highoctane.be

On Sat, May 31, 2014 at 11:33 AM, Hilaire Fernandes < hilaire.fernandes(a)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 > > >

May 31, 2014

Initial versions for OSWindow and Woden

by Ronie Salgado

Hello There, I have been working in OSWindow, which is a cross platform API for dealing with native operating system windows. This API requires using a custom VM and the library SDL2. With this API, even the main Pharo window is handled almost completely in image side using NativeBoost. The only support required from the VM is a small periodical check in the heartbeat about the presence of events. This no more than 10 lines of code. This is currently working very well in my Linux machine, so I need to start testing this stuff. For Windows, soon I will be building the custom VM. My last built was very dirty and I want to do something more clean. For Mac OS X, I don't have one for testing. But Alex is going allow me to borrow one for some time. So be patience. As for Woden, it is a new 3D graphics engine that I started making. This one requires currently support of OSWindow and also shows some cool stuffs. As for prebuilt versions of the VM with OSWindow support along with preloaded images for both, OSWindow and Woden. And screenshots. Well, I am putting them here: http://ronie.cl/OSWindow/ Greetings, Ronie

May 31, 2014

Re: [Pharo-dev] Regular Hangouts

by Ben Coman

stepharo wrote: > Hi guys > > I would really like to launch regular hangouts because I would like to > build more contacts inside the community. > I was thinking about every two weeks around 17h-18h > > What do you think? > > Stef > > Two weeks seems like a good span. That works out to be 2300 to 2400 for me, which is okay - I'm a night owl. Maybe align it shortly after the fortnightly "Whats up" - to provide some conversation points. cheers -ben

May 31, 2014

Re: [Pharo-dev] Dark Theme in Pharo 4

by kilon alios

great to know Where exactly is the color of the font for code ? I cant find it. On Thu, May 29, 2014 at 3:19 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > > On 29 May 2014, at 09:01, Sergi Reyner <sergi.reyner(a)gmail.com> wrote: > > 2014-05-29 9:11 GMT+01:00 kilon alios <kilon.alios(a)gmail.com>: > >> I would also like to take a deep look and see if with your help can >> document the theming. You think that themes now are more coder friendly or >> is Dark theme still a hack ? >> > > (just noticed it right now): Try to revert to a "regular" theme and tell > me what color is the text cursor, that should partially answer your > question :D > > > no, it is not a hack. > Dark theme is a combination of two things: a refactor to move out > hardcoded colors (they are everywhere) and the theme itself. > the cursor color is also a hardcoded value someplace there (not the fault > of the theme :P). > > but... #installFullTheme should be used between dark and lighter themes to > restore all values. > If you choose dark theme, to go back you should first execute: > > Pharo3Theme installFullTheme. > > that should restore everything as before. > > so wellâ¦ I do not like the theme design, but the dark theme is following > its guidelines. Then is not a hack, but it has some limitations :) > also, thatâs why it is integrated in Pharo4 and not in Pharo3â¦ most > probably it need some iterations until is ready. > > Esteban > > > Cheers, > Sergi > > >

May 31, 2014