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

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

by Stephan Eggermont

Sven wrote: >PS2: I am not sure I am allowed to fix this so close to release, is it a feature or a bug fix ? ;-) Donât worry, if you look at the slope of our issue burndown chart you might notice that we need to change directions to get closer to releaseâ¦ Stephan

March 27, 2014

Re: [Pharo-dev] Smalltalkhub & API

by phil＠highoctane.be

Ah, good. I'll look at that. Thx

March 27, 2014

Re: [Pharo-dev] Smalltalkhub & API

by Stephan Eggermont

Hi Phil, Did you take a look at a smalltalkhub image https://ci.inria.fr/pharo-contribution/job/SmalltalkHub/ The Hub package provides a starting point. Stephan

March 27, 2014

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

by Esteban A. Maringolo

2014-03-27 16:18 GMT-03:00 Johan Brichau <johan(a)inceptive.be>: > Sven, > > FYI, if you have the slice, I can run all our tests against it. > We do just a little bit of things with DateAndTime in a planning app :-) so potential issues might be exposed. My app also deals with schedules, that's how I found this :) But I'm sure I don't have as many tests as you do. o.O Esteban A. Maringolo

March 27, 2014

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

by Johan Brichau

Sven, FYI, if you have the slice, I can run all our tests against it. We do just a little bit of things with DateAndTime in a planning app :-) so potential issues might be exposed. Johan On 27 Mar 2014, at 15:17, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Umbrella issue: > > https://pharo.fogbugz.com/f/cases/13139/Speed-Regressions-in-DateAndTime > > I rewrote (and simplified) DateAndTime>>#+ #- #= > I added caching for #epoch > I switched the localTimeZone to an #asFixedTimeZone variant > > My benchmark now runs 40x FASTER than in Pharo 1.4 > > All Chronology tests remain green. > > I will upload slices when the funding goal of 1,000,000 USD is reached on https://www.kickstarter.com/projects/1003214829/improve-pharo-dateandtime-p… > > PS: Half of the funds will go to Camillo for making DateAndTime work in UTC internally ;-) > > PS2: I am not sure I am allowed to fix this so close to release, is it a feature or a bug fix ? ;-) > > On 27 Mar 2014, at 12:29, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > >> >> On 27 Mar 2014, at 11:55, Johan Brichau <johan(a)inceptive.be> wrote: >> >>> On 27 Mar 2014, at 11:50, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >>> >>>> It is slow(er) in 2 and fast(er) in 3, according to this discussion and my reading of the code. If you see the inverse, than please provide some details. >>> >>> We come from Pharo 1.4, where our timing benchmarks that use a lot of DateAndTime operations run 4x faster (in Gemstone too). >>> It is indeed faster in 3 than in 2. (I believe because of a wait in de DateAndTime creation that has to do with clock precision). >>> >>> Johan >> >> An x4 (400%) slowdown sounds like an unacceptable regression to me. >> >> Could you maybe provide some benchmark ? >> >> I did a quick one (in Pharo 3): >> >> [ >> | timestamps | >> timestamps := Array streamContents: [ :out | >> 1024 timesRepeat: [ out nextPut: (DateAndTime now - (60*60*24*265) atRandom seconds) ] ]. >> 64 timesRepeat: [ timestamps sorted ]. >> timestamps sort. >> timestamps collect: [ :each | timestamps includes: each ] ] timeToRun. >> >> => "0:00:00:09.491" >> >> In 1.4, this is indeed about 40 times faster: >> >> [ >> | timestamps | >> timestamps := Array streamContents: [ :out | >> 1024 timesRepeat: [ out nextPut: (DateAndTime now - (60*60*24*265) atRandom seconds) ] ]. >> 64 timesRepeat: [ timestamps sorted ]. >> timestamps sort. >> timestamps collect: [ :each | timestamps includes: each ] ] timeToRun milliSeconds. >> >> => "0:00:00:00.228" >> >> For this test, ZTimestamp is 100 times faster: >> >> [ >> | timestamps | >> timestamps := Array streamContents: [ :out | >> 1024 timesRepeat: [ out nextPut: (ZTimestamp now - (60*60*24*265) atRandom seconds) ] ]. >> 64 timesRepeat: [ timestamps sorted ]. >> timestamps sort. >> timestamps collect: [ :each | timestamps includes: each ] ] timeToRun. >> >> => "0:00:00:00.07" >> >> Looking at this with the Time Profiler, I see that DateAndTime>>#asSeconds (used in #<) takes 95% of the time. I am pretty sure we can fix this. I'll make an issue and slice later on. >> >> Sven >> > > > > -- > Sven Van Caekenberghe > Proudly supporting Pharo > http://pharo.org > http://association.pharo.org > http://consortium.pharo.org > > > > >

March 27, 2014

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

by J.F. Rick

Ubuntu (latest) + Arial font (though other fonts have the same problem). Cheers, Jeff On Thu, Mar 27, 2014 at 4:44 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > 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. > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

March 27, 2014

Re: [Pharo-dev] Redraw suggestion for Athens

by J.F. Rick

Sure. It's just a change to Pharo that a switch to Athens rendering could enable. You couldn't quite do the same thing in BitBlt / current Morphic as you would need three forms: one for rendering, one inactive one, and one active one. Switching to Athens would make the V-Sync thing be quite efficient as you wouldn't be copying large amount of bits from one form to another on a regular basis. Cheers, Jeff On Thu, Mar 27, 2014 at 5:09 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > 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). > > > > -- Jochen "Jeff" Rick, Ph.D. http://www.je77.com/ Skype ID: jochenrick

March 27, 2014

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

by Pharo4Stef

> Btw, guys i need some details: > - what platform you using Windows and Linux (this is the moose image). > - what default font you using No idea. We will give you the image of nicolas and the image of the contact I got. It happens on windows for her. Apparently people where putting the same image on a different machines and it worked. Nicolas got a problem on linux. May be this is just a stupid use of freetype with the settings but since WE DO NOT understand font the setting should do it right. Stef

March 27, 2014

Re: [Pharo-dev] Pen back in the image

by Pharo4Stef

build it on top of athens On 27 Mar 2014, at 17:33, Hilaire Fernandes <hilaire.fernandes(a)gmail.com> wrote: > I think too it is nice class to introduce to programming > > Hilaire > > Le 27/03/2014 17:17, phil(a)highoctane.be a Ã©crit : >> 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 > > -- > Dr. Geo http://drgeo.eu > >

March 27, 2014

Re: [Pharo-dev] SmalltalkHub update

by Yuriy Tymchuk

+1 On 27 Mar 2014, at 17:30, Stephan Eggermont <stephan(a)stack.nl> wrote: > Do you test with Safari? I get lots of restarts.10.9.2 > > Stephan >

March 27, 2014