- Pharo-dev - lists.pharo.org

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

Smalltalkhub & API

by phil＠highoctane.be

Is there a way to ask for a set of project names under a given Team/User? I don't like maintaining lists like this one: #( 'BitmapCharacterSet' 'CollectionArithmetic' 'Coral' 'EventRecorder' 'FFICompatibility' 'FileSystemLegacy' 'Flotr' 'Gettext' 'ImageWorker' 'JSON' 'LDAP' 'LEDMorph' 'MorphExamplesAndDemos' 'NBOpenGL' 'OPAX' 'OrderPreservingDictionary' 'Pastell' 'Phexample' 'PlotMorph' 'PostgresV2' 'Postmark' 'ProfStef' 'RFB' 'ROE' 'SCouchDBViewServer' 'SMark' 'Smacc' 'Sound' 'Soup' 'Spotlight2' 'Tanker' 'XMLParser' 'XMLSupport' 'XMLWriter' 'XPath' 'readline') do: [ :projectName | MCRepositoryGroup default addRepository: ( MCSmalltalkhubRepository owner: 'PharoExtras' project: projectName) ]. Phil

March 27, 2014

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

by Hilaire Fernandes

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] Streaming problem in case of errors

by Damien Cassou

On Fri, Feb 28, 2014 at 3:59 PM, Damien Cassou <damien.cassou(a)gmail.com>wrote: > Camillo has another suggestion: https://pharo.fogbugz.com/f/cases/13008 > could you please review https://pharo.fogbugz.com/f/cases/13008 -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

March 27, 2014

Re: [Pharo-dev] SmalltalkHub update

by Stephan Eggermont

Do you test with Safari? I get lots of restarts.10.9.2 Stephan

March 27, 2014

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

by jannik laval

Hi Phil, There is a Pen in Phratch, named PhratchPen. You could probably extract it. There is also an editor. I discover last week that some command in this editor does not work, but the main feature is here. I am thinking that we can extract it too. Cheers, Jannik 2014-03-27 17:17 GMT+01:00 phil(a)highoctane.be <phil(a)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 > -- ~~Jannik Laval~~ Ãcole des Mines de Douai Enseignant-chercheur http://www.jannik-laval.eu http://car.mines-douai.fr/

March 27, 2014