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

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

by Igor Stasenko

On 24 May 2010 17:22, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> Yes, i actually want to do that. > > I'm trying to understand the reason of such a plan? > Is it because like that the clients of existing rendering do not have to be touched? > To make things minimally dependent on implementation. >> >> I plan to inject the new methods into a Morph >> >> Morph>>fullDrawOnRomeCanvas: aCanvas >> Morph>>drawOnRomeCanvas: aCanvas >> >> which should tell the morph to use a different instructions/commands >> to perform drawing, >> to conform with RomeReferenceCanvas protocol. >> >> I don't want to repeat a balloon canvas protocol. > > what was wrong with it? > I did this once for GLCanvas, and don't want to repeat that again :) The Balloon canvas and its uses is too damn focused on blitting, which makes it too hard to provide a backend which doing most things on GPU. If you want to go into vector world, you should keep a distance from any blitting operations. Simply because they are ineffective, CPU hungry and don't scale well. >> >> Then, eventually, when we will have everything ready, >> we will be free to use different rendering backend than Balloon canvas. >> >> And its important to make it a non-intrusive. >> So, the plan is: >> >> - create a separate package, which will contain extension methods >> to Morph and its various subclasses. And maybe some little classes. >> >> - this package !!_should not_!! have any dependencies on Rome , and >> should be loaded cleanly, >> even if you don't have Rome installed. >> It only should conform with Rome canvas protocol for implementing rendering. >> >> This will ensure a backend agnostic nature of new morphic rendering code. >> >> If you think this plan is cool, then lets pick a package name and >> repository, and i will start happy coding :) >> >>>> >>>>> Regards, >>>>> Â Â Â Â Â Â Javier. >>>>> >>>>> 2010/5/23 Igor Stasenko <siguctua(a)gmail.com> >>>> >>>> >>>> -- >>>> Best regards, >>>> Igor Stasenko AKA sig. >>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> Pharo-project(a)lists.gforge.inria.fr >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

May 24, 2010

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

by StÃ©phane Ducasse

> > Yes, i actually want to do that. I'm trying to understand the reason of such a plan? Is it because like that the clients of existing rendering do not have to be touched? > > I plan to inject the new methods into a Morph > > Morph>>fullDrawOnRomeCanvas: aCanvas > Morph>>drawOnRomeCanvas: aCanvas > > which should tell the morph to use a different instructions/commands > to perform drawing, > to conform with RomeReferenceCanvas protocol. > > I don't want to repeat a balloon canvas protocol. what was wrong with it? > > Then, eventually, when we will have everything ready, > we will be free to use different rendering backend than Balloon canvas. > > And its important to make it a non-intrusive. > So, the plan is: > > - create a separate package, which will contain extension methods > to Morph and its various subclasses. And maybe some little classes. > > - this package !!_should not_!! have any dependencies on Rome , and > should be loaded cleanly, > even if you don't have Rome installed. > It only should conform with Rome canvas protocol for implementing rendering. > > This will ensure a backend agnostic nature of new morphic rendering code. > > If you think this plan is cool, then lets pick a package name and > repository, and i will start happy coding :) > >>> >>>> Regards, >>>> Javier. >>>> >>>> 2010/5/23 Igor Stasenko <siguctua(a)gmail.com> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

[Pharo-project] Need someone to test if NBOpenGL works for you on win32

by Igor Stasenko

