- Pharo-dev - lists.pharo.org

Pen back in the image

by phil＠highoctane.be

Hello, I'd like to see the Pen class coming back in the main image. It really is useful for getting people acquainted with the tools and the bluebook uses it. I am not asking for a form editor (it could be handy though). Path is dead as it was hijacked by FileSystem. I miss it too. What do you people think? Phil

March 27, 2014

Re: [Pharo-dev] Redraw suggestion for Athens

by Igor Stasenko

On 26 March 2014 20:22, J.F. Rick <self(a)je77.com> wrote: > I've been using Athens to render my applications and I've thought a bit > about how the #changed mechanism might change when BitBlt rendering is > replaced by Athens rendering. First, you must realize that a lot of the > rendering in Morphic is highly specialized to deal with the slowness of > BitBlt rendering. So, a morph that has changed in appearance (by moving, > etc.) calls the #changed message on itself. This tells morphic that it > needs to get rerendered when the screen is next being updated. The full > bounds of the morph are then added to the damage recorder. When the UI loop > gets around to it, the damage areas are rerendered in a relatively smart > fashion. For instance, if a morph is opaque, none of the morphs behind it > get rendered. Only the damage rectangles are copied to the canvas, which is > then updated. > > With Athens, this strategy is problematic. Because Athens allows for > arbitrary rotation and scaling, it is much more difficult to determine the > bounds of a specific morph. Athens also can use local positioning as > opposed to the global positioning currently used in Morphic. Igor argues > that it is best not to try to figure this out but just to render everything > when anything has changed. In my experience, that is a reasonable > proposition. Athens rendering is fast enough that even full animation could > be done reasonably. That would also simplify the #changed code and could > pretty much eliminate the damage recorder. > > OK. That's enough setup. Now for the suggestion. One problem I still have > with Athens rendering is that there is still a visual artifact that has to > do with the screen refresh not being in sync with the UI loop. Half the > screen renders the previous frame and the other half renders the current > frame. While it only is noticeable when moving something fast, it still > isn't nice. So, here's the suggestion. Have two Athens surfaces in memory > that switch between being the one next to be rendered and the active one. > When the screen refresh comes along, send it to the last one rendered > (i.e., the active one). When a change happens, render the surface on the > inactive one. When that is done, make it the active one. Thus, the screen > update always has an accurate form. It also would mean less copying around > of forms (i.e., cacheing). I'm not sure if this implementation is viable, > but it seems like a fairly efficient strategy that Athens could enable. > > Right. This is something what called V-Sync. And all i can tell about it, that it is out of scope of Athens, because there's nothing in Athens API which tells where the results of drawing will be used: on screen, printed on paper, into file etc.. Dealing with it requires another device-specific layer which controls it, in our case - the layer responsible for delivering content to the screen. Apparently for such layer (if it will appear one day - like in OSWindow), it should be completely orthogonal, where content comes from: from Athens, BitBlt or other source(s).

March 27, 2014

Re: [Pharo-dev] Font problem is still there

by Igor Stasenko

Btw, guys i need some details: - what platform you using - what default font you using On 26 March 2014 21:27, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Thanks, indeed :) > > Please keep us informed. > > Doru > > > On Wed, Mar 26, 2014 at 5:57 PM, Alexandre Bergel <alexandre.bergel(a)me.com > > wrote: > >> > I didn't tried to debug it, i can't bet it would be easy (need to build >> a debug version of cairo first) >> > but it worth trying. >> > Meanwhile i will put workaround back. >> >> Thanks Igor. Let us know! >> >> Alexandre >> >> >> > >> > > Hi! >> > > >> > >> there's some kind of caching interference either in cairo or between >> cairo and freetype, >> > >> when using identity transformation matrix and integral (integer) >> font sizes. >> > >> and there is a simple workaround: >> > >> >> > >> canvas pathTransform restoreAfter: [ >> > >> canvas pathTransform scaleBy: 1.00001. >> > >> "draw text here" >> > >> >> > >> ] >> > >> >> > >> this workaround was in font-rendering code, but then i removed it, >> because i thought problem was solved. >> > > >> > > Can we add this back please? >> > > This font problem is quite serious. It makes people laugh at Pharo... >> > >> > >> > >> > >> > -- >> > Best regards, >> > Igor Stasenko. >> >> -- >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> Alexandre Bergel http://www.bergel.eu >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- Best regards, Igor Stasenko.

March 27, 2014

Re: [Pharo-dev] Strange left-over in 30804

by Marcus Denker

On 27 Mar 2014, at 16:31, Goubier Thierry <thierry.goubier(a)cea.fr> wrote: > Hi All, > > has anybody noticed a strange new RPackage in 30804 named: FloatArray-dot.st ? I can't miss it with AltBrowser, and it's visible in Nautilus, but not in Browser. Strange, I just filed in that .st file when integrating. This should normally not create any packageâ¦. Marcus

