Graphic System Arquitecture Question
Hello, I want to know about the Pharo graphic system architecture, I whould like to know if there's some documentation explaining his inner works. For NBOpenGL and Roassal 3D in particular, I'm having some flickering, which I think is related to the way that the OpenGL framebuffer is transferred into a pharo window. In NBOpenGL, rendering is done in a offscreen FBO, whose content is transferred into main memory y blitted into a pharo window. The pharo window of course must be blitted or renderer into the screen, which means anothere transfer into the GPU. In other words, we are a GPU->CPU->GPU memory roundtrip. The consequences of this are the lost of performance, the lost of double-buffering and which is more important, the lost v-sync. The lack of v-sync is seen in the way of tearing, which is more appreciated when moving on the X-axis in a 3d view, such as in the Roassal3D example in R3Example>>city. I have heard that in pharo 3, all of the graphics are being moving into Athens, a new graphics, for which I donr't know where's the documentation. I believe that athens is a vector graphics API, which several backends as cairo, which also has an opengl backend. I would like to share that OpenGL context to avoid that round-trip if possible, or use a native window for the OpenGL stuff, but to that I need to know how pharo graphics are done. Greetings, Ronie Salgado
On Nov 22, 2013, at 6:57 PM, Ronie Salgado <roniesalg@gmail.com> wrote:
Hello,
I want to know about the Pharo graphic system architecture, I whould like to know if there's some documentation explaining his inner works.
For NBOpenGL and Roassal 3D in particular, I'm having some flickering, which I think is related to the way that the OpenGL framebuffer is transferred into a pharo window.
In NBOpenGL, rendering is done in a offscreen FBO, whose content is transferred into main memory y blitted into a pharo window. The pharo window of course must be blitted or renderer into the screen, which means anothere transfer into the GPU. In other words, we are a GPU->CPU->GPU memory roundtrip.
Yes and igor would love to have the time to avoid this and only use and share one memory
The consequences of this are the lost of performance, the lost of double-buffering and which is more important, the lost v-sync. The lack of v-sync is seen in the way of tearing, which is more appreciated when moving on the X-axis in a 3d view, such as in the Roassal3D example in R3Example>>city.
I have heard that in pharo 3, all of the graphics are being moving into Athens, a new graphics, for which I donr't know where's the documentation.
There is a simple tutorial example. May be check on the Athens repo or on the mailing-list (I have to run now)
I believe that athens is a vector graphics API,
exact API. the idea is to have different back end. One that is the default one (balloon), one with cairo and probably some others in the future.
which several backends as cairo, which also has an opengl backend. I would like to share that OpenGL context to avoid that round-trip if possible, or use a native window for the OpenGL stuff, but to that I need to know how pharo graphics are done.
You should have a look at the VM code and the graphics primitive. VM guys will tell you where you can find the latest version of VMMaker for Pharo.
Greetings, Ronie Salgado
It would be great to have this issue debated and fixed. I have the impression that using the Cairo backend suffers from the same problem. Alexandre
Le 22-11-2013 à 14:57, Ronie Salgado <roniesalg@gmail.com> a écrit :
Hello,
I want to know about the Pharo graphic system architecture, I whould like to know if there's some documentation explaining his inner works.
For NBOpenGL and Roassal 3D in particular, I'm having some flickering, which I think is related to the way that the OpenGL framebuffer is transferred into a pharo window.
In NBOpenGL, rendering is done in a offscreen FBO, whose content is transferred into main memory y blitted into a pharo window. The pharo window of course must be blitted or renderer into the screen, which means anothere transfer into the GPU. In other words, we are a GPU->CPU->GPU memory roundtrip.
The consequences of this are the lost of performance, the lost of double-buffering and which is more important, the lost v-sync. The lack of v-sync is seen in the way of tearing, which is more appreciated when moving on the X-axis in a 3d view, such as in the Roassal3D example in R3Example>>city.
I have heard that in pharo 3, all of the graphics are being moving into Athens, a new graphics, for which I donr't know where's the documentation. I believe that athens is a vector graphics API, which several backends as cairo, which also has an opengl backend. I would like to share that OpenGL context to avoid that round-trip if possible, or use a native window for the OpenGL stuff, but to that I need to know how pharo graphics are done.
Greetings, Ronie Salgado
It would be great to have this issue debated and fixed. I have the impression that using the Cairo backend suffers from the same problem.
Money and time. This is not a question of debating this is about doing and having more people helping the core so that we can do something important. Stef
participants (3)
-
Alexandre Bergel -
Ronie Salgado -
Stéphane Ducasse