Hi, i just snapshotted my stuff with various fixes, to make it load cleanly on pharo and squeak images. I'd like you to ask to test and load it and tell me if it works for you. Currently it works only on win32 platform. It could work on Linux, but i didn't had time to port it yet. There is no automatic installation procedure right now, so here what you should try: - first, you need to have VM with NativeBoost plugin + NativeBoost loaded into an image (see http://code.google.com/p/nativeboost/wiki/Installation for instructions) - then load the OpenGL stuff from http://www.squeaksource.com/NBOpenGL in following order: - NBOpenGL-Core - NBOpenGL-Win - NBOpenGL-TrueType - NBOpenGL-Display - NBOpenGL-Morphic i tried the above on Pharo-1.1-11367-Betadev10.05.1.image , which were released recently, and it seems works ok. on squeak/trunk it should also work without problems. Now, if everything went right, then we're ready to run a demo: GLViewportMorph new "useOwnForm: true;" openInWorld This thing should render a TrueType glyphs and animating a smooth zoom of it. Nothing fancy, i just wanna know, if it works for you (and how well). :) As you may know, GPU/OpenGL implementations vary depending on vendor and how old your hardware is, and i don't have all of it at my disposal. Ok.. if you got it running, and it renders the glyphs.. there's one thing left: - save your image and quit (without closing this morph) - start image it should continue working as if nothing happens. -- Best regards, Igor Stasenko AKA sig.

May 24, 2010

Re: [Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

by Igor Stasenko

Just an idea how to call the package: Romph-Rendering if you swizzle first 3 letters, you'll get Morph-Rendering :) On 24 May 2010 14:36, Igor Stasenko <siguctua(a)gmail.com> wrote: > On 24 May 2010 13:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: >> >> On May 23, 2010, at 11:04 PM, Igor Stasenko wrote: >> >>> 2010/5/23 Javier PimÃ¡s <elpochodelagente(a)gmail.com>: >>>> Hi, may I ask how you are rendering these fonts? You parse the glyphs and >>>> then render lines with opengl or use freetype to render to a texture without >>>> antialiasing or both? >>> >>> Squeak has already a TT font reader, so i just taking the data from there >>> and piping to GPU. >>> What you see here is freely scalable vector/curve rendering done >>> completely on GPU. >>> >>>> If you asked me, I'd say I like the method but for >>>> fonts they look a bit blury, I'd say too much for the smaller ones. >>> >>> I think this is best what you can achieve without hinting / subpixel AA. >>> >>>> Also, what are you working on? >>>> >>> I once did a GLCanvas, >>> and now i want to reiterate and improve it using new callout mechanism >>> (NativeBoost), >>> and full coverage of OpenGL API, with all extensions available at your disposal. >> >> Igor it would be good it we could have >> >> NativeBoostRomeCanvas >> >> if you see what I mean :) >> > > Yes, i actually want to do that. > > I plan to inject the new methods into a Morph > > Morph>>fullDrawOnRomeCanvas: aCanvas > Morph>>drawOnRomeCanvas: aCanvas > > which should tell the morph to use a different instructions/commands > to perform drawing, > to conform with RomeReferenceCanvas protocol. > > I don't want to repeat a balloon canvas protocol. > > Then, eventually, when we will have everything ready, > we will be free to use different rendering backend than Balloon canvas. > > And its important to make it a non-intrusive. > So, the plan is: > > - create a separate package, which will contain extension methods > to Morph and its various subclasses. And maybe some little classes. > > - this package !!_should not_!! have any dependencies on Rome , and > should be loaded cleanly, > even if you don't have Rome installed. > It only should conform with Rome canvas protocol for implementing rendering. > > This will ensure a backend agnostic nature of new morphic rendering code. > > If you think this plan is cool, then lets pick a package name and > repository, and i will start happy coding :) > >>> >>>> Regards, >>>> Â Â Â Â Â Â Javier. >>>> >>>> 2010/5/23 Igor Stasenko <siguctua(a)gmail.com> >>> >>> >>> -- >>> Best regards, >>> Igor Stasenko AKA sig. >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> > > > > -- > Best regards, > Igor Stasenko AKA sig. > -- Best regards, Igor Stasenko AKA sig.

May 24, 2010

[Pharo-project] Rome Canvas to replace an ordinary canvas [Was: Re: Rendering fonts on OpenGL ]

by Igor Stasenko

On 24 May 2010 13:36, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > > On May 23, 2010, at 11:04 PM, Igor Stasenko wrote: > >> 2010/5/23 Javier PimÃ¡s <elpochodelagente(a)gmail.com>: >>> Hi, may I ask how you are rendering these fonts? You parse the glyphs and >>> then render lines with opengl or use freetype to render to a texture without >>> antialiasing or both? >> >> Squeak has already a TT font reader, so i just taking the data from there >> and piping to GPU. >> What you see here is freely scalable vector/curve rendering done >> completely on GPU. >> >>> If you asked me, I'd say I like the method but for >>> fonts they look a bit blury, I'd say too much for the smaller ones. >> >> I think this is best what you can achieve without hinting / subpixel AA. >> >>> Also, what are you working on? >>> >> I once did a GLCanvas, >> and now i want to reiterate and improve it using new callout mechanism >> (NativeBoost), >> and full coverage of OpenGL API, with all extensions available at your disposal. > > Igor it would be good it we could have > > NativeBoostRomeCanvas > > if you see what I mean :) > Yes, i actually want to do that. I plan to inject the new methods into a Morph Morph>>fullDrawOnRomeCanvas: aCanvas Morph>>drawOnRomeCanvas: aCanvas which should tell the morph to use a different instructions/commands to perform drawing, to conform with RomeReferenceCanvas protocol. I don't want to repeat a balloon canvas protocol. Then, eventually, when we will have everything ready, we will be free to use different rendering backend than Balloon canvas. And its important to make it a non-intrusive. So, the plan is: - create a separate package, which will contain extension methods to Morph and its various subclasses. And maybe some little classes. - this package !!_should not_!! have any dependencies on Rome , and should be loaded cleanly, even if you don't have Rome installed. It only should conform with Rome canvas protocol for implementing rendering. This will ensure a backend agnostic nature of new morphic rendering code. If you think this plan is cool, then lets pick a package name and repository, and i will start happy coding :) >> >>> Regards, >>> Â Â Â Â Â Â Javier. >>> >>> 2010/5/23 Igor Stasenko <siguctua(a)gmail.com> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

