- Pharo-dev - lists.pharo.org

Re: [Pharo-project] Drawing speed for animations?

by Igor Stasenko

On 4 May 2012 17:50, Martin Drautzburg <Martin.Drautzburg(a)web.de> wrote: > Hello all, > > I am doing some smooth scrolling expriments. I use a step method in which I > adjust the display. When I set stepTime to 0, the time between steps is still > between 10 and 40 msces. During a scroll which takes 10 steps I see apx 1000 > redraws of fairly simple Morphs. That is 100 redraws per step. When an average > step takes apx. 20 msec this is 0.2 msec per redaw. Does this look normal, or > should I hunt for flaws in my program? > hard to say.. apparently every morph should be drawn only once per step. probably you mixing stepping and drawing/updating? during stepping you should change some state, like advance the counters, do some calculations etc.. and then _just_ invalidate morphs which need to be redrawn, but do not draw them directly. (use "self changed" for morph ) then morphic will take care about redrawing things which are changed. > If this is the normal speed, then I cannot do animations in morphic, such that > I get a new frame every 14 msec (70 Hz), at least not the way I am trying to > do it. > > Another thing I cannot explain is the following: when I repeatedly call my > step method from another method (putting a Delay between the calls), the > display does not always update. I just see the end of the scroll, but not the > steps in between. Only when I add a World displayWorld I see the intermediate > scroll positions. However, when I call step from an explorer the Display > updates just fine, without an explicit displayWorld. Why is that so? > because of deferred updates. you should use Display forceToScreen to actually update the display. > -- > Martin > -- Best regards, Igor Stasenko.

May 4, 2012

[Pharo-project] Drawing speed for animations?

by Martin Drautzburg

Hello all, I am doing some smooth scrolling expriments. I use a step method in which I adjust the display. When I set stepTime to 0, the time between steps is still between 10 and 40 msces. During a scroll which takes 10 steps I see apx 1000 redraws of fairly simple Morphs. That is 100 redraws per step. When an average step takes apx. 20 msec this is 0.2 msec per redaw. Does this look normal, or should I hunt for flaws in my program? If this is the normal speed, then I cannot do animations in morphic, such that I get a new frame every 14 msec (70 Hz), at least not the way I am trying to do it. Another thing I cannot explain is the following: when I repeatedly call my step method from another method (putting a Delay between the calls), the display does not always update. I just see the end of the scroll, but not the steps in between. Only when I add a World displayWorld I see the intermediate scroll positions. However, when I call step from an explorer the Display updates just fine, without an explicit displayWorld. Why is that so? -- Martin

May 4, 2012

Re: [Pharo-project] NativeBoost help

by Igor Stasenko

ok, Luc i just added support for our case in NB. See NativeBoost-Core-IgorStasenko.57 you can use structs as return value from functions now. let me know if it works :) -- Best regards, Igor Stasenko.

May 4, 2012

Re: [Pharo-project] Artefact - a PDF framework

by Stephan Eggermont

Why do we have so many ways to create pdfs, and why do most libraries/frameworks only provide a partial solution? At first it seems not to difficult to build something for what I need, so it makes sense to build it myself. But the pdf spec is large, and I don't use most of it. Building it myself makes more sense than trying to understand a current implementation. That is more complex than needed to solve the current problem, and building my own is a good way to understand the spec. Completing an implementation is hard to justify on project costs (as is mostly done for open source). More people seem to have followed the same road, so we end up with lots of partial solutions. Next time I need to create pdfs, I have different needs. Something with fonts, that seems like a lot of work. So I connect to a c library that already implements it. Only that has no way to create a document in-memory, just on diskâ¦ Artefact at the moment has very simple text layout and table algorithms. They are suitable for simple documents. High quality layout is complex as it needs to handle a.o. line breaking, justification, ligatures, kerning, hyphenation, text direction, text container shape, paragraph and page layout. PDF4Smalltalk is large because it is able to read and write pdfs, so it needs to have at least basic support for all pdf elements, and it contains lots of constants and mappings (glyph list, font metrics). Cairo (and Pango) by itself does not support reading pdfs. Stephan

May 4, 2012

