On 11 November 2013 21:47, kilon alios <kilon.alios@gmail.com> wrote:
Ignore my last messages. Apparently I had an error with my code I just did not understand the error report. Everything works fone now.
:)
���������� 11 ������ 2013 4:46 ��.��., �� �������������� "kilon alios" <kilon.alios@gmail.com> ������������:
sorry previous stack was for slightly diffirent code this is the correct oneUndefinedObject(Object)>>doesNotUnderstand: #drawDuring:Hyperion>>renderHyperion>>drawOn:FormCanvas(Canvas)>>draw:FormCanvas(Canvas)>>drawMorph:Hyperion(Morph)>>fullDrawOn: in Block: [ ...FormCanvas>>roundCornersOf:in:during:FormCanvas(Canvas)>>roundCornersOf:during:Hyperion(Morph)>>fullDrawOn: in Block: [ ...BlockClosure>>on:do:Hyperion(Morph)>>fullDrawOn:FormCanvas(Canvas)>>fullDraw:FormCanvas(Canvas)>>fullDrawMorph:SystemWindow(Morph)>>drawSubmorphsOn: in Block: [ :m | canvas fullDrawMorph: m ]Array(SequenceableCollection)>>reverseDo:SystemWindow(Morph)>>drawSubmorphsOn: in Block: [ :canvas | submorphs reverseDo: [ :m | canvas ful...etc...FormCanvas>>clipBy:during:SystemWindow(Morph)>>drawSubmorphsOn:SystemWindow(Morph)>>fullDrawOn: in Block: [ ...FormCanvas>>roundCornersOf:in:during:FormCanvas(Canvas)>>roundCornersOf:during:SystemWindow(Morph)>>fullDrawOn: in Block: [ ...BlockClosure>>on:do:SystemWindow(Morph)>>fullDrawOn:FormCanvas(Canvas)>>fullDraw:FormCanvas(Canvas)>>fullDrawMorph:WorldState>>drawWorld:submorphs:invalidAreasOn: in Block: drawWorld: aWorld submorphs: submorphs invalidArea...etc...Rectangle>>allAreasOutsideList:startingAt:do:Rectangle>>allAreasOutsideList:do:WorldState>>drawWorld:submorphs:invalidAreasOn: in Block: [ :dirtyRect | ...On Mon, Nov 11, 2013 at 4:43 PM, kilon alios <kilon.alios@gmail.com> wrote:Igor I am trying your session code but it does not work for me. I still get the red box of doom. This is the methodcheckSessionsession == Smalltalk session ifFalse: [��surface := surface := AthensCairoSurface extent: self extent. .session := Smalltalk session.]and This is my full stackNBFFICallout class>>signalError:NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode:NBFFICalloutAPI>>function:module:AthensCairoSurface class(Object)>>nbCall:AthensCairoSurface class>>primImage:width:height:NBFFICallout class(NBNativeCodeGen class)>>retrySend:AthensCairoSurface class>>extent:format:AthensCairoSurface class>>extent:Hyperion>>mouseDown:Hyperion(Morph)>>handleMouseDown:MouseButtonEvent>>sentTo:Hyperion(Morph)>>handleEvent:MorphicEventDispatcher>>dispatchMouseDown:with:MorphicEventDispatcher>>dispatchEvent:with:Hyperion(Morph)>>processEvent:using:MorphicEventDispatcher>>dispatchMouseDown:with:MorphicEventDispatcher>>dispatchEvent:with:SystemWindow(Morph)>>processEvent:using:SystemWindow(Morph)>>processEvent:SystemWindow>>mouseDown: in Block: [ ...BlockClosure>>ensure:SystemWindow>>mouseDown:SystemWindow(Morph)>>handleMouseDown:MouseButtonEvent>>sentTo:SystemWindow(Morph)>>handleEvent:MorphicEventDispatcher>>dispatchMouseDown:with:MorphicEventDispatcher>>dispatchEvent:with:SystemWindow(Morph)>>processEvent:using:MorphicEventDispatcher>>dispatchMouseDown:with:MorphicEventDispatcher>>dispatchEvent:with:
On Sat, Nov 2, 2013 at 12:01 PM, kilon alios <kilon.alios@gmail.com> wrote:
and here is the strange MNU that I was talking about earlierhere is the full stackHyperion(Object)>>doesNotUnderstand: #passengerPackageTreeModel>>acceptDroppingMorph:event:inMorph:MorphTreeMorph>>acceptDroppingMorph:event:MorphTreeMorph(Morph)>>handleDropMorph:DropEvent>>sentTo:MorphTreeMorph(Morph)>>handleEvent:MorphicEventDispatcher>>dispatchDropEvent:with:MorphicEventDispatcher>>dispatchEvent:with:MorphTreeMorph(Morph)>>processEvent:using:MorphicEventDispatcher>>dispatchDropEvent:with:MorphicEventDispatcher>>dispatchEvent:with:PanelMorph(Morph)>>processEvent:using:MorphicEventDispatcher>>dispatchDropEvent:with:MorphicEventDispatcher>>dispatchEvent:with:NautilusWindow(Morph)>>processEvent:using:MorphicEventDispatcher>>dispatchDropEvent:with:MorphicEventDispatcher>>dispatchEvent:with:WorldMorph(Morph)>>processEvent:using:WorldMorph(Morph)>>processEvent:HandMorph>>sendEvent:focus:clear:HandMorph>>sendEvent:focus:HandMorph>>dropMorph:event:HandMorph>>dropMorphs: in Block: [ :m | ...Array(SequenceableCollection)>>reverseDo:HandMorph(Morph)>>submorphsReverseDo:HandMorph>>dropMorphs:HandMorph>>handleEvent:HandMorph>>processEventsWorldState>>doOneCycleNowFor: in Block: [ :h | ...Array(SequenceableCollection)>>do:This one happens when I bring up the halos and try to move the morph around.Morphs gets deleted because of MNU. Note it does not happen with just my Class (Hyperion) it happens with any morph using Athens.��Hyperion in this case is a partial copy of the AthensDemoMorph. As always I am using Pharo 3 (Latest update: #30534) .On Fri, Nov 1, 2013 at 7:14 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 1 November 2013 14:32, St��phane Ducasse <stephane.ducasse@inria.fr> wrote:
Ok now the explanation :)Spec changed recently in 30.then i need help on that.. what is needs to be changed.btw, i noticed that monticello configuration browser also having problems with spec.��StefAgain I am following Igor instructions, loaded Athens-Tutorial from smalltalkhub , opened a new workspace, AthensTutorial open. I am using a pharo 3 that downloaded just yesterday. (Pharo3.0 Latest update: #30532)here is the full stackAthensViewMorph(Object)>>doesNotUnderstand: #layout:SpecInterpreter>>actionToPerformWithSelector:arguments:SpecInterpreter>>performNextSelectorAndIncrementIndexSpecInterpreter>>interpretASpec:selector:SpecInterpreter>>interpretASpec:model:selector:SpecInterpreter class>>private_interpretASpec:model:selector:SpecInterpreter>>performNextSelectorAndIncrementIndex in Block: [ :each | self class private_interpretASpec: each ...etc...Array(SequenceableCollection)>>collect:SpecInterpreter>>performNextSelectorAndIncrementIndexSpecInterpreter>>interpretASpec:selector:SpecInterpreter>>interpretASpec:model:selector:SpecInterpreter class>>private_interpretASpec:model:selector:SpecInterpreter class>>interpretASpec:model:selector: in Block: [ result := self private_interpretASpec: aPresente...etc...BlockClosure>>ensure:SpecInterpreter class>>interpretASpec:model:selector:SpecInterpreter class>>interpretASpec:model:AthensTutorial(ComposableModel)>>buildWithSpecLayout:MorphicWindowAdapter>>addModelIn:withSpecLayout:MorphicWindowAdapter(AbstractAdapter)>>update:with:WindowModel(Object)>>changed:with: in Block: [ :aDependent | aDependent update: anAspect with: ...etc...DependentsArray>>do:WindowModel(Object)>>changed:with:WindowModel>>addModelIn:withSpecLayout:WindowModel>>buildWithSpecLayout:WindowModel>>openWithSpecLayout:AthensTutorial(ComposableModel)>>openWithSpecLayout:AthensTutorial(ComposableModel)>>openWithSpec:AthensTutorial(ComposableModel)>>openWithSpecAthensTutorial class>>openUndefinedObject>>DoItIs that enough ?I am also getting another error from Athens from time to time, I will have to remember to capture it cause it appears randomly.��On Fri, Nov 1, 2013 at 1:42 PM, St��phane Ducasse <stephane.ducasse@inria.fr> wrote:
On Nov 1, 2013, at 10:02 AM, kilon alios <kilon.alios@gmail.com> wrote:Igor I got Athens-Tutorial but it gives me a MNU: AthensViewMorph>>layout:��strange tell us more.You know��which image���.StefOn Fri, Nov 1, 2013 at 10:23 AM, kilon alios <kilon.alios@gmail.com> wrote:
ShivaVG looks definitely as a way to ease the pain of porting to OpenGL.��Some notes on the matter. The Cairo backend for OpenGL is opengl but yet its not opengl. ��What it does is render cairo as a opengl texture. OpenGL true power is in the shaders so you dont get the kind of hardware acceleration you would expect.��Speewise as surprising this may sound ��opengl is not the ideal option, because opengl is mainly 3d orientated. The ideal solution from what I have seen would be something like CUDA or OpenCL, that give direct access to the GPU cores and allow you to do any kind of computation thus liberation from the restrictions of APIs. For example Blender takes advantage of both Opengl and CUDA , the CUDA renderer is phenomenal better because of its flexibility.��The problem however is that all that are very technical and it takes quite some dedication to implement.��A reason why I abandoned opengl as an idea is that I came to realise that Cairo was already fast enough for my needs. But I still keep that door open for the distant future, ShivaVG with OpenCL would be awesome for really intensive GUIs and complex Graphics and definitely would love to give it another try eventually. ����On Fri, Nov 1, 2013 at 2:19 AM, Igor Stasenko <siguctua@gmail.com> wrote:
On 1 November 2013 00:53, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Not sure to fully understand the problem. In what ShivaVG would solve a situation better than with Athens? If I understand well, a then working with Cairo uses the hardware acceleration right?
What is it not enough for you need?
First, OpenVG is more complete and i would say thoroughly designed API than Cairo.Second, i don't want to go�� Athens -> Cairo -> OpenGL
if i can do directly Athens->OpenGL.
Putting extra dependency out of the loop is advantageous, OpenGL is widely supported industry standard, which today you can find even on portable devices, while you cannot say same about Cairo.
��(not mentioning avoiding costs of having multiple layers to get to the hardware).
ShivaVG implements OpenVG API using OpenGL, since OpenVG is vector graphics frameworkit can serve as a good source to look how to implement OpenGL backend for Athens.��Alexandre
> Le 31-10-2013 �� 19:16, Igor Stasenko <siguctua@gmail.com> a ��crit :
>
> I cannot say, of course, how it would be for you, but there is ShivaVG[1] open-source
> opengl implementation of OpenVG, more or less feature-complete,
> so all what is needed is to port this code from C to smalltalk.
> Or if not for porting, but using as a source of insights how to implement it.
> I think it is fairly doable.
--
Best regards,
Igor Stasenko.
--
Best regards,
Igor Stasenko.
--
Best regards,
Igor Stasenko.