May 24, 2010

[Pharo-project] [ENH] CompiledMethodTrailer with a different CompiledMethod class

by Igor Stasenko

Hello, i added a simple enhancement to make CompilerMethodTrailer to be more friendly with CompiledMethod subclasses. It provides an additional method #createMethod:header:methodClass: which allows to create a compiled method with other class, than a CompiledMethod. Installing it requires 2 separate phases: phase1 - adds #createMethod:header:methodClass: method phase2 - puts this method in use. if you merge these changesets, you'd will run into a problem, because filein/fileout utility does not honors the order of changes, how they should be applied. On 24 May 2010 13:27, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > and send us the fix for inclusion :) > > On May 24, 2010, at 10:54 AM, Igor Stasenko wrote: > >> On 24 May 2010 10:31, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> wrote: >>> Hello >>> >>> Just to make a little note. I'm adapting the lightweight classes >>> package to work with CompilerMethodTrailer. In this method >>> >>> CompiledMethodTrailer>>createMethod: numberOfBytesForAllButTrailer >>> header: headerWord >>> Â Â Â Â | meth | >>> Â Â Â Â encodedData ifNil: [ self encode ]. >>> Â Â Â Â meth := CompiledMethod newMethod: numberOfBytesForAllButTrailer + >>> size header: headerWord. >>> Â Â Â Â ... >>> >>> I need to answer a different kind of CompiledMethod, it would be nice >>> if my own CompiledMethod class could be specified in some way to make >>> the CompiledMethodTrailer more flexible. >> >> Yes, you could add a class parameter, so method will take 3 >> >> createMethod: numberOfBytesForAllButTrailer header: headerWord class: >> aMethodClass >> >>> Cheers, >>> >>> HernÃ¡n >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> Pharo-project(a)lists.gforge.inria.fr >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> >> -- >> Best regards, >> Igor Stasenko AKA sig. >> >> _______________________________________________ >> Pharo-project mailing list >> Pharo-project(a)lists.gforge.inria.fr >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig.

May 24, 2010

Re: [Pharo-project] TORCH: supporting source-code change integration

by StÃ©phane Ducasse

Hi veronica I wanted to use Torch to check inbox published change and I get TCTrait>>parAuthorAlia.... When I tried to look at Slice-hasEqualElement (using Torch build on 11370) Stef On May 18, 2010, at 11:00 AM, Veronica Isabel Uquillas Gomez wrote: > Dear all, > > I would like to announce Torch, a tool for supporting source-code change integration. For now, it offers visualizations of the changes and enhanced change lists. > Torch can be accessed through Monticello (in the main MC browser, in the repository browser or in the history browser). Selecting a version or slice, you can view the changes with Torch using the contextual menu. > Once you open the Torch dashboard, you can access the enhanced change list or a detailed visualization via the contextual menu as well. > > Torch is available on SqueakSource, the repository is named Torch, and you need to load the ConfigurationOfTorch package. > It runs in a dev or core image. > > For a dev image. > - ConfigurationOfTorch loadVersion10 > > For a core image. > 1) Set fonts - described in the attached file. > 2) ConfigurationOfTorch loadDefault > > I would appreciate comments and feedback! > > Best Regards, > VerÃ³nica Uquillas GÃ³mez > Vrije University Brussel - SOFT Lab > University of Lille - RMOD Team > > <torchFontsScript.st> > > > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

Re: [Pharo-project] [squeak-dev] runSimulated behaviour

by StÃ©phane Ducasse