[Pharo-project] [update 1.4] #14441

by Esteban Lorenzano

14441 ----- Issue 5445: Broken command-line arguments in 1.4 http://code.google.com/p/pharo/issues/detail?id=5445 (this is to enable running pharo tests in windows)

May 4, 2012

[Pharo-project] [update 2.0] #20049

by Marcus Denker

20049 ----- Issue 5751: SUnit-UI Interaction refactor http://code.google.com/p/pharo/issues/detail?id=5751 Issue 5445: Broken command-line arguments in 1.4 http://code.google.com/p/pharo/issues/detail?id=5445 -- Marcus Denker -- http://marcusdenker.de

May 4, 2012

Re: [Pharo-project] NativeBoost help

by Luc Fabresse

2012/5/4 Igor Stasenko <siguctua(a)gmail.com> > On 4 May 2012 10:38, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > > Hi Igor, > > > >> > >> there is a workaround. > >> all structs in C is returned via pointer. > >> so, actually a true return type of a function is CvSize* > > > > > > I agree that usually structs are returned through pointers. > > But here it is not the case. > > > > I want to wrap this function: > > CvSize cvGetSize( const CvArr* arr ); > > > > and the CvSize struct is returned by value. Am I wrong? > > > > i don't know.. this is a bit shady part of C ABI. > Some compilers use return-by-value, some return by pointer > by forcing a caller to pass a hidden implicit argument as a pointer to > the struct, which then filled with values by > the function you call. > > It is easy to add support for that, but to make it work correctly can > be tricky. > See this, for example: > > http://stackoverflow.com/questions/161788/are-there-any-downsides-to-passin… > > > >> > >> > >> so, what you do is to change the return value to simple void* > >> and then copy the contents of struct into instance of corresponding > >> NBExternalStructure subclass > >> using #fromPointer: method.. to conveniently access its fields values. > > > > > > yes I saw that in NB tests. > > > >> > >> > >> > >> but this is in general, in your case this function is actually inlined > >> by compiler (as CV_INLINE suggests), so there could be even no > >> exported symbol for it in dynamic library. > >> and the function is actually so simple, that you don't need to wrap it > at > >> all. > >> you can just create a subclass of NBExternalStructure , named CvSize, > >> implement fieldDesc method as: > >> > >> fieldsDesc > >> ^ #( > >> int width; > >> int height > >> ) > >> > >> > >> and if you invoke: > >> > >> CvSize new width: 1 height:2 > >> > >> it will be equivalent as if you will call cvSize(1,2) function. > > > > > > yes it is exactly what I did. > > > > So my problem is: > > > > NBCvSize implemented as a subclass of NBExternalStruct with fieldDesc > > correctly set up. > > Then wrap the function cvGetSize: > > > > getSize > > self nbCall: #(NBCvSize cvGetSize(IplImage self)) module: LIB_CV. > > > > But I get a debugger because: > > > > NBExternalStruct>>coerceReturn: gen > > " ... should we support handling return of external structures? " > > self error: 'returning pointer to structure?' > > > > And I have no idea how to implement this (black magic EAX pop push ;-)) > to > > coerce result of struct. > > > > > you don't. if function takes an implicit struct pointer, you can just > rewrite the function signature from > NBCvSize cvGetSize(IplImage self) > to: > > void cvGetSize(NBCvSize hidden, IplImage self) > > and so, you pass a fresh instance of NBCvSize as argument, which > function then fill. > I will investigate if this is the case. But, I "suppose" that for small structs, gcc does not bother with that. > But if C compiler using registers to return struct.. then you're screwed :) > Yes I was thinking of this case ;-) > > Anyways, Luc i will try to read docs about C ABI and see if we can > easily add support for that. > Thank you Igor! Luc

May 4, 2012

Re: [Pharo-project] NativeBoost help

by Igor Stasenko

