Questions about Athens
I created a new subject About the problem to recreate it all it takes is a demo := AthensDemoMorph new openInWorld . It opens the morph with the Athens grey box, I save the image , close pharo, open pharo which reloads the image automagically and BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph since I cant find documentation to do things differently. So lets get to the questions 1) You say you have morphs using Athens that don't have this problem, care to explain further ? 2) How do I recreate automatically those surfaces ? 3) Do I need to instruct the image on load to reinitialize those objects ? 4) If yes How I do that ? You say its a major problem but yet its not an Athens bug. I know this is has to do with how image saves live objects and that NB calls are not part of the image hence creating the problem. 5) Are there ways to avoid the problem ? 6) Also why there is a Red Box of Doom in the first place ? 7) Why the debugger is not triggered as it should be ? 8) Is that critical a failure of Morphic ? 9) Why Athens even though is based largely on Cairo , and taking into consideration the intention to extend to other graphical interfaces, not following the Cairo design more closely so we can use the Cairo tutorials ? 10) Is the Cairo design so prohibiting / limiting for Athens ? Does Cairo do things so differently than other vector based libraries ? 11) How important is Athens to Pharo community , meaning further bug fixes, improvements , tutorials etc ? I hear there is an intention to gradual move Morphic to it. Is this true ? I really like Athens, I am asking all these questions because I need to make a fast decision whether I will continue to use Pharo or not for my project. Learning OpenGL and using NBOpenGL produced zero results for me. I was not even able to create a single triangle. My gpu driver because of Macos gave me close to zero errors, and Red Box of Doom made it impossible to debug opengl problems. In short close to zero error reporting made it a no go for me. So I fall back at much simpler solutions because I want to create my own GUI API. I see several solutions for this 1) Pharo Athens 2) Amber SVG / WebGL based Vector libs like Pixi / Athens / HTML5 + CSS 3) Python + PyQT + QT I rather stay with Pharo. But I already wasted months of doing nothing and going nowhere with NBOpenGL , I am tried of moving in circles. I am not frustrated cause I knew when I tried that OpenGL was very hard ( I was warned by several opengl people ) so failure was always an option , but I can no longer justify wasting my time getting nowhere. I dont need much from a graphic lib all I need is a) Stability . If it crashes regularly its no good b) Speed, if moving graphic elements around slows down (anything above 20%) dual cores , its no good c) Basic Feature set like , lines, curves , circles and ellipses , display of raster graphics, simple animations , import export of graphic formats, png , jpg and svg is enough. Looks like Athens satisfies b and c , I am not so sure about a. I am trying to understand Athens code from reading it, once again I am a big failure at understanding code. So is there any hope for someone like me , that he is not a very good coder, he is new to Pharo and he has a simple mind to use Athens to make a basic GUI API ? On Thu, Oct 31, 2013 at 6:07 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 31 October 2013 16:40, kilon alios <kilon.alios@gmail.com> wrote:
save the image while the morph is displayed, reload the image and in its place there is the big red box with the yellow X , reporting an error with Athens. I have reproduced the error on Windows too with the Athens examples. I assumed my explanation was clear , I hope its clear now.
no. not clear. which morph? what class, how you using it etc. I have morphs which using Athens for drawing and i can save and load image back and i don't have red squares of death.
This means that its impossible to save an image with a morph using Athens displaying and have it reload back when the image is reloaded.
The athens-surface, especially cairo surface is valid only within a single session. if you boot new image, you must recreate (or stop using) surface you used in previous session. Otherwise you will have red box of doom.
And while i agree that this is pretty major problem (in terms of making your morph to be session-aware and in terms of managing external resources) i am far from calling it a bug of Athens of any kind per se.
On Thu, Oct 31, 2013 at 5:05 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On Oct 31, 2013, at 9:55 AM, kilon alios <kilon.alios@gmail.com> wrote:
yes I am aware of the examples already, I am learning from them. Please note I have found a bug with Athens, which looks to me pretty major. If I save a morph using Athens
what do you mean save a morph
and reload the image,
what do you mean?
I see the red box of doom. For example trying your example from stackoverflow. Are you aware of this bug ?
On Thu, Oct 31, 2013 at 2:43 AM, Igor Stasenko <siguctua@gmail.com>wrote:
ah, yes , there's also examples in Athens-Examples package.
On 31 October 2013 01:30, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 October 2013 23:02, kilon alios <kilon.alios@gmail.com> wrote:
well I just asked if there is any kind of Documentation about Athens . Or should I just read the code and ask questions ?
the main source of documentation right now is class comments and tutorial. I've spent quite of a time commenting the central classes of athens, hope that's helpful. Of course this does not replacement for a well written docu, and that needs to be done.
On Wed, Oct 30, 2013 at 11:51 PM, Igor Stasenko <siguctua@gmail.com>wrote:
i hope you satisfied with my answer. you welcome to ask more, if you not :)
On 30 October 2013 22:32, dimitris chloupis <thekilon@yahoo.co.uk>wrote:
http://stackoverflow.com/questions/19694197/how-to-create-lines-with-athens
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Hi Kilon, Roassal uses Athens (look for a dedicated package in the Roassal smalltalkhub repository). You may want to have a look at the implementation if you are looking for an application using Athens. Cheers, Alexandre On Oct 31, 2013, at 2:24 PM, kilon alios <kilon.alios@gmail.com> wrote:
I created a new subject
About the problem to recreate it all it takes is a demo := AthensDemoMorph new openInWorld . It opens the morph with the Athens grey box, I save the image , close pharo, open pharo which reloads the image automagically and BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph since I cant find documentation to do things differently.
So lets get to the questions
1) You say you have morphs using Athens that don't have this problem, care to explain further ?
2) How do I recreate automatically those surfaces ?
3) Do I need to instruct the image on load to reinitialize those objects ?
4) If yes How I do that ?
You say its a major problem but yet its not an Athens bug. I know this is has to do with how image saves live objects and that NB calls are not part of the image hence creating the problem.
5) Are there ways to avoid the problem ?
6) Also why there is a Red Box of Doom in the first place ?
7) Why the debugger is not triggered as it should be ?
8) Is that critical a failure of Morphic ?
9) Why Athens even though is based largely on Cairo , and taking into consideration the intention to extend to other graphical interfaces, not following the Cairo design more closely so we can use the Cairo tutorials ?
10) Is the Cairo design so prohibiting / limiting for Athens ? Does Cairo do things so differently than other vector based libraries ?
11) How important is Athens to Pharo community , meaning further bug fixes, improvements , tutorials etc ? I hear there is an intention to gradual move Morphic to it. Is this true ?
I really like Athens, I am asking all these questions because I need to make a fast decision whether I will continue to use Pharo or not for my project. Learning OpenGL and using NBOpenGL produced zero results for me. I was not even able to create a single triangle. My gpu driver because of Macos gave me close to zero errors, and Red Box of Doom made it impossible to debug opengl problems. In short close to zero error reporting made it a no go for me.
So I fall back at much simpler solutions because I want to create my own GUI API. I see several solutions for this
1) Pharo Athens 2) Amber SVG / WebGL based Vector libs like Pixi / Athens / HTML5 + CSS 3) Python + PyQT + QT
I rather stay with Pharo. But I already wasted months of doing nothing and going nowhere with NBOpenGL , I am tried of moving in circles. I am not frustrated cause I knew when I tried that OpenGL was very hard ( I was warned by several opengl people ) so failure was always an option , but I can no longer justify wasting my time getting nowhere.
I dont need much from a graphic lib all I need is
a) Stability . If it crashes regularly its no good
b) Speed, if moving graphic elements around slows down (anything above 20%) dual cores , its no good
c) Basic Feature set like , lines, curves , circles and ellipses , display of raster graphics, simple animations , import export of graphic formats, png , jpg and svg is enough.
Looks like Athens satisfies b and c , I am not so sure about a.
I am trying to understand Athens code from reading it, once again I am a big failure at understanding code.
So is there any hope for someone like me , that he is not a very good coder, he is new to Pharo and he has a simple mind to use Athens to make a basic GUI API ?
On Thu, Oct 31, 2013 at 6:07 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 31 October 2013 16:40, kilon alios <kilon.alios@gmail.com> wrote: save the image while the morph is displayed, reload the image and in its place there is the big red box with the yellow X , reporting an error with Athens. I have reproduced the error on Windows too with the Athens examples. I assumed my explanation was clear , I hope its clear now.
no. not clear. which morph? what class, how you using it etc. I have morphs which using Athens for drawing and i can save and load image back and i don't have red squares of death.
This means that its impossible to save an image with a morph using Athens displaying and have it reload back when the image is reloaded.
The athens-surface, especially cairo surface is valid only within a single session. if you boot new image, you must recreate (or stop using) surface you used in previous session. Otherwise you will have red box of doom.
And while i agree that this is pretty major problem (in terms of making your morph to be session-aware and in terms of managing external resources) i am far from calling it a bug of Athens of any kind per se.
On Thu, Oct 31, 2013 at 5:05 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 31, 2013, at 9:55 AM, kilon alios <kilon.alios@gmail.com> wrote:
yes I am aware of the examples already, I am learning from them. Please note I have found a bug with Athens, which looks to me pretty major. If I save a morph using Athens
what do you mean save a morph
and reload the image,
what do you mean?
I see the red box of doom. For example trying your example from stackoverflow. Are you aware of this bug ?
On Thu, Oct 31, 2013 at 2:43 AM, Igor Stasenko <siguctua@gmail.com> wrote: ah, yes , there's also examples in Athens-Examples package.
On 31 October 2013 01:30, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 October 2013 23:02, kilon alios <kilon.alios@gmail.com> wrote: well I just asked if there is any kind of Documentation about Athens . Or should I just read the code and ask questions ?
the main source of documentation right now is class comments and tutorial. I've spent quite of a time commenting the central classes of athens, hope that's helpful. Of course this does not replacement for a well written docu, and that needs to be done.
On Wed, Oct 30, 2013 at 11:51 PM, Igor Stasenko <siguctua@gmail.com> wrote: i hope you satisfied with my answer. you welcome to ask more, if you not :)
On 30 October 2013 22:32, dimitris chloupis <thekilon@yahoo.co.uk> wrote: http://stackoverflow.com/questions/19694197/how-to-create-lines-with-athens
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi
I created a new subject
About the problem to recreate it all it takes is a demo := AthensDemoMorph new openInWorld . It opens the morph with the Athens grey box, I save the image , close pharo, open pharo which reloads the image automagically and BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph since I cant find documentation to do things differently.
So lets get to the questions
1) You say you have morphs using Athens that don't have this problem, care to explain further ?
Did you see the tutorial?
2) How do I recreate automatically those surfaces ?
3) Do I need to instruct the image on load to reinitialize those objects ?
4) If yes How I do that ?
You say its a major problem but yet its not an Athens bug. I know this is has to do with how image saves live objects and that NB calls are not part of the image hence creating the problem.
5) Are there ways to avoid the problem ?
6) Also why there is a Red Box of Doom in the first place ?
7) Why the debugger is not triggered as it should be ?
It is now you should bring the halos and click on debug draw something error
8) Is that critical a failure of Morphic ?
9) Why Athens even though is based largely on Cairo , and taking into consideration the intention to extend to other graphical interfaces, not following the Cairo design more closely so we can use the Cairo tutorials ?
Because Athens is not Cairo. Athens is an API so that we can have multiple graphical back-ends in the future.
10) Is the Cairo design so prohibiting / limiting for Athens ? Does Cairo do things so differently than other vector based libraries ?
Cairo does not have an OO design from what I know.
11) How important is Athens to Pharo community , meaning further bug fixes, improvements , tutorials etc ? I hear there is an intention to gradual move Morphic to it. Is this true ?
Athens is the new canvas and we will rewrite everything to use it. Now Athens will have a default version that is just the default balloon. Now the guy that should have helped us (fernando) left in hurry and we lost the money 62 K Euros of his salary. Igor has been working more than a year in total on Athens, textEditor and others so we will not give up now.
I really like Athens, I am asking all these questions because I need to make a fast decision whether I will continue to use Pharo or not for my project. Learning OpenGL and using NBOpenGL produced zero results for me.
Did you check Roassal 3d because they forgot to publish the enhancements they did to NBOpenGL
I was not even able to create a single triangle.
You should look at Roassal 3d because this is working.
My gpu driver because of Macos gave me close to zero errors, and Red Box of Doom made it impossible to debug opengl problems. In short close to zero error reporting made it a no go for me.
So I fall back at much simpler solutions because I want to create my own GUI API. I see several solutions for this
1) Pharo Athens 2) Amber SVG / WebGL based Vector libs like Pixi / Athens / HTML5 + CSS 3) Python + PyQT + QT
I rather stay with Pharo. But I already wasted months of doing nothing and going nowhere with NBOpenGL , I am tried of moving in circles.
I'm sure you learned probably a lot. Now for a GUI API may be openGL is not the best to start. What I can tell you is that with Athens we will be able to have the first mix between 3D and 2D vector graphics.
I am not frustrated cause I knew when I tried that OpenGL was very hard ( I was warned by several opengl people ) so failure was always an option , but I can no longer justify wasting my time getting nowhere.
I dont need much from a graphic lib all I need is
a) Stability . If it crashes regularly its no good
b) Speed, if moving graphic elements around slows down (anything above 20%) dual cores , its no good
c) Basic Feature set like , lines, curves , circles and ellipses , display of raster graphics, simple animations , import export of graphic formats, png , jpg and svg is enough.
Looks like Athens satisfies b and c , I am not so sure about a.
It is stable.
I am trying to understand Athens code from reading it, once again I am a big failure at understanding code.
The tutorial is the way to go. Why this is not enough.
So is there any hope for someone like me , that he is not a very good coder, he is new to Pharo and he has a simple mind to use Athens to make a basic GUI API ?
Yes just focus on Athens. For example extend the
On Thu, Oct 31, 2013 at 6:07 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 31 October 2013 16:40, kilon alios <kilon.alios@gmail.com> wrote: save the image while the morph is displayed, reload the image and in its place there is the big red box with the yellow X , reporting an error with Athens. I have reproduced the error on Windows too with the Athens examples. I assumed my explanation was clear , I hope its clear now.
no. not clear. which morph? what class, how you using it etc. I have morphs which using Athens for drawing and i can save and load image back and i don't have red squares of death.
This means that its impossible to save an image with a morph using Athens displaying and have it reload back when the image is reloaded.
The athens-surface, especially cairo surface is valid only within a single session. if you boot new image, you must recreate (or stop using) surface you used in previous session. Otherwise you will have red box of doom.
And while i agree that this is pretty major problem (in terms of making your morph to be session-aware and in terms of managing external resources) i am far from calling it a bug of Athens of any kind per se.
On Thu, Oct 31, 2013 at 5:05 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 31, 2013, at 9:55 AM, kilon alios <kilon.alios@gmail.com> wrote:
yes I am aware of the examples already, I am learning from them. Please note I have found a bug with Athens, which looks to me pretty major. If I save a morph using Athens
what do you mean save a morph
and reload the image,
what do you mean?
I see the red box of doom. For example trying your example from stackoverflow. Are you aware of this bug ?
On Thu, Oct 31, 2013 at 2:43 AM, Igor Stasenko <siguctua@gmail.com> wrote: ah, yes , there's also examples in Athens-Examples package.
On 31 October 2013 01:30, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 October 2013 23:02, kilon alios <kilon.alios@gmail.com> wrote: well I just asked if there is any kind of Documentation about Athens . Or should I just read the code and ask questions ?
the main source of documentation right now is class comments and tutorial. I've spent quite of a time commenting the central classes of athens, hope that's helpful. Of course this does not replacement for a well written docu, and that needs to be done.
On Wed, Oct 30, 2013 at 11:51 PM, Igor Stasenko <siguctua@gmail.com> wrote: i hope you satisfied with my answer. you welcome to ask more, if you not :)
On 30 October 2013 22:32, dimitris chloupis <thekilon@yahoo.co.uk> wrote: http://stackoverflow.com/questions/19694197/how-to-create-lines-with-athens
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
Thank you Alexander and Stephane , I did not know that Roassal use Athens. This certainly will be helpful for me. Stephane, about NBOpenGL , my problem was opengl itself not NBOpenGL , I learned a lot of things true and yeah I did not know Roassal is using NBOpenGL but even if I did as you said opengl is not what I really needed. At the time I did not realize the effort to do vector graphics with opengl and the whole difficulty of learning the API, now I know I need something way more high level for my needs. About Athens tutorial, I dont know such thing, the only thing I know is AthensDemoMorph and the Athens-Examples Package and a video presentation that Igor posted way back in vimeo. So no I dont know of such tutorial. Wow the guy took 62 K euros and left ? Sorry to hear that :( cant believe how people do such things . On Thu, Oct 31, 2013 at 7:49 PM, Stéphane Ducasse <stephane.ducasse@inria.fr
wrote:
Hi
I created a new subject
About the problem to recreate it all it takes is a demo := AthensDemoMorph new openInWorld . It opens the morph with the Athens grey box, I save the image , close pharo, open pharo which reloads the image automagically and BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph since I cant find documentation to do things differently.
So lets get to the questions
1) You say you have morphs using Athens that don't have this problem, care to explain further ?
Did you see the tutorial?
2) How do I recreate automatically those surfaces ?
3) Do I need to instruct the image on load to reinitialize those objects ?
4) If yes How I do that ?
You say its a major problem but yet its not an Athens bug. I know this is has to do with how image saves live objects and that NB calls are not part of the image hence creating the problem.
5) Are there ways to avoid the problem ?
6) Also why there is a Red Box of Doom in the first place ?
7) Why the debugger is not triggered as it should be ?
It is now you should bring the halos and click on debug draw something error
8) Is that critical a failure of Morphic ?
9) Why Athens even though is based largely on Cairo , and taking into consideration the intention to extend to other graphical interfaces, not following the Cairo design more closely so we can use the Cairo tutorials ?
Because Athens is not Cairo. Athens is an API so that we can have multiple graphical back-ends in the future.
10) Is the Cairo design so prohibiting / limiting for Athens ? Does Cairo do things so differently than other vector based libraries ?
Cairo does not have an OO design from what I know.
11) How important is Athens to Pharo community , meaning further bug fixes, improvements , tutorials etc ? I hear there is an intention to gradual move Morphic to it. Is this true ?
Athens is the new canvas and we will rewrite everything to use it. Now Athens will have a default version that is just the default balloon. Now the guy that should have helped us (fernando) left in hurry and we lost the money 62 K Euros of his salary. Igor has been working more than a year in total on Athens, textEditor and others so we will not give up now.
I really like Athens, I am asking all these questions because I need to make a fast decision whether I will continue to use Pharo or not for my project. Learning OpenGL and using NBOpenGL produced zero results for me.
Did you check Roassal 3d because they forgot to publish the enhancements they did to NBOpenGL
I was not even able to create a single triangle.
You should look at Roassal 3d because this is working.
My gpu driver because of Macos gave me close to zero errors, and Red Box of Doom made it impossible to debug opengl problems. In short close to zero error reporting made it a no go for me.
So I fall back at much simpler solutions because I want to create my own GUI API. I see several solutions for this
1) Pharo Athens 2) Amber SVG / WebGL based Vector libs like Pixi / Athens / HTML5 + CSS 3) Python + PyQT + QT
I rather stay with Pharo. But I already wasted months of doing nothing and going nowhere with NBOpenGL , I am tried of moving in circles.
I'm sure you learned probably a lot. Now for a GUI API may be openGL is not the best to start. What I can tell you is that with Athens we will be able to have the first mix between 3D and 2D vector graphics.
I am not frustrated cause I knew when I tried that OpenGL was very hard ( I was warned by several opengl people ) so failure was always an option , but I can no longer justify wasting my time getting nowhere.
I dont need much from a graphic lib all I need is
a) Stability . If it crashes regularly its no good
b) Speed, if moving graphic elements around slows down (anything above 20%) dual cores , its no good
c) Basic Feature set like , lines, curves , circles and ellipses , display of raster graphics, simple animations , import export of graphic formats, png , jpg and svg is enough.
Looks like Athens satisfies b and c , I am not so sure about a.
It is stable.
I am trying to understand Athens code from reading it, once again I am a big failure at understanding code.
The tutorial is the way to go. Why this is not enough.
So is there any hope for someone like me , that he is not a very good coder, he is new to Pharo and he has a simple mind to use Athens to make a basic GUI API ?
Yes just focus on Athens. For example extend the
On Thu, Oct 31, 2013 at 6:07 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 31 October 2013 16:40, kilon alios <kilon.alios@gmail.com> wrote:
save the image while the morph is displayed, reload the image and in its place there is the big red box with the yellow X , reporting an error with Athens. I have reproduced the error on Windows too with the Athens examples. I assumed my explanation was clear , I hope its clear now.
no. not clear. which morph? what class, how you using it etc. I have morphs which using Athens for drawing and i can save and load image back and i don't have red squares of death.
This means that its impossible to save an image with a morph using Athens displaying and have it reload back when the image is reloaded.
The athens-surface, especially cairo surface is valid only within a single session. if you boot new image, you must recreate (or stop using) surface you used in previous session. Otherwise you will have red box of doom.
And while i agree that this is pretty major problem (in terms of making your morph to be session-aware and in terms of managing external resources) i am far from calling it a bug of Athens of any kind per se.
On Thu, Oct 31, 2013 at 5:05 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On Oct 31, 2013, at 9:55 AM, kilon alios <kilon.alios@gmail.com> wrote:
yes I am aware of the examples already, I am learning from them. Please note I have found a bug with Athens, which looks to me pretty major. If I save a morph using Athens
what do you mean save a morph
and reload the image,
what do you mean?
I see the red box of doom. For example trying your example from stackoverflow. Are you aware of this bug ?
On Thu, Oct 31, 2013 at 2:43 AM, Igor Stasenko <siguctua@gmail.com>wrote:
ah, yes , there's also examples in Athens-Examples package.
On 31 October 2013 01:30, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 October 2013 23:02, kilon alios <kilon.alios@gmail.com> wrote:
well I just asked if there is any kind of Documentation about Athens . Or should I just read the code and ask questions ?
the main source of documentation right now is class comments and tutorial. I've spent quite of a time commenting the central classes of athens, hope that's helpful. Of course this does not replacement for a well written docu, and that needs to be done.
On Wed, Oct 30, 2013 at 11:51 PM, Igor Stasenko <siguctua@gmail.com>wrote:
i hope you satisfied with my answer. you welcome to ask more, if you not :)
On 30 October 2013 22:32, dimitris chloupis <thekilon@yahoo.co.uk>wrote:
http://stackoverflow.com/questions/19694197/how-to-create-lines-with-athens
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 31 October 2013 20:01, kilon alios <kilon.alios@gmail.com> wrote:
Thank you Alexander and Stephane , I did not know that Roassal use Athens. This certainly will be helpful for me.
Stephane, about NBOpenGL , my problem was opengl itself not NBOpenGL , I learned a lot of things true and yeah I did not know Roassal is using NBOpenGL but even if I did as you said opengl is not what I really needed. At the time I did not realize the effort to do vector graphics with opengl and the whole difficulty of learning the API, now I know I need something way more high level for my needs.
About Athens tutorial, I dont know such thing, the only thing I know is AthensDemoMorph and the Athens-Examples Package and a video presentation that Igor posted way back in vimeo. So no I dont know of such tutorial.
MCSmalltalkhubRepository owner: 'Pharo' project: 'Athens' user: '' password: '' Load Athens-Tutorial package Run: AthensTutorial open Wow the guy took 62 K euros and left ? Sorry to hear that :( cant believe
how people do such things .
no, he didn't. It was a budget allocated for him if he would stay and work with us.
On Thu, Oct 31, 2013 at 7:49 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Hi
I created a new subject
About the problem to recreate it all it takes is a demo := AthensDemoMorph new openInWorld . It opens the morph with the Athens grey box, I save the image , close pharo, open pharo which reloads the image automagically and BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph since I cant find documentation to do things differently.
So lets get to the questions
1) You say you have morphs using Athens that don't have this problem, care to explain further ?
Did you see the tutorial?
2) How do I recreate automatically those surfaces ?
3) Do I need to instruct the image on load to reinitialize those objects ?
4) If yes How I do that ?
You say its a major problem but yet its not an Athens bug. I know this is has to do with how image saves live objects and that NB calls are not part of the image hence creating the problem.
5) Are there ways to avoid the problem ?
6) Also why there is a Red Box of Doom in the first place ?
7) Why the debugger is not triggered as it should be ?
It is now you should bring the halos and click on debug draw something error
8) Is that critical a failure of Morphic ?
9) Why Athens even though is based largely on Cairo , and taking into consideration the intention to extend to other graphical interfaces, not following the Cairo design more closely so we can use the Cairo tutorials ?
Because Athens is not Cairo. Athens is an API so that we can have multiple graphical back-ends in the future.
10) Is the Cairo design so prohibiting / limiting for Athens ? Does Cairo do things so differently than other vector based libraries ?
Cairo does not have an OO design from what I know.
11) How important is Athens to Pharo community , meaning further bug fixes, improvements , tutorials etc ? I hear there is an intention to gradual move Morphic to it. Is this true ?
Athens is the new canvas and we will rewrite everything to use it. Now Athens will have a default version that is just the default balloon. Now the guy that should have helped us (fernando) left in hurry and we lost the money 62 K Euros of his salary. Igor has been working more than a year in total on Athens, textEditor and others so we will not give up now.
I really like Athens, I am asking all these questions because I need to make a fast decision whether I will continue to use Pharo or not for my project. Learning OpenGL and using NBOpenGL produced zero results for me.
Did you check Roassal 3d because they forgot to publish the enhancements they did to NBOpenGL
I was not even able to create a single triangle.
You should look at Roassal 3d because this is working.
My gpu driver because of Macos gave me close to zero errors, and Red Box of Doom made it impossible to debug opengl problems. In short close to zero error reporting made it a no go for me.
So I fall back at much simpler solutions because I want to create my own GUI API. I see several solutions for this
1) Pharo Athens 2) Amber SVG / WebGL based Vector libs like Pixi / Athens / HTML5 + CSS 3) Python + PyQT + QT
I rather stay with Pharo. But I already wasted months of doing nothing and going nowhere with NBOpenGL , I am tried of moving in circles.
I'm sure you learned probably a lot. Now for a GUI API may be openGL is not the best to start. What I can tell you is that with Athens we will be able to have the first mix between 3D and 2D vector graphics.
I am not frustrated cause I knew when I tried that OpenGL was very hard ( I was warned by several opengl people ) so failure was always an option , but I can no longer justify wasting my time getting nowhere.
I dont need much from a graphic lib all I need is
a) Stability . If it crashes regularly its no good
b) Speed, if moving graphic elements around slows down (anything above 20%) dual cores , its no good
c) Basic Feature set like , lines, curves , circles and ellipses , display of raster graphics, simple animations , import export of graphic formats, png , jpg and svg is enough.
Looks like Athens satisfies b and c , I am not so sure about a.
It is stable.
I am trying to understand Athens code from reading it, once again I am a big failure at understanding code.
The tutorial is the way to go. Why this is not enough.
So is there any hope for someone like me , that he is not a very good coder, he is new to Pharo and he has a simple mind to use Athens to make a basic GUI API ?
Yes just focus on Athens. For example extend the
On Thu, Oct 31, 2013 at 6:07 PM, Igor Stasenko <siguctua@gmail.com>wrote:
On 31 October 2013 16:40, kilon alios <kilon.alios@gmail.com> wrote:
save the image while the morph is displayed, reload the image and in its place there is the big red box with the yellow X , reporting an error with Athens. I have reproduced the error on Windows too with the Athens examples. I assumed my explanation was clear , I hope its clear now.
no. not clear. which morph? what class, how you using it etc. I have morphs which using Athens for drawing and i can save and load image back and i don't have red squares of death.
This means that its impossible to save an image with a morph using Athens displaying and have it reload back when the image is reloaded.
The athens-surface, especially cairo surface is valid only within a single session. if you boot new image, you must recreate (or stop using) surface you used in previous session. Otherwise you will have red box of doom.
And while i agree that this is pretty major problem (in terms of making your morph to be session-aware and in terms of managing external resources) i am far from calling it a bug of Athens of any kind per se.
On Thu, Oct 31, 2013 at 5:05 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On Oct 31, 2013, at 9:55 AM, kilon alios <kilon.alios@gmail.com> wrote:
yes I am aware of the examples already, I am learning from them. Please note I have found a bug with Athens, which looks to me pretty major. If I save a morph using Athens
what do you mean save a morph
and reload the image,
what do you mean?
I see the red box of doom. For example trying your example from stackoverflow. Are you aware of this bug ?
On Thu, Oct 31, 2013 at 2:43 AM, Igor Stasenko <siguctua@gmail.com>wrote:
ah, yes , there's also examples in Athens-Examples package.
On 31 October 2013 01:30, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 October 2013 23:02, kilon alios <kilon.alios@gmail.com> wrote:
well I just asked if there is any kind of Documentation about Athens . Or should I just read the code and ask questions ?
the main source of documentation right now is class comments and tutorial. I've spent quite of a time commenting the central classes of athens, hope that's helpful. Of course this does not replacement for a well written docu, and that needs to be done.
On Wed, Oct 30, 2013 at 11:51 PM, Igor Stasenko <siguctua@gmail.com
wrote:
i hope you satisfied with my answer. you welcome to ask more, if you not :)
On 30 October 2013 22:32, dimitris chloupis <thekilon@yahoo.co.uk>wrote:
http://stackoverflow.com/questions/19694197/how-to-create-lines-with-athens
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
thanks Igor for the very thorough answer. I took a look at AthensViewScene , I see initializeForNewSession , Smalltalk session and the other state methods, it starts to make sense now. I will get the tutorial and together with Roassal I should be able to make a lot more progress. About OpenGL , no I did not give up too easily. I have been told that OpenGL is complex for a good reason but now I know more about it I just know its the typical C/C++ library, badly designed to the bone. Its a huge pile of mess and the very fact that my macos drivers of my gpu does ( a typical behavior for macos gpu drivers) not report detailed errors it makes it a No Go area for me. Documentation is also a in a very bad state , definitely does not make life easier. My idea was to follow your advise implement OpenVg and then use that as a backend for Athens. But alas at this point I hear OpenGL and just run :D The main problem however was that even if I could use OpenGL I would have to learn also a lot of math to do the OpenVG implementation, So yeah not my cup of tea. I did not expect it to work, I just wanted to learn Nativeboost and NBOpenGL was a good chance to do that. So I realize that the whole deal just was way over my level of skill as a coder. I wanted something a lot simpler. I cant justify wasting months to draw a single curve in the shake of GPU acceleration. Fortunately with Athens I am already able to draw curves, lines, boxes and circles, For me thats a very good start. I dont need 3d graphics at this point, but I may at the distant future. When that time comes then I will consider moving back to NBOpenGL, but not before that. Again thank you all for your help I will keep you posted on my progress. On Thu, Oct 31, 2013 at 9:53 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 31 October 2013 20:01, kilon alios <kilon.alios@gmail.com> wrote:
Thank you Alexander and Stephane , I did not know that Roassal use Athens. This certainly will be helpful for me.
Stephane, about NBOpenGL , my problem was opengl itself not NBOpenGL , I learned a lot of things true and yeah I did not know Roassal is using NBOpenGL but even if I did as you said opengl is not what I really needed. At the time I did not realize the effort to do vector graphics with opengl and the whole difficulty of learning the API, now I know I need something way more high level for my needs.
About Athens tutorial, I dont know such thing, the only thing I know is AthensDemoMorph and the Athens-Examples Package and a video presentation that Igor posted way back in vimeo. So no I dont know of such tutorial.
MCSmalltalkhubRepository owner: 'Pharo' project: 'Athens' user: '' password: ''
Load Athens-Tutorial package Run: AthensTutorial open
Wow the guy took 62 K euros and left ? Sorry to hear that :( cant believe
how people do such things .
no, he didn't. It was a budget allocated for him if he would stay and work with us.
On Thu, Oct 31, 2013 at 7:49 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Hi
I created a new subject
About the problem to recreate it all it takes is a demo := AthensDemoMorph new openInWorld . It opens the morph with the Athens grey box, I save the image , close pharo, open pharo which reloads the image automagically and BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph since I cant find documentation to do things differently.
So lets get to the questions
1) You say you have morphs using Athens that don't have this problem, care to explain further ?
Did you see the tutorial?
2) How do I recreate automatically those surfaces ?
3) Do I need to instruct the image on load to reinitialize those objects ?
4) If yes How I do that ?
You say its a major problem but yet its not an Athens bug. I know this is has to do with how image saves live objects and that NB calls are not part of the image hence creating the problem.
5) Are there ways to avoid the problem ?
6) Also why there is a Red Box of Doom in the first place ?
7) Why the debugger is not triggered as it should be ?
It is now you should bring the halos and click on debug draw something error
8) Is that critical a failure of Morphic ?
9) Why Athens even though is based largely on Cairo , and taking into consideration the intention to extend to other graphical interfaces, not following the Cairo design more closely so we can use the Cairo tutorials ?
Because Athens is not Cairo. Athens is an API so that we can have multiple graphical back-ends in the future.
10) Is the Cairo design so prohibiting / limiting for Athens ? Does Cairo do things so differently than other vector based libraries ?
Cairo does not have an OO design from what I know.
11) How important is Athens to Pharo community , meaning further bug fixes, improvements , tutorials etc ? I hear there is an intention to gradual move Morphic to it. Is this true ?
Athens is the new canvas and we will rewrite everything to use it. Now Athens will have a default version that is just the default balloon. Now the guy that should have helped us (fernando) left in hurry and we lost the money 62 K Euros of his salary. Igor has been working more than a year in total on Athens, textEditor and others so we will not give up now.
I really like Athens, I am asking all these questions because I need to make a fast decision whether I will continue to use Pharo or not for my project. Learning OpenGL and using NBOpenGL produced zero results for me.
Did you check Roassal 3d because they forgot to publish the enhancements they did to NBOpenGL
I was not even able to create a single triangle.
You should look at Roassal 3d because this is working.
My gpu driver because of Macos gave me close to zero errors, and Red Box of Doom made it impossible to debug opengl problems. In short close to zero error reporting made it a no go for me.
So I fall back at much simpler solutions because I want to create my own GUI API. I see several solutions for this
1) Pharo Athens 2) Amber SVG / WebGL based Vector libs like Pixi / Athens / HTML5 + CSS 3) Python + PyQT + QT
I rather stay with Pharo. But I already wasted months of doing nothing and going nowhere with NBOpenGL , I am tried of moving in circles.
I'm sure you learned probably a lot. Now for a GUI API may be openGL is not the best to start. What I can tell you is that with Athens we will be able to have the first mix between 3D and 2D vector graphics.
I am not frustrated cause I knew when I tried that OpenGL was very hard ( I was warned by several opengl people ) so failure was always an option , but I can no longer justify wasting my time getting nowhere.
I dont need much from a graphic lib all I need is
a) Stability . If it crashes regularly its no good
b) Speed, if moving graphic elements around slows down (anything above 20%) dual cores , its no good
c) Basic Feature set like , lines, curves , circles and ellipses , display of raster graphics, simple animations , import export of graphic formats, png , jpg and svg is enough.
Looks like Athens satisfies b and c , I am not so sure about a.
It is stable.
I am trying to understand Athens code from reading it, once again I am a big failure at understanding code.
The tutorial is the way to go. Why this is not enough.
So is there any hope for someone like me , that he is not a very good coder, he is new to Pharo and he has a simple mind to use Athens to make a basic GUI API ?
Yes just focus on Athens. For example extend the
On Thu, Oct 31, 2013 at 6:07 PM, Igor Stasenko <siguctua@gmail.com>wrote:
On 31 October 2013 16:40, kilon alios <kilon.alios@gmail.com> wrote:
save the image while the morph is displayed, reload the image and in its place there is the big red box with the yellow X , reporting an error with Athens. I have reproduced the error on Windows too with the Athens examples. I assumed my explanation was clear , I hope its clear now.
no. not clear. which morph? what class, how you using it etc. I have morphs which using Athens for drawing and i can save and load image back and i don't have red squares of death.
This means that its impossible to save an image with a morph using Athens displaying and have it reload back when the image is reloaded.
The athens-surface, especially cairo surface is valid only within a single session. if you boot new image, you must recreate (or stop using) surface you used in previous session. Otherwise you will have red box of doom.
And while i agree that this is pretty major problem (in terms of making your morph to be session-aware and in terms of managing external resources) i am far from calling it a bug of Athens of any kind per se.
On Thu, Oct 31, 2013 at 5:05 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On Oct 31, 2013, at 9:55 AM, kilon alios <kilon.alios@gmail.com> wrote:
yes I am aware of the examples already, I am learning from them. Please note I have found a bug with Athens, which looks to me pretty major. If I save a morph using Athens
what do you mean save a morph
and reload the image,
what do you mean?
I see the red box of doom. For example trying your example from stackoverflow. Are you aware of this bug ?
On Thu, Oct 31, 2013 at 2:43 AM, Igor Stasenko <siguctua@gmail.com>wrote:
ah, yes , there's also examples in Athens-Examples package.
On 31 October 2013 01:30, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 October 2013 23:02, kilon alios <kilon.alios@gmail.com>wrote:
well I just asked if there is any kind of Documentation about Athens . Or should I just read the code and ask questions ?
the main source of documentation right now is class comments and tutorial. I've spent quite of a time commenting the central classes of athens, hope that's helpful. Of course this does not replacement for a well written docu, and that needs to be done.
On Wed, Oct 30, 2013 at 11:51 PM, Igor Stasenko < siguctua@gmail.com> wrote:
i hope you satisfied with my answer. you welcome to ask more, if you not :)
On 30 October 2013 22:32, dimitris chloupis <thekilon@yahoo.co.uk
wrote:
http://stackoverflow.com/questions/19694197/how-to-create-lines-with-athens
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 31 October 2013 22:39, kilon alios <kilon.alios@gmail.com> wrote:
thanks Igor for the very thorough answer. I took a look at AthensViewScene , I see initializeForNewSession , Smalltalk session and the other state methods, it starts to make sense now.
I will get the tutorial and together with Roassal I should be able to make a lot more progress.
Feel free to ask any question you need to be answered.
About OpenGL , no I did not give up too easily. I have been told that OpenGL is complex for a good reason but now I know more about it I just know its the typical C/C++ library, badly designed to the bone. Its a huge pile of mess and the very fact that my macos drivers of my gpu does ( a typical behavior for macos gpu drivers) not report detailed errors it makes it a No Go area for me. Documentation is also a in a very bad state , definitely does not make life easier. My idea was to follow your advise implement OpenVg and then use that as a backend for Athens. But alas at this point I hear OpenGL and just run :D
The main problem however was that even if I could use OpenGL I would have to learn also a lot of math to do the OpenVG implementation, So yeah not my cup of tea. I did not expect it to work, I just wanted to learn Nativeboost and NBOpenGL was a good chance to do that. So I realize that the whole deal just was way over my level of skill as a coder. I wanted something a lot simpler.
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. [1] https://github.com/ileben/ShivaVG I cant justify wasting months to draw a single curve in the shake of GPU
acceleration.
Fortunately with Athens I am already able to draw curves, lines, boxes and circles, For me thats a very good start. I dont need 3d graphics at this point, but I may at the distant future. When that time comes then I will consider moving back to NBOpenGL, but not before that. Again thank you all for your help I will keep you posted on my progress.
I want to have Athens at one day harnessing GPU power. I want such things for myself. :) But right now i have other things to do.. (and i want many other things aside of this ;)
On Thu, Oct 31, 2013 at 9:53 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 31 October 2013 20:01, kilon alios <kilon.alios@gmail.com> wrote:
Thank you Alexander and Stephane , I did not know that Roassal use Athens. This certainly will be helpful for me.
Stephane, about NBOpenGL , my problem was opengl itself not NBOpenGL , I learned a lot of things true and yeah I did not know Roassal is using NBOpenGL but even if I did as you said opengl is not what I really needed. At the time I did not realize the effort to do vector graphics with opengl and the whole difficulty of learning the API, now I know I need something way more high level for my needs.
About Athens tutorial, I dont know such thing, the only thing I know is AthensDemoMorph and the Athens-Examples Package and a video presentation that Igor posted way back in vimeo. So no I dont know of such tutorial.
MCSmalltalkhubRepository owner: 'Pharo' project: 'Athens' user: '' password: ''
Load Athens-Tutorial package Run: AthensTutorial open
Wow the guy took 62 K euros and left ? Sorry to hear that :( cant
believe how people do such things .
no, he didn't. It was a budget allocated for him if he would stay and work with us.
On Thu, Oct 31, 2013 at 7:49 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
Hi
I created a new subject
About the problem to recreate it all it takes is a demo := AthensDemoMorph new openInWorld . It opens the morph with the Athens grey box, I save the image , close pharo, open pharo which reloads the image automagically and BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph since I cant find documentation to do things differently.
So lets get to the questions
1) You say you have morphs using Athens that don't have this problem, care to explain further ?
Did you see the tutorial?
2) How do I recreate automatically those surfaces ?
3) Do I need to instruct the image on load to reinitialize those objects ?
4) If yes How I do that ?
You say its a major problem but yet its not an Athens bug. I know this is has to do with how image saves live objects and that NB calls are not part of the image hence creating the problem.
5) Are there ways to avoid the problem ?
6) Also why there is a Red Box of Doom in the first place ?
7) Why the debugger is not triggered as it should be ?
It is now you should bring the halos and click on debug draw something error
8) Is that critical a failure of Morphic ?
9) Why Athens even though is based largely on Cairo , and taking into consideration the intention to extend to other graphical interfaces, not following the Cairo design more closely so we can use the Cairo tutorials ?
Because Athens is not Cairo. Athens is an API so that we can have multiple graphical back-ends in the future.
10) Is the Cairo design so prohibiting / limiting for Athens ? Does Cairo do things so differently than other vector based libraries ?
Cairo does not have an OO design from what I know.
11) How important is Athens to Pharo community , meaning further bug fixes, improvements , tutorials etc ? I hear there is an intention to gradual move Morphic to it. Is this true ?
Athens is the new canvas and we will rewrite everything to use it. Now Athens will have a default version that is just the default balloon. Now the guy that should have helped us (fernando) left in hurry and we lost the money 62 K Euros of his salary. Igor has been working more than a year in total on Athens, textEditor and others so we will not give up now.
I really like Athens, I am asking all these questions because I need to make a fast decision whether I will continue to use Pharo or not for my project. Learning OpenGL and using NBOpenGL produced zero results for me.
Did you check Roassal 3d because they forgot to publish the enhancements they did to NBOpenGL
I was not even able to create a single triangle.
You should look at Roassal 3d because this is working.
My gpu driver because of Macos gave me close to zero errors, and Red Box of Doom made it impossible to debug opengl problems. In short close to zero error reporting made it a no go for me.
So I fall back at much simpler solutions because I want to create my own GUI API. I see several solutions for this
1) Pharo Athens 2) Amber SVG / WebGL based Vector libs like Pixi / Athens / HTML5 + CSS 3) Python + PyQT + QT
I rather stay with Pharo. But I already wasted months of doing nothing and going nowhere with NBOpenGL , I am tried of moving in circles.
I'm sure you learned probably a lot. Now for a GUI API may be openGL is not the best to start. What I can tell you is that with Athens we will be able to have the first mix between 3D and 2D vector graphics.
I am not frustrated cause I knew when I tried that OpenGL was very hard ( I was warned by several opengl people ) so failure was always an option , but I can no longer justify wasting my time getting nowhere.
I dont need much from a graphic lib all I need is
a) Stability . If it crashes regularly its no good
b) Speed, if moving graphic elements around slows down (anything above 20%) dual cores , its no good
c) Basic Feature set like , lines, curves , circles and ellipses , display of raster graphics, simple animations , import export of graphic formats, png , jpg and svg is enough.
Looks like Athens satisfies b and c , I am not so sure about a.
It is stable.
I am trying to understand Athens code from reading it, once again I am a big failure at understanding code.
The tutorial is the way to go. Why this is not enough.
So is there any hope for someone like me , that he is not a very good coder, he is new to Pharo and he has a simple mind to use Athens to make a basic GUI API ?
Yes just focus on Athens. For example extend the
On Thu, Oct 31, 2013 at 6:07 PM, Igor Stasenko <siguctua@gmail.com>wrote:
On 31 October 2013 16:40, kilon alios <kilon.alios@gmail.com> wrote:
save the image while the morph is displayed, reload the image and in its place there is the big red box with the yellow X , reporting an error with Athens. I have reproduced the error on Windows too with the Athens examples. I assumed my explanation was clear , I hope its clear now.
no. not clear. which morph? what class, how you using it etc. I have morphs which using Athens for drawing and i can save and load image back and i don't have red squares of death.
This means that its impossible to save an image with a morph using Athens displaying and have it reload back when the image is reloaded.
The athens-surface, especially cairo surface is valid only within a single session. if you boot new image, you must recreate (or stop using) surface you used in previous session. Otherwise you will have red box of doom.
And while i agree that this is pretty major problem (in terms of making your morph to be session-aware and in terms of managing external resources) i am far from calling it a bug of Athens of any kind per se.
On Thu, Oct 31, 2013 at 5:05 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On Oct 31, 2013, at 9:55 AM, kilon alios <kilon.alios@gmail.com> wrote:
yes I am aware of the examples already, I am learning from them. Please note I have found a bug with Athens, which looks to me pretty major. If I save a morph using Athens
what do you mean save a morph
and reload the image,
what do you mean?
I see the red box of doom. For example trying your example from stackoverflow. Are you aware of this bug ?
On Thu, Oct 31, 2013 at 2:43 AM, Igor Stasenko <siguctua@gmail.com>wrote:
ah, yes , there's also examples in Athens-Examples package.
On 31 October 2013 01:30, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 October 2013 23:02, kilon alios <kilon.alios@gmail.com>wrote:
well I just asked if there is any kind of Documentation about Athens . Or should I just read the code and ask questions ?
the main source of documentation right now is class comments and tutorial. I've spent quite of a time commenting the central classes of athens, hope that's helpful. Of course this does not replacement for a well written docu, and that needs to be done.
On Wed, Oct 30, 2013 at 11:51 PM, Igor Stasenko < siguctua@gmail.com> wrote:
i hope you satisfied with my answer. you welcome to ask more, if you not :)
On 30 October 2013 22:32, dimitris chloupis < thekilon@yahoo.co.uk> wrote:
http://stackoverflow.com/questions/19694197/how-to-create-lines-with-athens
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
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? 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.
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 framework it 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.
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 framework it 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.
Igor I got Athens-Tutorial but it gives me a MNU: AthensViewMorph>>layout: On 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 framework it 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.
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 â¦. Stef
On 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 framework it 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.
Again 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 stack AthensViewMorph(Object)>>doesNotUnderstand: #layout: SpecInterpreter>>actionToPerformWithSelector:arguments: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>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>>performNextSelectorAndIncrementIndex SpecInterpreter>>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)>>openWithSpec AthensTutorial class>>open UndefinedObject>>DoIt Is 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 â¦.
Stef
On 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 framework it 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.
Ok now the explanation :) Spec changed recently in 30. Stef
Again 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 stack
AthensViewMorph(Object)>>doesNotUnderstand: #layout: SpecInterpreter>>actionToPerformWithSelector:arguments: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>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>>performNextSelectorAndIncrementIndex SpecInterpreter>>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)>>openWithSpec AthensTutorial class>>open UndefinedObject>>DoIt
Is 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 â¦.
Stef
On 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 framework it 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.
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.
Stef
Again 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 stack
AthensViewMorph(Object)>>doesNotUnderstand: #layout: SpecInterpreter>>actionToPerformWithSelector:arguments: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>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>>performNextSelectorAndIncrementIndex SpecInterpreter>>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)>>openWithSpec AthensTutorial class>>open UndefinedObject>>DoIt
Is 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 â¦.
Stef
On 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 framework it 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.
and here is the strange MNU that I was talking about earlier here is the full stack Hyperion(Object)>>doesNotUnderstand: #passenger PackageTreeModel>>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>>processEvents WorldState>>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.
Stef
Again 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 stack
AthensViewMorph(Object)>>doesNotUnderstand: #layout: SpecInterpreter>>actionToPerformWithSelector:arguments: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>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>>performNextSelectorAndIncrementIndex SpecInterpreter>>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)>>openWithSpec AthensTutorial class>>open UndefinedObject>>DoIt
Is 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 â¦.
Stef
On 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 framework it 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.
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 method checkSession session == Smalltalk session ifFalse: [ surface := surface := AthensCairoSurface extent: self extent. . session := Smalltalk session. ] and This is my full stack NBFFICallout 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 earlier
here is the full stack
Hyperion(Object)>>doesNotUnderstand: #passenger PackageTreeModel>>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>>processEvents WorldState>>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.
Stef
Again 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 stack
AthensViewMorph(Object)>>doesNotUnderstand: #layout: SpecInterpreter>>actionToPerformWithSelector:arguments: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>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>>performNextSelectorAndIncrementIndex SpecInterpreter>>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)>>openWithSpec AthensTutorial class>>open UndefinedObject>>DoIt
Is 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 â¦.
Stef
On 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 framework it 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.
sorry previous stack was for slightly diffirent code this is the correct one UndefinedObject(Object)>>doesNotUnderstand: #drawDuring: Hyperion>>render Hyperion>>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 method
checkSession
session == Smalltalk session ifFalse: [ surface := surface := AthensCairoSurface extent: self extent. . session := Smalltalk session. ]
and This is my full stack
NBFFICallout 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 earlier
here is the full stack
Hyperion(Object)>>doesNotUnderstand: #passenger PackageTreeModel>>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>>processEvents WorldState>>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.
Stef
Again 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 stack
AthensViewMorph(Object)>>doesNotUnderstand: #layout: SpecInterpreter>>actionToPerformWithSelector:arguments: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>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>>performNextSelectorAndIncrementIndex SpecInterpreter>>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)>>openWithSpec AthensTutorial class>>open UndefinedObject>>DoIt
Is 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 â¦.
Stef
On 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 framework it 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.
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 one
UndefinedObject(Object)>>doesNotUnderstand: #drawDuring: Hyperion>>render Hyperion>>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 method
checkSession
session == Smalltalk session ifFalse: [ surface := surface := AthensCairoSurface extent: self extent. . session := Smalltalk session. ]
and This is my full stack
NBFFICallout 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 earlier
here is the full stack
Hyperion(Object)>>doesNotUnderstand: #passenger PackageTreeModel>>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>>processEvents WorldState>>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.
Stef
Again 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 stack
AthensViewMorph(Object)>>doesNotUnderstand: #layout: SpecInterpreter>>actionToPerformWithSelector:arguments: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>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>>performNextSelectorAndIncrementIndex SpecInterpreter>>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)>>openWithSpec AthensTutorial class>>open UndefinedObject>>DoIt
Is 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 â¦.
Stef
On 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 framework it 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.
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
one
UndefinedObject(Object)>>doesNotUnderstand: #drawDuring: Hyperion>>render Hyperion>>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 method
checkSession
session == Smalltalk session ifFalse: [ surface := surface := AthensCairoSurface extent: self extent. . session := Smalltalk session. ]
and This is my full stack
NBFFICallout 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 earlier
here is the full stack
Hyperion(Object)>>doesNotUnderstand: #passenger PackageTreeModel>>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>>processEvents WorldState>>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.
Stef
Again 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 stack
AthensViewMorph(Object)>>doesNotUnderstand: #layout: SpecInterpreter>>actionToPerformWithSelector:arguments: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>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>>performNextSelectorAndIncrementIndex SpecInterpreter>>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)>>openWithSpec AthensTutorial class>>open UndefinedObject>>DoIt
Is 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 â¦.
Stef
On 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 framework it 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.
Igor just for the record, I still have not figure out why I had this problem in the first place. I was using self extent and that was giving me a NB error as I posted in the first stack trace. I changed it to self defaultExtent that returns a point with the default size of the area of the Morph and voila it worked. I checked the Hierachy and Morph which is the super class of Hyperion has an extent method so this should work. So I think this may be an Athens bug after all. So i changed the method from checkSession session == Smalltalk session ifFalse: [surface := AthensCairoSurface extent: self extent . session := Smalltalk session ] to checkSession session == Smalltalk session ifFalse: [surface := AthensCairoSurface extent: self defaultExtent . session := Smalltalk session ] and now it works properly for some strange reason. At first I thought it was because there was no self extent method but now I see thats not the case. On Tue, Nov 12, 2013 at 1:20 PM, Igor Stasenko <siguctua@gmail.com> wrote:
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 one
UndefinedObject(Object)>>doesNotUnderstand: #drawDuring: Hyperion>>render Hyperion>>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 method
checkSession
session == Smalltalk session ifFalse: [ surface := surface := AthensCairoSurface extent: self extent. . session := Smalltalk session. ]
and This is my full stack
NBFFICallout 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 earlier
here is the full stack
Hyperion(Object)>>doesNotUnderstand: #passenger PackageTreeModel>>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>>processEvents WorldState>>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.
Stef
Again 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 stack
AthensViewMorph(Object)>>doesNotUnderstand: #layout: SpecInterpreter>>actionToPerformWithSelector:arguments: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>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>>performNextSelectorAndIncrementIndex SpecInterpreter>>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)>>openWithSpec AthensTutorial class>>open UndefinedObject>>DoIt
Is 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 â¦.
Stef
On 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 framework it 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.
I doubt it is related to Athens. I think it is initialization problem. If morph's extent depends on external factors, you should properly initialize them before computing it. It could be that you calling #checkSession before.. which leads to DNU, because no extent can be computed at given point yet. On 12 November 2013 12:59, kilon alios <kilon.alios@gmail.com> wrote:
Igor just for the record, I still have not figure out why I had this problem in the first place. I was using self extent and that was giving me a NB error as I posted in the first stack trace. I changed it to self defaultExtent that returns a point with the default size of the area of the Morph and voila it worked. I checked the Hierachy and Morph which is the super class of Hyperion has an extent method so this should work. So I think this may be an Athens bug after all.
So i changed the method from
checkSession session == Smalltalk session ifFalse: [surface := AthensCairoSurface extent: self extent . session := Smalltalk session ]
to
checkSession session == Smalltalk session ifFalse: [surface := AthensCairoSurface extent: self defaultExtent . session := Smalltalk session ]
and now it works properly for some strange reason. At first I thought it was because there was no self extent method but now I see thats not the case.
On Tue, Nov 12, 2013 at 1:20 PM, Igor Stasenko <siguctua@gmail.com> wrote:
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 one
UndefinedObject(Object)>>doesNotUnderstand: #drawDuring: Hyperion>>render Hyperion>>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 method
checkSession
session == Smalltalk session ifFalse: [ surface := surface := AthensCairoSurface extent: self extent. . session := Smalltalk session. ]
and This is my full stack
NBFFICallout 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 earlier
here is the full stack
Hyperion(Object)>>doesNotUnderstand: #passenger PackageTreeModel>>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>>processEvents WorldState>>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.
Stef
Again 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 stack
AthensViewMorph(Object)>>doesNotUnderstand: #layout: SpecInterpreter>>actionToPerformWithSelector:arguments: SpecInterpreter>>performNextSelectorAndIncrementIndex SpecInterpreter>>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>>performNextSelectorAndIncrementIndex SpecInterpreter>>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)>>openWithSpec AthensTutorial class>>open UndefinedObject>>DoIt
Is 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 â¦.
Stef
On 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 framework it 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.
-- Best regards, Igor Stasenko.
Regarding OpenGL, we intensively use it for Roassal3d, also available on smalltalkhub. Screenshots are available on https://m.facebook.com/ObjectProfile?id=340543479365589&_rdr Cheers, Alexandre
Le 31-10-2013 à 16:01, kilon alios <kilon.alios@gmail.com> a écrit :
Thank you Alexander and Stephane , I did not know that Roassal use Athens. This certainly will be helpful for me.
Stephane, about NBOpenGL , my problem was opengl itself not NBOpenGL , I learned a lot of things true and yeah I did not know Roassal is using NBOpenGL but even if I did as you said opengl is not what I really needed. At the time I did not realize the effort to do vector graphics with opengl and the whole difficulty of learning the API, now I know I need something way more high level for my needs.
About Athens tutorial, I dont know such thing, the only thing I know is AthensDemoMorph and the Athens-Examples Package and a video presentation that Igor posted way back in vimeo. So no I dont know of such tutorial.
Wow the guy took 62 K euros and left ? Sorry to hear that :( cant believe how people do such things .
On Thu, Oct 31, 2013 at 7:49 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote: Hi
I created a new subject
About the problem to recreate it all it takes is a demo := AthensDemoMorph new openInWorld . It opens the morph with the Athens grey box, I save the image , close pharo, open pharo which reloads the image automagically and BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph since I cant find documentation to do things differently.
So lets get to the questions
1) You say you have morphs using Athens that don't have this problem, care to explain further ?
Did you see the tutorial?
2) How do I recreate automatically those surfaces ?
3) Do I need to instruct the image on load to reinitialize those objects ?
4) If yes How I do that ?
You say its a major problem but yet its not an Athens bug. I know this is has to do with how image saves live objects and that NB calls are not part of the image hence creating the problem.
5) Are there ways to avoid the problem ?
6) Also why there is a Red Box of Doom in the first place ?
7) Why the debugger is not triggered as it should be ?
It is now you should bring the halos and click on debug draw something error
8) Is that critical a failure of Morphic ?
9) Why Athens even though is based largely on Cairo , and taking into consideration the intention to extend to other graphical interfaces, not following the Cairo design more closely so we can use the Cairo tutorials ?
Because Athens is not Cairo. Athens is an API so that we can have multiple graphical back-ends in the future.
10) Is the Cairo design so prohibiting / limiting for Athens ? Does Cairo do things so differently than other vector based libraries ?
Cairo does not have an OO design from what I know.
11) How important is Athens to Pharo community , meaning further bug fixes, improvements , tutorials etc ? I hear there is an intention to gradual move Morphic to it. Is this true ?
Athens is the new canvas and we will rewrite everything to use it. Now Athens will have a default version that is just the default balloon. Now the guy that should have helped us (fernando) left in hurry and we lost the money 62 K Euros of his salary. Igor has been working more than a year in total on Athens, textEditor and others so we will not give up now.
I really like Athens, I am asking all these questions because I need to make a fast decision whether I will continue to use Pharo or not for my project. Learning OpenGL and using NBOpenGL produced zero results for me.
Did you check Roassal 3d because they forgot to publish the enhancements they did to NBOpenGL
I was not even able to create a single triangle.
You should look at Roassal 3d because this is working.
My gpu driver because of Macos gave me close to zero errors, and Red Box of Doom made it impossible to debug opengl problems. In short close to zero error reporting made it a no go for me.
So I fall back at much simpler solutions because I want to create my own GUI API. I see several solutions for this
1) Pharo Athens 2) Amber SVG / WebGL based Vector libs like Pixi / Athens / HTML5 + CSS 3) Python + PyQT + QT
I rather stay with Pharo. But I already wasted months of doing nothing and going nowhere with NBOpenGL , I am tried of moving in circles.
I'm sure you learned probably a lot. Now for a GUI API may be openGL is not the best to start. What I can tell you is that with Athens we will be able to have the first mix between 3D and 2D vector graphics.
I am not frustrated cause I knew when I tried that OpenGL was very hard ( I was warned by several opengl people ) so failure was always an option , but I can no longer justify wasting my time getting nowhere.
I dont need much from a graphic lib all I need is
a) Stability . If it crashes regularly its no good
b) Speed, if moving graphic elements around slows down (anything above 20%) dual cores , its no good
c) Basic Feature set like , lines, curves , circles and ellipses , display of raster graphics, simple animations , import export of graphic formats, png , jpg and svg is enough.
Looks like Athens satisfies b and c , I am not so sure about a.
It is stable.
I am trying to understand Athens code from reading it, once again I am a big failure at understanding code.
The tutorial is the way to go. Why this is not enough.
So is there any hope for someone like me , that he is not a very good coder, he is new to Pharo and he has a simple mind to use Athens to make a basic GUI API ?
Yes just focus on Athens. For example extend the
On Thu, Oct 31, 2013 at 6:07 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 31 October 2013 16:40, kilon alios <kilon.alios@gmail.com> wrote: save the image while the morph is displayed, reload the image and in its place there is the big red box with the yellow X , reporting an error with Athens. I have reproduced the error on Windows too with the Athens examples. I assumed my explanation was clear , I hope its clear now.
no. not clear. which morph? what class, how you using it etc. I have morphs which using Athens for drawing and i can save and load image back and i don't have red squares of death.
This means that its impossible to save an image with a morph using Athens displaying and have it reload back when the image is reloaded. The athens-surface, especially cairo surface is valid only within a single session. if you boot new image, you must recreate (or stop using) surface you used in previous session. Otherwise you will have red box of doom.
And while i agree that this is pretty major problem (in terms of making your morph to be session-aware and in terms of managing external resources) i am far from calling it a bug of Athens of any kind per se.
On Thu, Oct 31, 2013 at 5:05 PM, Stéphane Ducasse <stephane.ducasse@inria.fr> wrote:
On Oct 31, 2013, at 9:55 AM, kilon alios <kilon.alios@gmail.com> wrote:
yes I am aware of the examples already, I am learning from them. Please note I have found a bug with Athens, which looks to me pretty major. If I save a morph using Athens
what do you mean save a morph
and reload the image,
what do you mean?
I see the red box of doom. For example trying your example from stackoverflow. Are you aware of this bug ?
On Thu, Oct 31, 2013 at 2:43 AM, Igor Stasenko <siguctua@gmail.com> wrote: ah, yes , there's also examples in Athens-Examples package.
On 31 October 2013 01:30, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 October 2013 23:02, kilon alios <kilon.alios@gmail.com> wrote: well I just asked if there is any kind of Documentation about Athens . Or should I just read the code and ask questions ?
the main source of documentation right now is class comments and tutorial. I've spent quite of a time commenting the central classes of athens, hope that's helpful. Of course this does not replacement for a well written docu, and that needs to be done.
On Wed, Oct 30, 2013 at 11:51 PM, Igor Stasenko <siguctua@gmail.com> wrote: i hope you satisfied with my answer. you welcome to ask more, if you not :)
On 30 October 2013 22:32, dimitris chloupis <thekilon@yahoo.co.uk> wrote: http://stackoverflow.com/questions/19694197/how-to-create-lines-with-athens
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
On 31 October 2013 18:24, kilon alios <kilon.alios@gmail.com> wrote:
I created a new subject
About the problem to recreate it all it takes is a demo := AthensDemoMorph new openInWorld . It opens the morph with the Athens grey box, I save the image , close pharo, open pharo which reloads the image automagically and BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph since I cant find documentation to do things differently.
That one is bad, it does not having session management code. Perhaps because the code there was authored before i figured what is most convenient pattern to deal with it, neither i thought about that at all, because it was too early to think about it. At that stage i was more concerned about that framework is capable of rendering stuff correctly. (see my other reply about that).
So lets get to the questions
1) You say you have morphs using Athens that don't have this problem, care to explain further ?
yes, there is number of morphs which correctly implement session-aware resource management, which you need when working with surfaces. AthensSceneView, AthensWrapMorph
The problem is that right now it is a little incursions (since Athens does not completely replaces old Canvas and runs in parallel to it), and there is no globals, like Display which manages that. This code had to be added at one day, but not before we figure, how we can deliver rendered data directly to OS-level window bypassing Form(s) and unnecessary bit copying here and there between number of double-triple-quadruple buffering which stands between Morphic and OS-level screen, which greatly hinders the screen update performance. (or at least figure our migration plan/path). But for that we also must cut out parts in VM and move responsibility for creating OS-level window(s) into image, not VM. The limitations, which we currently having in VM greatly cripples the number of choices of what can be done using Pharo for making desktop-level application. But it is more general problem, and there's nothing in Athens to blame for it. 2) How do I recreate automatically those surfaces ?
3) Do I need to instruct the image on load to reinitialize those objects ?
4) If yes How I do that ?
see how i did that in AthensSceneView, AthensWrapMorph
You say its a major problem but yet its not an Athens bug. I know this is has to do with how image saves live objects and that NB calls are not part of the image hence creating the problem.
5) Are there ways to avoid the problem ?
yes, use Smalltalk session object to check if session is changed before any attempt of using external resource(s).
6) Also why there is a Red Box of Doom in the first place ?
7) Why the debugger is not triggered as it should be ?
It is a general feature of Morphic: if there's an error during morph's drawing it renders it as red box, but not opens a debugger. because opening debugger implies that you will need to render debugger window, but if that code raising an error, you will enter endless recursion.
If you don't like it, you can disable it in Morph>>fullDrawOn: aCanvas (and then try to put a mistake in any morph's rendering code.. but don't say i didn't warned you ;) 8) Is that critical a failure of Morphic ?
It is not a failure, the red box is the only sane way how to keep things running, even if there's error(s) in code. But sometimes even that doesn't helps. Other choice would be to just leave to OS, because at that stage UI will be unresponsive anyways, but that will be even worse, isn't?
9) Why Athens even though is based largely on Cairo , and taking into consideration the intention to extend to other graphical interfaces, not following the Cairo design more closely so we can use the Cairo tutorials ?
The biggest source for design choices is not Cairo. But OpenVG standard. Cairo was easy to reach, low-hanging fruit which we grasp. A more expanded answer as for why Athens is not copy-paste of Cairo, you can read here: http://computeradventures.wordpress.com/2012/03/07/athens-a-first-babysteps/
[[ In other words, give me 1 week, a lump sum of money, and after 2 weeks [image: ;)] i will deliver you a binding to any C library you want. But do not expect that it will be much easier to use it, only because you can access it in smalltalk. This is because exposing a non-object oriented library in smalltalk does not automagically makes it by a bit more object oriented, especially in terms of smalltalk, not in terms of C++ [image: :)] . ]] 10) Is the Cairo design so prohibiting / limiting for Athens ? Does Cairo
do things so differently than other vector based libraries ?
Most of them providing more or less same set of features. But each of them has own API and own idiosyncrasies to deal with, and Athens here to serve for hiding unnecessary details from users and provide a consistent object-oriented API.
11) How important is Athens to Pharo community , meaning further bug fixes, improvements , tutorials etc ? I hear there is an intention to gradual move Morphic to it. Is this true ?
Yes, it is our future.
I really like Athens, I am asking all these questions because I need to make a fast decision whether I will continue to use Pharo or not for my project. Learning OpenGL and using NBOpenGL produced zero results for me. I was not even able to create a single triangle. My gpu driver because of Macos gave me close to zero errors, and Red Box of Doom made it impossible to debug opengl problems. In short close to zero error reporting made it a no go for me.
Sounds like you surrendered too quickly. :) I know multiple people who managed to do things with it, like importing 3d models and rendering them. But sure thing, it is not easy and requires a lot of effort and broad knowledge in multiple areas and abilities to learn & search for examples and docs and understanding the mechanics behind everything.
So I fall back at much simpler solutions because I want to create my own GUI API. I see several solutions for this
1) Pharo Athens 2) Amber SVG / WebGL based Vector libs like Pixi / Athens / HTML5 + CSS 3) Python + PyQT + QT
I rather stay with Pharo. But I already wasted months of doing nothing and going nowhere with NBOpenGL , I am tried of moving in circles. I am not frustrated cause I knew when I tried that OpenGL was very hard ( I was warned by several opengl people ) so failure was always an option , but I can no longer justify wasting my time getting nowhere.
you can ask Alex, who has working examples of opengl. Roassal 3D.
I dont need much from a graphic lib all I need is
a) Stability . If it crashes regularly its no good
b) Speed, if moving graphic elements around slows down (anything above 20%) dual cores , its no good
c) Basic Feature set like , lines, curves , circles and ellipses , display of raster graphics, simple animations , import export of graphic formats, png , jpg and svg is enough.
Looks like Athens satisfies b and c , I am not so sure about a.
I dealing with Athens for... ?last year? almost every day during my work.. don't have much problems here. And that would be my top-priority taks, if it would be a problem, because it would be blocking my own work.
I am trying to understand Athens code from reading it, once again I am a big failure at understanding code.
ask questions. I will gladly help understanding.
So is there any hope for someone like me , that he is not a very good coder, he is new to Pharo and he has a simple mind to use Athens to make a basic GUI API ?
Definitely yes :)
On Thu, Oct 31, 2013 at 6:07 PM, Igor Stasenko <siguctua@gmail.com> wrote:
On 31 October 2013 16:40, kilon alios <kilon.alios@gmail.com> wrote:
save the image while the morph is displayed, reload the image and in its place there is the big red box with the yellow X , reporting an error with Athens. I have reproduced the error on Windows too with the Athens examples. I assumed my explanation was clear , I hope its clear now.
no. not clear. which morph? what class, how you using it etc. I have morphs which using Athens for drawing and i can save and load image back and i don't have red squares of death.
This means that its impossible to save an image with a morph using Athens displaying and have it reload back when the image is reloaded.
The athens-surface, especially cairo surface is valid only within a single session. if you boot new image, you must recreate (or stop using) surface you used in previous session. Otherwise you will have red box of doom.
And while i agree that this is pretty major problem (in terms of making your morph to be session-aware and in terms of managing external resources) i am far from calling it a bug of Athens of any kind per se.
On Thu, Oct 31, 2013 at 5:05 PM, Stéphane Ducasse < stephane.ducasse@inria.fr> wrote:
On Oct 31, 2013, at 9:55 AM, kilon alios <kilon.alios@gmail.com> wrote:
yes I am aware of the examples already, I am learning from them. Please note I have found a bug with Athens, which looks to me pretty major. If I save a morph using Athens
what do you mean save a morph
and reload the image,
what do you mean?
I see the red box of doom. For example trying your example from stackoverflow. Are you aware of this bug ?
On Thu, Oct 31, 2013 at 2:43 AM, Igor Stasenko <siguctua@gmail.com>wrote:
ah, yes , there's also examples in Athens-Examples package.
On 31 October 2013 01:30, Igor Stasenko <siguctua@gmail.com> wrote:
On 30 October 2013 23:02, kilon alios <kilon.alios@gmail.com> wrote:
well I just asked if there is any kind of Documentation about Athens . Or should I just read the code and ask questions ?
the main source of documentation right now is class comments and tutorial. I've spent quite of a time commenting the central classes of athens, hope that's helpful. Of course this does not replacement for a well written docu, and that needs to be done.
On Wed, Oct 30, 2013 at 11:51 PM, Igor Stasenko <siguctua@gmail.com>wrote:
i hope you satisfied with my answer. you welcome to ask more, if you not :)
On 30 October 2013 22:32, dimitris chloupis <thekilon@yahoo.co.uk>wrote:
http://stackoverflow.com/questions/19694197/how-to-create-lines-with-athens
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
-- Best regards, Igor Stasenko.
kilon alios wrote:
About the problem to recreate it all it takes is a demo := AthensDemoMorph new openInWorld . It opens the morph with the Athens grey box, I save the image , close pharo, open pharo which reloads the image automagically and BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph since I cant find documentation to do things differently.
So lets get to the questions
6) Also why there is a Red Box of Doom in the first place ?
See #drawErrorOn: call from... Morph>>fullDrawOn: self visible ifFalse: [^ self]. (aCanvas isVisible: self fullBounds) ifFalse:[^self]. (self hasProperty: #errorOnDraw) ifTrue:[^self drawErrorOn: aCanvas]. [ "calls to each Morph's drawing stuff" ] on: Error do: [:err | "Smalltalk at: #morphDebugOnce ifPresent: [ Smalltalk remove: #morphDebugOnce. self halt ]. self setProperty: #errorOnDraw toValue: true. self setProperty: #drawError toValue: err freeze. ^ self drawErrorOn: aCanvas ] --------------- In the past I have successfully debugged a morph by adding something like the commented line. Although I can't quite remember if 'self halt' is correct. Perhaps it should be 'err raise'. Perhaps others with more experience of the debugger internals can comment. From a workspace just evaluate 'Smalltalk at: #morphDebugOnce put: #anything' before opening the morph. Or if the morph is already open and you have a reference theMorph, then you can try 'theMorph setProperty: #errorOnDraw toValue: false' to cause the bad morph code to run again. You can get a reference to an existing morph by enabling 'Create textual references to dropped morphs' from the window menu of a Workspace - then from the window menu select 'inspect variables' Now what would be really interesting is if in place of my commented line, the debugging context of the error was serialized using Fuel to a variable and then clicking on the red-square-of-death brought up a debugger on that. Something like this... Morph>>fullDrawOn: self visible ifFalse: [^ self]. (aCanvas isVisible: self fullBounds) ifFalse:[^self]. (self hasProperty: #errorOnDraw) ifTrue:[^self drawErrorOn: aCanvas debugOn: (self property: #drawError) ]. [ "calls to each Morph's drawing stuff" ] on: Error do: [:err | self setProperty: #errorOnDraw toValue: true. self setProperty: #drawError toValue: (Fuel serializedDebuggingContextOf: err. "***". ^ self drawErrorOn: aCanvas ] "*** Disclaimer: I haven't used Fuel yet, so I don't have the faintest idea what the proper method here should be."
7) Why the debugger is not triggered as it should be ?
Because Morph>>fullDrawOn: is called many times a second. You would end up with dozens of debuggers coming up faster than you can respond.
8) Is that critical a failure of Morphic ?
Its an error in the drawing code of that particular morph. cheers -ben
On 2013-11-01, at 16:44, btc@openinworld.com wrote:
kilon alios wrote:
About the problem to recreate it all it takes is a demo := AthensDemoMorph new openInWorld . It opens the morph with the Athens grey box, I save the image , close pharo, open pharo which reloads the image automagically and BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph since I cant find documentation to do things differently.
So lets get to the questions
6) Also why there is a Red Box of Doom in the first place ?
See #drawErrorOn: call from...
Morph>>fullDrawOn: self visible ifFalse: [^ self]. (aCanvas isVisible: self fullBounds) ifFalse:[^self]. (self hasProperty: #errorOnDraw) ifTrue:[^self drawErrorOn: aCanvas]. [ "calls to each Morph's drawing stuff" ] on: Error do: [:err | "Smalltalk at: #morphDebugOnce ifPresent: [ Smalltalk remove: #morphDebugOnce. self halt ]. self setProperty: #errorOnDraw toValue: true. self setProperty: #drawError toValue: err freeze. ^ self drawErrorOn: aCanvas ] --------------- In the past I have successfully debugged a morph by adding something like the commented line. Although I can't quite remember if 'self halt' is correct. Perhaps it should be 'err raise'. Perhaps others with more experience of the debugger internals can comment. From a workspace just evaluate 'Smalltalk at: #morphDebugOnce put: #anything' before opening the morph. Or if the morph is already open and you have a reference theMorph, then you can try 'theMorph setProperty: #errorOnDraw toValue: false' to cause the bad morph code to run again. You can get a reference to an existing morph by enabling 'Create textual references to dropped morphs' from the window menu of a Workspace - then from the window menu select 'inspect variables'
Now what would be really interesting is if in place of my commented line, the debugging context of the error was serialized using Fuel to a variable and then clicking on the red-square-of-death brought up a debugger on that. Something like this...
Morph>>fullDrawOn: self visible ifFalse: [^ self]. (aCanvas isVisible: self fullBounds) ifFalse:[^self]. (self hasProperty: #errorOnDraw) ifTrue:[^self drawErrorOn: aCanvas debugOn: (self property: #drawError) ]. [ "calls to each Morph's drawing stuff" ] on: Error do: [:err | self setProperty: #errorOnDraw toValue: true. self setProperty: #drawError toValue: (Fuel serializedDebuggingContextOf: err. "***". ^ self drawErrorOn: aCanvas ] "*** Disclaimer: I haven't used Fuel yet, so I don't have the faintest idea what the proper method here should be."
You have in the halo menu an entry "debug drawing error" which does what you want. As you can see there is already the line:
self setProperty: #drawError toValue: err freeze.
which serializes the whole error (no need to use fuel as long as you stay in the image...).
Thanks guys, I already tried Stephane and now Camillo's suggestion with debug morph and works like a charm :) . Definetly makes my life a lot easier. btc self halt inserts a breakpoint to your code, so that execution stops there and debugger pops up. I find all this highly fascinating because its an area of coding that deeply interests me. Even when I don't code I love reading Pharo code, its so nice :) On Fri, Nov 1, 2013 at 7:13 PM, <btc@openinworld.com> wrote:
** Camillo Bruni wrote:
On 2013-11-01, at 16:44, btc@openinworld.com wrote:
kilon alios wrote:
About the problem to recreate it all it takes is a demo := AthensDemoMorph new openInWorld . It opens the morph with the Athens grey box, I save the image , close pharo, open pharo which reloads the image automagically and BOOM Red Box of Doom :) My other tries also are based on AthensDemoMorph since I cant find documentation to do things differently.
So lets get to the questions
6) Also why there is a Red Box of Doom in the first place ?
See #drawErrorOn: call from...
Morph>>fullDrawOn: self visible ifFalse: [^ self]. (aCanvas isVisible: self fullBounds) ifFalse:[^self]. (self hasProperty: #errorOnDraw) ifTrue:[^self drawErrorOn: aCanvas]. [ "calls to each Morph's drawing stuff" ] on: Error do: [:err | "Smalltalk at: #morphDebugOnce ifPresent: [ Smalltalk remove: #morphDebugOnce. self halt ]. self setProperty: #errorOnDraw toValue: true. self setProperty: #drawError toValue: err freeze. ^ self drawErrorOn: aCanvas ] --------------- In the past I have successfully debugged a morph by adding something like the commented line. Although I can't quite remember if 'self halt' is correct. Perhaps it should be 'err raise'. Perhaps others with more experience of the debugger internals can comment. From a workspace just evaluate 'Smalltalk at: #morphDebugOnce put: #anything' before opening the morph. Or if the morph is already open and you have a reference theMorph, then you can try 'theMorph setProperty: #errorOnDraw toValue: false' to cause the bad morph code to run again. You can get a reference to an existing morph by enabling 'Create textual references to dropped morphs' from the window menu of a Workspace - then from the window menu select 'inspect variables'
Now what would be really interesting is if in place of my commented line, the debugging context of the error was serialized using Fuel to a variable and then clicking on the red-square-of-death brought up a debugger on that. Something like this...
Morph>>fullDrawOn: self visible ifFalse: [^ self]. (aCanvas isVisible: self fullBounds) ifFalse:[^self]. (self hasProperty: #errorOnDraw) ifTrue:[^self drawErrorOn: aCanvas debugOn: (self property: #drawError) ]. [ "calls to each Morph's drawing stuff" ] on: Error do: [:err | self setProperty: #errorOnDraw toValue: true. self setProperty: #drawError toValue: (Fuel serializedDebuggingContextOf: err. "***". ^ self drawErrorOn: aCanvas ] "*** Disclaimer: I haven't used Fuel yet, so I don't have the faintest idea what the proper method here should be."
You have in the halo menu an entry "debug drawing error" which does what you want. As you can see there is already the line:
self setProperty: #drawError toValue: err freeze.
which serializes the whole error (no need to use fuel as long as you stay in the image...).
Thats brilliant! I think thats new since last time I had to debug a morph. I did see 'err freeze' in passing just earlier and wonder. However the functionality is a bit hidden. To make it more obvious, perhaps #drawErrorOn: could be modified as follows...
self valueOfProperty: #drawError ifPresentDo: [ :error| | trace stringBounds | trace := String streamContents: [ :s| error signalerContext shortDebugStackOn: s]. trace := 'Use Halos>Debug>debug drawing error' , String cr , trace. --------------------
btw kilon, you can experiment with that by adding a '1/0' to EllipseMorph>>drawOn: and evaluating (EllipseMorph new extent: 300@300) openInWorld.
cheers -ben
participants (6)
-
Alexandre Bergel -
btc＠openinworld.com -
Camillo Bruni -
Igor Stasenko -
kilon alios -
Stéphane Ducasse