First option is clean but there is no way to get the surface back to do further things. Second keeps the surface around and this is pretty useful and the class name implies there is something about Athens in there.
Now can't we have it both ways? By default it is the second option but when we, say, #withoutCairoDependency, we get the version 1 executed. and a #isCairoIndependent testing thing. anAthensCairoSurfaceForm asForm withoutCairoDependency -> aMundaneForm Phil On Mon, Feb 13, 2017 at 1:48 AM, Ronie Salgado <ronies...@gmail.com> wrote: > Hi, > > How about changing AthensCairoSurface >> asForm into the following > definition?: > asForm > > "create a form and copy an image data there" > | form | > self checkSession. > > self flush. > form := Form extent: (self width@self height) depth: 32. > form unhibernate. > LibC memCopy: self getDataPtr to: form bits size: self width*self > height*4. > ^ form > > This involves a whole copy, but it removes completely the dependency on > the surface plugin. > > If we want to keep using the surface plugin with Cairo, the old definition > of asForm still has a bug, which can be reproduced with the following > snippet: > > Smalltalk compiler evaluate: ' > | surface | > surface := AthensCairoSurface extent: 640@480. > surface drawDuring: [ :canvas | > surface clear: Color blue. > ]. > > surface asForm asMorph openInWindow > ' > > The problem with asForm, is that the form returned can be used after the > cairo surface which holds the pixels is garbage collected. The solution to > that problem, is the following (attached): > asForm > > "create a form and copy an image data there" > self checkSession. > > self flush. > ^ (AthensCairoSurfaceForm extent: (self width@self height) depth: 32 > bits: id) > surface: self; > yourself > > Where AthensCairoSurfaceForm(attached) is just a subclass of Form, that > holds a reference to the surface object that manages the lifetime of the > pixels referenced by the bits in the form. By having an extra reference to > the surface, we can prevent the finalization of it, until is not being > referenced by a form that uses its storage. > > Best regards, > Ronie > > 2016-12-21 5:27 GMT-03:00 Esteban Lorenzano <esteba...@gmail.com>: > >> would be possible to have one of your crashing images? >> so I can test… because one of my problems is that I’m not able to >> reproduce the problem when I try, and is hard to fix blindly... >> >> Esteban >> >> > On 21 Dec 2016, at 08:09, Alexandre Bergel <alexandre.ber...@me.com> >> wrote: >> > >> > I had plenty of elements in my Roassal visualization, and on some point >> it just crashed. >> > I have the impression that having many elements and / or animations (as >> in the case of Johan Fabry) triggers the crash. >> > >> > Alexandre >> > >> > >> >> On Dec 20, 2016, at 9:12 AM, Stephane Ducasse <stepharo.s...@gmail.com> >> wrote: >> >> >> >> So what was your crash problem? >> >> >> >> >> >> On Tue, Dec 20, 2016 at 8:43 AM, Alexandre Bergel < >> alexandre.ber...@me.com> wrote: >> >>> so did it work? >> >>> Is there something that we should do? >> >> >> >> I had no problem, but as Henrik and Peter said, the problem is likely >> to be more complex >> >> >> >> Alexandre >> >> >> >> >> >>> >> >>> On Fri, Dec 16, 2016 at 5:06 PM, Alexandre Bergel < >> alexandre.ber...@me.com> wrote: >> >>> Okay, trying… >> >>> >> >>> Alexandre >> >>> >> >>> >> >>>> On Dec 16, 2016, at 4:40 PM, Aliaksei Syrel <alex.sy...@gmail.com> >> wrote: >> >>>> >> >>>> According to crash.dmp TRMorph>drawOn: draws an image using >> FormCanvas>>#image:at:sourceRect:rule: at a coordinate represented by a >> Float point. >> >>>> Try to round it to integer point. >> >>>> >> >>>> Cheers, >> >>>> Alex >> >>>> >> >>>> On 16 December 2016 at 16:34, Alexandre Bergel < >> alexandre.ber...@me.com> wrote: >> >>>> Hi! >> >>>> >> >>>> Vincent and I are experiencing many crashes from GrafPort>copyBits. >> It crashes every couple of minutes. >> >>>> >> >>>> I know that not much can be done so far. Stability is my biggest >> concern with Pharo :-( >> >>>> I use the latest VM. >> >>>> >> >>>> Cheers, >> >>>> Alexandre >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> -- >> >>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >>>> Alexandre Bergel http://www.bergel.eu >> >>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >>>> >> >>>> >> >>>> >> >>>> >> >>>> _______________________________________________ >> >>>> Moose-dev mailing list >> >>>> moose-...@list.inf.unibe.ch >> >>>> https://www.list.inf.unibe.ch/listinfo/moose-dev >> >>>> >> >>>> >> >>> >> >>> -- >> >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >>> Alexandre Bergel http://www.bergel.eu >> >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >>> >> >>> >> >>> >> >>> >> >>> >> >> >> >> -- >> >> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> >> Alexandre Bergel http://www.bergel.eu >> >> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> >> >> >> >> >> >> >> >> >> >> > >> > -- >> > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: >> > Alexandre Bergel http://www.bergel.eu >> > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. >> > >> > >> > >> > >> >> >> >