tx! On May 23, 2010, at 11:24 PM, Eliot Miranda wrote: > Hi Michael, Michael, Dennis, Hi All, > > I think this is a simple bug in ContextPart >> #tryNamedPrimitiveIn:for:withArgs:, which neglects to flush the method cache for the method and/or selector used to simulate execution of a named primitive. With the relevant flushCacher calls added I no longer see any of the simulation failures recently experienced (someMethod getSourceFromFile, TimeStamp now). Please test the attached and let me know how you get on. > > The problem is caused by using the same method to invoke differet primitives in quick succession where, because the method cache is not flushed, the wrong primitive (a previous primitive) is left in the cache and invoked instead of the desired primitive. In Cog I added a primitive to directly evaluate a named primitive so the problem does not occur. Adding the two lines marked >> below fixes the problem. The line "theMethod flushCache" is probably more than we need, but does not harm. > > HTH > Eliot > > > !ContextPart methodsFor: 'private' stamp: 'eem 5/23/2010 14:13'! > tryNamedPrimitiveIn: aCompiledMethod for: aReceiver withArgs: arguments > "Hack. Attempt to execute the named primitive from the given compiled method" > | selector theMethod spec | > arguments size > 8 ifTrue:[^PrimitiveFailToken]. > selector := #( > tryNamedPrimitive > tryNamedPrimitive: > tryNamedPrimitive:with: > tryNamedPrimitive:with:with: > tryNamedPrimitive:with:with:with: > tryNamedPrimitive:with:with:with:with: > tryNamedPrimitive:with:with:with:with:with: > tryNamedPrimitive:with:with:with:with:with:with: > tryNamedPrimitive:with:with:with:with:with:with:with:) at: arguments size+1. > theMethod := aReceiver class lookupSelector: selector. > theMethod == nil ifTrue:[^PrimitiveFailToken]. > spec := theMethod literalAt: 1. > spec replaceFrom: 1 to: spec size with: (aCompiledMethod literalAt: 1) startingAt: 1. > >> theMethod flushCache. > >> selector flushCache. > ^aReceiver perform: selector withArguments: arguments! ! > > On Thu, May 20, 2010 at 2:55 AM, Michael Haupt <mhaupt(a)gmail.com> wrote: > Dear all, > > we're observing some strange behaviour in simulated bytecode execution > in Squeak (4.1, on Macs). > > Printing this: > ContextPart runSimulated: [ TimeStamp now ] > will work once and then reproducibly fail with code simulation errors. > > This works well (also reproducibly): > ContextPart trace: [ TimeStamp now ] > > Going to more detail, we figured out that simulation reproducibly > works if things are written to the Transcript every now and then. > Printing this: > n:=0. thisContext runSimulated: [ TimeStamp now ] contextAtEachStep: [ > :c | n\\100=0 ifTrue: [ Transcript show: $. ] ] > works. > > We've tried to just insert some artificial delays (<someValue> > milliSeconds asDelay wait) in the block, but that will not > reproducibly work; it also leads to code simulation errors. So it > can't be just the time it takes to write to Transcript. Or so we > believe. > > Does anybody know the reason for this strange behaviour, or where in > the simulation logic to look? > > Best, > > Michael > > > <ContextPart-tryNamedPrimitiveInforwithArgs.st>_______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

Re: [Pharo-project] Metacello and SourceTalk ...

by StÃ©phane Ducasse

thanks for the update. Stef On May 24, 2010, at 2:42 AM, Julian Fitzell wrote: > The fact that MC2 is still a moving target. Or at least it would be if it was moving. :) More to the point, the early releases had some problems that prompted further redesign and I'd recommend against creating large amounts of date in those versions that will need to be brought forward. In other words, I don't think it's ready for prime time in its current state. > > Julian > > On Mon, May 17, 2010 at 1:34 PM, Geert Claes <geert.wl.claes(a)gmail.com> wrote: > > What would be the biggest challenges moving to MC2 and a MC2 Repository like > SourceTalk? > > > Mariano Martinez Peck wrote: > > > > Hi Geert. I agree it would awesome to have Monticello 2 and SourcTalk for > > Pharo 1.2. I have not idea the status. I tested once (you can see > > squeakdbx there) but I have a lot of problems. And the project seems > > "dead". I mean, I don't think someone is working on it. That said, it > > would be great someone to work on it and maybe start to using it by Pharo > > 1.2 > > > -- > View this message in context: http://forum.world.st/Metacello-and-SourceTalk-tp2219294p2219517.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010

Re: [Pharo-project] Rendering fonts on OpenGL

by StÃ©phane Ducasse

On May 23, 2010, at 11:04 PM, Igor Stasenko wrote: > 2010/5/23 Javier PimÃ¡s <elpochodelagente(a)gmail.com>: >> Hi, may I ask how you are rendering these fonts? You parse the glyphs and >> then render lines with opengl or use freetype to render to a texture without >> antialiasing or both? > > Squeak has already a TT font reader, so i just taking the data from there > and piping to GPU. > What you see here is freely scalable vector/curve rendering done > completely on GPU. > >> If you asked me, I'd say I like the method but for >> fonts they look a bit blury, I'd say too much for the smaller ones. > > I think this is best what you can achieve without hinting / subpixel AA. > >> Also, what are you working on? >> > I once did a GLCanvas, > and now i want to reiterate and improve it using new callout mechanism > (NativeBoost), > and full coverage of OpenGL API, with all extensions available at your disposal. Igor it would be good it we could have NativeBoostRomeCanvas if you see what I mean :) > >> Regards, >> Javier. >> >> 2010/5/23 Igor Stasenko <siguctua(a)gmail.com> > > > -- > Best regards, > Igor Stasenko AKA sig. > > _______________________________________________ > Pharo-project mailing list > Pharo-project(a)lists.gforge.inria.fr > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project

May 24, 2010