On 4 May 2012 10:38, Luc Fabresse <luc.fabresse(a)gmail.com> wrote: > Hi Igor, > >> >> there is a workaround. >> all structs in C is returned via pointer. >> so, actually a true return type of a function is CvSize* > > > I agree that usually structs are returned through pointers. > But here it is not the case. > > I want to wrap this function: > CvSize cvGetSize( const CvArr* arr ); > > and the CvSize struct is returned by value. Am I wrong? > i don't know.. this is a bit shady part of C ABI. Some compilers use return-by-value, some return by pointer by forcing a caller to pass a hidden implicit argument as a pointer to the struct, which then filled with values by the function you call. It is easy to add support for that, but to make it work correctly can be tricky. See this, for example: http://stackoverflow.com/questions/161788/are-there-any-downsides-to-passin… >> >> >> so, what you do is to change the return value to simple void* >> and then copy the contents of struct into instance of corresponding >> NBExternalStructure subclass >> using #fromPointer: method.. to conveniently access its fields values. > > > yes I saw that in NB tests. > >> >> >> >> but this is in general, in your case this function is actually inlined >> by compiler (as CV_INLINE suggests), so there could be even no >> exported symbol for it in dynamic library. >> and the function is actually so simple, that you don't need to wrap it at >> all. >> you can just create a subclass of NBExternalStructure , named CvSize, >> implement fieldDesc method as: >> >> fieldsDesc >> ^ #( >> int width; >> int height >> ) >> >> >> and if you invoke: >> >> CvSize new width: 1 height:2 >> >> it will be equivalent as if you will call cvSize(1,2) function. > > > yes it is exactly what I did. > > So my problem is: > > NBCvSize implemented as a subclass of NBExternalStruct with fieldDesc > correctly set up. > Then wrap the function cvGetSize: > > getSize > Â Â Â self nbCall: #(NBCvSizeÂ cvGetSize(IplImage self)) module: LIB_CV. > > But I get a debugger because: > > NBExternalStruct>>coerceReturn: gen > " ... should we support handling return of external structures? " > self error: 'returning pointer to structure?' > > And I have no idea how to implement this (black magic EAX pop push ;-)) to > coerce result of struct. > you don't. if function takes an implicit struct pointer, you can just rewrite the function signature from NBCvSize cvGetSize(IplImage self) to: void cvGetSize(NBCvSize hidden, IplImage self) and so, you pass a fresh instance of NBCvSize as argument, which function then fill. But if C compiler using registers to return struct.. then you're screwed :) Anyways, Luc i will try to read docs about C ABI and see if we can easily add support for that. -- Best regards, Igor Stasenko.

May 4, 2012

Re: [Pharo-project] [update 2.0] #20045

by Camillo Bruni

most of it is in the class comments of CommandLineArguments and CommandLineHandler. Example: ======= Default options --------------- cogVM CommandLine/CommandLine.image --help cogVM CommandLine/CommandLine.image --version cogVM CommandLine/CommandLine.image --copyright List all the Installed handlers/subcommands ------------------------------------------- cogVM CommandLine/CommandLine.image --list Evaluate a String ----------------- cogVM CommandLine/CommandLine.image eval '1+2' cogVM CommandLine/CommandLine.image -e '1+2' cogVM CommandLine/CommandLine.image --evaluate '1+2' all in all I cleaned up the old command-line handling stuff and replaced it with something that's less static and slightly more flexible. On 2012-05-04, at 13:27, Sean P. DeNigris wrote: > > Marcus Denker-4 wrote >> >> Issue 5758: Improve CommandLine handling >> http://code.google.com/p/pharo/issues/detail?id=5758 >> > > Cool! This deserves some documentation... > > -- > View this message in context: http://forum.world.st/update-2-0-20045-tp4608123p4608400.html > Sent from the Pharo Smalltalk mailing list archive at Nabble.com. >

May 4, 2012

[Pharo-project] [update 2.0] #20048

by Marcus Denker

20048 ----- Issue 5793: More flexible special objects array http://code.google.com/p/pharo/issues/detail?id=5793 Issue 5802: Clean Embedded Temp Names: CompiledMethodTrailer http://code.google.com/p/pharo/issues/detail?id=5802 Issue 5791: Merge ExpandedSourceFileArray into SourceFileArray (part3: remove ExpandedSourceFileArray) http://code.google.com/p/pharo/issues/detail?id=5791 -- Marcus Denker -- http://marcusdenker.de

May 4, 2012