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

Re: [Pharo-dev] GPU accelerated GUI

by Camille Teruel

On 31 mai 2014, at 20:21, Hilaire Fernandes <hilaire.fernandes(a)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(a)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

May 31, 2014

Re: [Pharo-dev] OpenGL 3.0+

by Ronie Salgado

Hello, OK. Where is the old generator? I will look into it if nobody is already > doing so. The old generator is in the NBOpenGL Smalltalk Hub repository. It does a lot of magic so working with it can be very frustrating. Also, you are going to want to read about the fileout format( http://www.inf.ufsc.br/poo/smalltalk/stx/english/programming/fileoutFormat.… ). Ask all the details to Igor or Jean Baptiste, they are more familiar with NBOpenGL itself. If there is something I can do to help with the Mac I would like to. > In my other post a published a bit of OSWindow. You can try to play with it or making it work on Mac. Apart from the VM changes, for Mac is missing testing for loading the SDL2 library. Very nice. Is Athens used to render the main UI elements (windows, buttons, > bitmaps, text, etc?). > I believe that most of them not, because they rely on older raster operations. I think that accelerating Morphic requires refactoring it to use Athens all the time. As for myself, I need an Athens backend for Roassal2 to avoid having cairo->form->texture transfers. Greetings, Ronie 2014-05-31 13:00 GMT-04:00 Ben Coman <btc(a)openinworld.com>: > Darrin Massena wrote: > > Thanks for all the great info Ronie! > > > On Fri, May 30, 2014 at 4:06 PM, Ronie Salgado <roniesalg(a)gmail.com> > wrote: > >> Hello, >> >> I am also interested on this topic. For what I saw from NBOpenGL, Igor >> was generating the bindings from older specifications of the OpenGL API. >> Those older specifications are in a deprecated DSL. >> >> The newer versions of the OpenGL APIs are available in some XML files >> provided by Khronos Group. In this link >> http://www.opengl.org/registry/#specfiles another link for a subversion >> repository( >> https://cvs.khronos.org/svn/repos/ogl/trunk/doc/registry/public/api/ ) >> with those XML files is available, along with the formal OpenGL specs. >> >> Because they are now in those XML files, we need new generator for >> OpenGL 3.3-4.0. >> > > OK. Where is the old generator? I will look into it if nobody is already > doing so. > > I am not involved so cannot answer directly, but I see something similar > discussed here.. > http://jeanbaptiste-arnaud.eu/opengl/ > > > > Another question, a core profile context is really needed? Why not >> starting working with a compatibility profile?. OpenGL API deprecation does >> not depend on us, it depends on what the Khronos Group and the graphics >> card maker decide to do. In the x86 Desktop, the three big companies cannot >> remove the compatibility profile, otherwise lot of older video-games will >> stop working. >> >> Also, there are lots of graphic cards, specially older integrated in >> laptops that are only OpenGL 2.x. A better bet is to support at least the >> subset available in OpenGL 2.x that is also available in the core profile. >> > > Good points. Nevertheless, as I understand it, OSX does not provide a > compatibility profile. You get core 2.1, 3.2, or 4.1 with OSX 10.7 or > greater (released 3 years ago). Currently Pharo always gets OpenGL 2.1 > core. So we are working with an API that was deprecated 6 years ago that > can only take advantage of a fraction of the power of our GPUs and is > discouraged/unavailable on mobile platforms. Maybe that is enough for some > things but I'd like to see the door opened for more. > > This makes me wonder what the compatibility philosophy of Pharo is. Is > it a goal that once something is developed in Pharo it will work unchanged > on all future Pharo versions? I imagine one of the liberating aspects of > VMs is that they can evolve, even incompatibility, because old software can > continue to run on old VMs. But I am new to Smalltalk/Pharo culture so > please educate me. > > Backward compatibility can be a divisive subject. The disparate views > expressed at [1] will give you a general overview of Pharo's philosophy. > Now your question is slightly different to the usual backward-compatibility > discussion that relates to the existing codebase inherited from Squeak and > before. Here on of Pharo's goal to enhance future maintainability by > elimination of "legacy code", where [1] defines "legacy code" as: > - a code written eons ago > - original authors are gone/not interested in communicating > - no documentation > - a lot of patches and extensions from various authors over ears > - often same functionality implemented using two different ways > - things are completely bizarre, unmaintainable and unable to understand > > So for the existing code, while compatibility is kept as much as possible, > cleaning takes priority. While this might cause some early pain, the mid > to long terms should end up better than otherwise. > > Regarding "once something is developed in Pharo will it work unchanged on > _all_ future Pharo versions?" I would hazard to guess, considering the > keyword "all", that the answer is "no". The Pharo team are pragmatic about > what they can achieve with their resources. If something can provide more > (in terms of maintainability and broader usage) for a given effort, then > that is probably the path to be taken. > > [1] > http://lists.gforge.inria.fr/pipermail/pharo-project/2012-December/072196.h… > > cheers -ben > > > > Maybe we need a GL3ViewportMorph to live along side GLViewportMorph. > > >> As for plans for OpenGL support, normal and accelerated GUIs, I am >> working in OSWindow. >> > > I have read a little of this -- very exciting! > > >> OSWindow provides support to manage native operating system windows >> purely from image side. With Igor, we made a custom image and VM for Linux >> in which we removed almost everything graphic related from the VM. The only >> support needed in the VM is a small check for event presence in the VM >> heartbeat. >> >> For OSWindow, we made initially a XLib based back-end. To reduce >> maintenance efforts for Windows and Mac OS, I made a new backend based in >> SDL2. It is quite complete and I have tested mostly in Linux. For Windows I >> could make it work, not perfect so it needs more testing and a complete >> removal of the old Win32 drivers. I don't have a Mac for testing, but Alex >> is going to help me there. >> > > If there is something I can do to help with the Mac I would like to. > > I have to tell the CMakeVMMaker to also build SDL2 before building, >> instead of having to build/install it manually. After that I think that we >> can start integrating into Pharo 4. >> >> As for OpenGL, SDL2 gives me a multi-platform abstraction for creating >> a window with an OpenGL context. I already made it work with NBOpenGL, the >> only tricky part is dependency order when loading the stuff in the image. >> > > Yes, SDL2 is the way to go. > > In fact, I already started making a new 3D graphics engine Pharo, to >> rewrite Roassal 3D on top of this one in the near future. Soon I will be >> posting some screen-shots of this engine. >> > > Sounds interesting! > > >> With this graphics engine, I am also going to try to make an Athens >> backend, for accelerated vector graphics. Vectorial graphics with OpenGL >> are very hard to do fast, specially self intersecting bezier curves. >> Stencil based testing is simple, fast, supported and efficient for this job. >> > > Very nice. Is Athens used to render the main UI elements (windows, > buttons, bitmaps, text, etc?). > > It's not clear to me how the OSWindow work will result in a faster Pharo > UI. On OSX, at least, underneath everything is already an OS window that > supports GL and other accelerated calls but the Pharo graphics primitives > don't take advantage of this. Won't they need reworking? > > Greetings, >> Ronie >> >> >> 2014-05-30 11:10 GMT-04:00 Sean P. DeNigris <sean(a)clipperadams.com>: >> >>> darrinm wrote >>> > Oh, and NBMacGLConstants is lacking necessary constants. Is it manually >>> > created or generated somehow? >>> > >>> > - darrinm >>> >>

May 31, 2014

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

by Ronie Salgado

Sorry about the missing VM source. I am uploading the changes into my github repository: https://github.com/ronsaldo/pharo-vm As for the details of loading a OSWindow into a Pharo image, there is a fogbugz issue with all the required instructions. Now, OSWindow relies heavily on NativeBoost, so as for Squeak integration they would need to support it. Now, I am also working on a new FFI, which will allows NB to have a better integration with the existing VM. With the FFI iam working on, it should be possible to use NB for when machine code generation is forbidden. In this project I am having discussions and working with Igor, Esteban, Clement and Eliot. Currently OSWindow is mostly for Pharo, but it should be possible to have it for more Smalltalks. As for the existing VM windows, we removed it completely for Linux with Igor. In Pharo, we don't want to maintain that old code in C, because is huge, really hard to understand and it has his limitations. For example, with the old VM window we have to pass mouse wheel events as if there keyboard presses. Windows and Mac OS X are next. In OSWindow, we receive the raw events that SDL2 or an operating system specific backend provide us. Later I will try it with a joystick. ------------------ -- VM Changes ---------------------- The SDL2Display plugin has the following code: extern struct VirtualMachine* interpreterProxy; extern void setIoProcessEventsHandler(void * handler); static int inited = 0; static int inputSemaphoreIndex = 0; /** * Called by the VM heartbeat if installed, to check for the presence of events. */ static void ioCheckForEvents() { if (inited) { SDL_PumpEvents(); if (SDL_HasEvents(SDL_FIRSTEVENT, SDL_LASTEVENT)) { interpreterProxy->signalSemaphoreWithIndex(inputSemaphoreIndex); } } } void setSDL2InputSemaphoreIndex(int semaIndex) { inited = 1; inputSemaphoreIndex = semaIndex; setIoProcessEventsHandler(&ioCheckForEvents); } The only change needed for existing platform specific driver is to implement: extern void setIoProcessEventsHandler(void * handler); In Windows, I just had to add: /*sqWin32Window.c*/ /*Line 179*//** * HACK: Hook for SDL2. */ static void (*ioCheckForEventsHooks)(void); EXPORT(void) setIoProcessEventsHandler(void * handler) { ioCheckForEventsHooks = (void (*)())handler; } /*Line 1586 */ /* HACK: for SDL2.*/ if(ioCheckForEventsHooks) ioCheckForEventsHooks(); I called them hacks, because a proper way means killing that code. As for the VM Windows code, it gives me the impression of being unnecessarily complex and to also have performance issues. In my laptop in Linux it takes about one minute to load NBOpenGL into a new image, but in Windows it takes about one hour, in the same machine. It could be my impression, but is window using multiples thread, one for IO and another for the actual VM? Greetings, Ronie 2014-05-31 11:39 GMT-04:00 phil(a)highoctane.be <phil(a)highoctane.be>: > Ronie, > > Throw the VM sources somewhere so that I can try this on CentOS. Glibc > 2_15 issue... > > Phil > > > On Sat, May 31, 2014 at 5:12 PM, Laurent Laffont < > laurent.laffont(a)gmail.com> wrote: > >> Hi, >> >> >> >> Seems to work well on my linux machine too (Arch 64). The main Pharo >> window is better handled by KDE (don't know why, but nice side effect :) >> >> >> >> Laurent >> >> >> >> Le samedi 31 mai 2014, 05:54:52 Ronie Salgado a Ã©crit : >> >> > 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] GPU accelerated GUI

by Hilaire Fernandes

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(a)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

May 31, 2014

Re: [Pharo-dev] OpenGL 3.0+

by Ben Coman

May 31, 2014

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

by phil＠highoctane.be

Ronie, Throw the VM sources somewhere so that I can try this on CentOS. Glibc 2_15 issue... Phil On Sat, May 31, 2014 at 5:12 PM, Laurent Laffont <laurent.laffont(a)gmail.com> wrote: > Hi, > > > > Seems to work well on my linux machine too (Arch 64). The main Pharo > window is better handled by KDE (don't know why, but nice side effect :) > > > > Laurent > > > > Le samedi 31 mai 2014, 05:54:52 Ronie Salgado a Ã©crit : > > > 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] Initial versions for OSWindow and Woden

by Laurent Laffont

Hi, Seems to work well on my linux machine too (Arch 64). The main Pharo window is better handled by KDE (don't know why, but nice side effect :) Laurent Le samedi 31 mai 2014, 05:54:52 Ronie Salgado a Ã©crit : > 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] GPU accelerated GUI

by ClÃ©ment Bera

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(a)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 > > >

May 31, 2014

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

by kilon alios

sorry I was not clear, I mean in system settings. I can't find the option. On Sat, May 31, 2014 at 3:34 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > 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 Esteban Lorenzano

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(a)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 > >

May 31, 2014