March 27, 2014

Strange left-over in 30804

by Goubier Thierry

Hi All, has anybody noticed a strange new RPackage in 30804 named: FloatArray-dot.st ? I can't miss it with AltBrowser, and it's visible in Nautilus, but not in Browser. Thierry -- Thierry Goubier CEA list Laboratoire des Fondations des SystÃ¨mes Temps RÃ©el EmbarquÃ©s 91191 Gif sur Yvette Cedex France Phone/Fax: +33 (0) 1 69 08 32 92 / 83 95

March 27, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Esteban A. Maringolo

2014-03-27 12:21 GMT-03:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > On 27 Mar 2014, at 12:14, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> On 27 Mar 2014, at 15:46, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >>> Will the fix be available for Pharo 2 builds as well? >> >> I knew you were going to ask that, but I don't know. The whole Chronology package was changed quite a lot going from 2.0 -> 3.0 >> >> On the other hand, my changes are pretty comprehensible (a couple of methods), somebody could certainly try to backport them - but no guarantees they will work though. > > pharo3 is at the corner to be out. > we are not integrating/backporting changes to pharo2 since... well, like 6 months. > so no, it will not be there and it will not be integrated. What is the support strategy for stable versions? Pharo 3 is still beta/release-candidate, so... strictly speaking Pharo 2 is the official stable version. Shouldn't it get support as such? If resource scarcity rules here, I'll understand. > said so... anyone can do their own backport and put it for others in a meta repo :) It will be so. :) Esteban A. Maringolo

March 27, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Esteban A. Maringolo

2014-03-27 12:14 GMT-03:00 Sven Van Caekenberghe <sven(a)stfx.eu>: > On 27 Mar 2014, at 15:46, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: >> Will the fix be available for Pharo 2 builds as well? > I knew you were going to ask that, but I don't know. :) > The whole Chronology package was changed quite a lot going from 2.0 -> 3.0 I know, but this is a "bugfix" not a feature enhancement or is it? :) I know Pharo 3 is uber cool, and way better... but... you'll understand. > On the other hand, my changes are pretty comprehensible (a couple of methods), somebody could certainly try to backport them - but no guarantees they will work though. I could give them a try. If all tests passes I can contribute the patch back. I have no hurry to fix this. But, but cutting ~40% of response time is a lot in web terms :) Regards,

March 27, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Esteban Lorenzano

On 27 Mar 2014, at 12:14, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > > On 27 Mar 2014, at 15:46, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > >> Will the fix be available for Pharo 2 builds as well? > > I knew you were going to ask that, but I don't know. The whole Chronology package was changed quite a lot going from 2.0 -> 3.0 > > On the other hand, my changes are pretty comprehensible (a couple of methods), somebody could certainly try to backport them - but no guarantees they will work though. pharo3 is at the corner to be out. we are not integrating/backporting changes to pharo2 sinceâ¦ well, like 6 months. so no, it will not be there and it will not be integrated. said soâ¦ anyone can do their own backport and put it for others in a meta repo :) Esteban

March 27, 2014

[Job] netstyle.ch is hiring! (v2)

by Christoph Wysseier

Hi all We are still looking for web application developers (Smalltalk/Seaside). Because of the lack of applications so far we reduced our primary restrictions: - German is not a must anymore, we accept applications from any experienced Smalltalk developers but we expect applicants to speak English fluently. - Citizenship does not matter anymore, we are going to take care of your work permit, if necessary. - No freelancer applications please, this is a permanent position located in Berne, Switzerland! [ Job Description ] netstyle.ch is looking for a Seaside web application developer. We are a small, agile and harmonious team located in Berne (Switzerland). With Cmsbox we have developed an award winning Content Management System with hundreds of installations so far. We also develop sophisticated web applications for longterm clients. The successful candidate must have excellent skills in OO software development with a dynamic programming language and fit in a team of young, ambitious engineers. For questions and applications please contact me at info(a)netstyle.ch. -- Christoph Wysseier netstyle.ch GmbH, CEO

March 27, 2014

Re: [Pharo-dev] DateAndTime>>#= slow?

by Sven Van Caekenberghe

On 27 Mar 2014, at 15:46, Esteban A. Maringolo <emaringolo(a)gmail.com> wrote: > Will the fix be available for Pharo 2 builds as well? I knew you were going to ask that, but I don't know. The whole Chronology package was changed quite a lot going from 2.0 -> 3.0 On the other hand, my changes are pretty comprehensible (a couple of methods), somebody could certainly try to backport them - but no guarantees they will work though.

March 27, 2014