Roassal3D and Woden process handling
Hi guys, Iâm not experienced in OpenGL, but Iâve noticed that both Roassal3D and Woden occupy a high level process and are not yielding Processor to anyone else. For example code highlight, spotter, and other lower priority processes are not working as soon as you open a 3D visualization. On the other hand this doesnât happen while using CodeCity (and it also uses OpenGL). Is it very complicated to make Roassal3D and Woden to respect other processes? Uko
Hi! This is an excellent question. Ronie? Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On May 4, 2015, at 9:33 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi guys,
Iâm not experienced in OpenGL, but Iâve noticed that both Roassal3D and Woden occupy a high level process and are not yielding Processor to anyone else. For example code highlight, spotter, and other lower priority processes are not working as soon as you open a 3D visualization. On the other hand this doesnât happen while using CodeCity (and it also uses OpenGL). Is it very complicated to make Roassal3D and Woden to respect other processes?
Uko
Hi Yuriy, Process and OpenGL are a pain in the ass. This is why I hate the Smalltalk green threads, for the following reasons: - Operating system Thread Local Storage is not respected. The current OpenGL is a thread local variable. - No completely preemptive. Making Woden and Woden-Roassal to have a lower priority is a problem, because of reduced performance in Woden. When using OpenGL, the functions glFinish or SwapBuffers has to be called to force the execution of commands an display the rendered image in the screen. SwapBuffers usually calls glFlush. And if, v-sync is enabled, it blocks, which does not get well Pharo. With OSWindow, OpenGL can also be used to render the main Pharo window via SDL2. Because of this, I had to introduce a rendering process in OSWindow, which I am using to serialize all the OpenGL commands. And I guess that it also produces a reduction in performance. This thread is located OSWindowRenderThread. Perhaps you can fix the problem somewhere in OSWindowRenderThread. Best regards, Ronie 2015-05-04 11:36 GMT-03:00 Alexandre Bergel <alexandre.bergel@me.com>:
Hi!
This is an excellent question. Ronie?
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On May 4, 2015, at 9:33 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi guys,
Iâm not experienced in OpenGL, but Iâve noticed that both Roassal3D and Woden occupy a high level process and are not yielding Processor to anyone else. For example code highlight, spotter, and other lower priority processes are not working as soon as you open a 3D visualization. On the other hand this doesnât happen while using CodeCity (and it also uses OpenGL). Is it very complicated to make Roassal3D and Woden to respect other processes?
Uko
On Mon, May 4, 2015 at 4:16 PM, Ronie Salgado <roniesalg@gmail.com> wrote:
Hi Yuriy,
Process and OpenGL are a pain in the ass. This is why I hate the Smalltalk green threads, for the following reasons: - Operating system Thread Local Storage is not respected. The current OpenGL is a thread local variable. - No completely preemptive.
Making Woden and Woden-Roassal to have a lower priority is a problem, because of reduced performance in Woden. When using OpenGL, the functions glFinish or SwapBuffers has to be called to force the execution of commands an display the rendered image in the screen. SwapBuffers usually calls glFlush. And if, v-sync is enabled, it blocks, which does not get well Pharo.
With OSWindow, OpenGL can also be used to render the main Pharo window via SDL2. Because of this, I had to introduce a rendering process in OSWindow, which I am using to serialize all the OpenGL commands. And I guess that it also produces a reduction in performance. This thread is located OSWindowRenderThread.
Perhaps you can fix the problem somewhere in OSWindowRenderThread.
Not having had a look, I suppose that this is a green thread in Pharo. Why not having a real OS thread doing the glFinish/SwapBuffers instead? and some OpenGL ThreadLocal interface? I am facing a kind of similar situation for another project. My current line of thought is that the best stable/fast thing is to have the 3D engine as a separate process (as in a true OS process) to which I do send high level commands. Of course, this makes it necessary to have a DSL to talk with and that extending the 3D engine is somewhat of a pain when in need of new commands. But it allows to do whatever I want in Pharo without blocking the rendering loop. What would be the design you'd like to see for Woden, Ronie? Phil
Best regards, Ronie
2015-05-04 11:36 GMT-03:00 Alexandre Bergel <alexandre.bergel@me.com>:
Hi!
This is an excellent question. Ronie?
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On May 4, 2015, at 9:33 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Hi guys,
Iâm not experienced in OpenGL, but Iâve noticed that both Roassal3D and Woden occupy a high level process and are not yielding Processor to anyone else. For example code highlight, spotter, and other lower priority processes are not working as soon as you open a 3D visualization. On the other hand this doesnât happen while using CodeCity (and it also uses OpenGL). Is it very complicated to make Roassal3D and Woden to respect other processes?
Uko
--
Sadly, Iâm not very experienced in that topic. I just looked at CodeCity running on my colleagueâs matching and syntax highlighting working. The view is also subclassing GLViewportMorph, but other than that I canât tell why CodeCity is not blocking the other processes. Uko
On 04 May 2015, at 16:47, phil@highoctane.be wrote:
On Mon, May 4, 2015 at 4:16 PM, Ronie Salgado <roniesalg@gmail.com <mailto:roniesalg@gmail.com>> wrote: Hi Yuriy,
Process and OpenGL are a pain in the ass. This is why I hate the Smalltalk green threads, for the following reasons: - Operating system Thread Local Storage is not respected. The current OpenGL is a thread local variable. - No completely preemptive.
Making Woden and Woden-Roassal to have a lower priority is a problem, because of reduced performance in Woden. When using OpenGL, the functions glFinish or SwapBuffers has to be called to force the execution of commands an display the rendered image in the screen. SwapBuffers usually calls glFlush. And if, v-sync is enabled, it blocks, which does not get well Pharo.
With OSWindow, OpenGL can also be used to render the main Pharo window via SDL2. Because of this, I had to introduce a rendering process in OSWindow, which I am using to serialize all the OpenGL commands. And I guess that it also produces a reduction in performance. This thread is located OSWindowRenderThread.
Perhaps you can fix the problem somewhere in OSWindowRenderThread.
Not having had a look, I suppose that this is a green thread in Pharo.
Why not having a real OS thread doing the glFinish/SwapBuffers instead? and some OpenGL ThreadLocal interface?
I am facing a kind of similar situation for another project.
My current line of thought is that the best stable/fast thing is to have the 3D engine as a separate process (as in a true OS process) to which I do send high level commands.
Of course, this makes it necessary to have a DSL to talk with and that extending the 3D engine is somewhat of a pain when in need of new commands.
But it allows to do whatever I want in Pharo without blocking the rendering loop.
What would be the design you'd like to see for Woden, Ronie?
Phil
Best regards, Ronie
2015-05-04 11:36 GMT-03:00 Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>>: Hi!
This is an excellent question. Ronie?
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On May 4, 2015, at 9:33 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
Hi guys,
Iâm not experienced in OpenGL, but Iâve noticed that both Roassal3D and Woden occupy a high level process and are not yielding Processor to anyone else. For example code highlight, spotter, and other lower priority processes are not working as soon as you open a 3D visualization. On the other hand this doesnât happen while using CodeCity (and it also uses OpenGL). Is it very complicated to make Roassal3D and Woden to respect other processes?
Uko
--
Hi Yuriy! I gave a try to fix the problem. Now, if the rendered is left untouched, there is no unnecessary refresh. The problem now is that the keystrokes are not properly handled⦠Can you give you try please? Does this solve your problem? Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On May 4, 2015, at 12:09 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com> wrote:
Sadly, Iâm not very experienced in that topic. I just looked at CodeCity running on my colleagueâs matching and syntax highlighting working. The view is also subclassing GLViewportMorph, but other than that I canât tell why CodeCity is not blocking the other processes.
Uko
On 04 May 2015, at 16:47, phil@highoctane.be <mailto:phil@highoctane.be> wrote:
On Mon, May 4, 2015 at 4:16 PM, Ronie Salgado <roniesalg@gmail.com <mailto:roniesalg@gmail.com>> wrote: Hi Yuriy,
Process and OpenGL are a pain in the ass. This is why I hate the Smalltalk green threads, for the following reasons: - Operating system Thread Local Storage is not respected. The current OpenGL is a thread local variable. - No completely preemptive.
Making Woden and Woden-Roassal to have a lower priority is a problem, because of reduced performance in Woden. When using OpenGL, the functions glFinish or SwapBuffers has to be called to force the execution of commands an display the rendered image in the screen. SwapBuffers usually calls glFlush. And if, v-sync is enabled, it blocks, which does not get well Pharo.
With OSWindow, OpenGL can also be used to render the main Pharo window via SDL2. Because of this, I had to introduce a rendering process in OSWindow, which I am using to serialize all the OpenGL commands. And I guess that it also produces a reduction in performance. This thread is located OSWindowRenderThread.
Perhaps you can fix the problem somewhere in OSWindowRenderThread.
Not having had a look, I suppose that this is a green thread in Pharo.
Why not having a real OS thread doing the glFinish/SwapBuffers instead? and some OpenGL ThreadLocal interface?
I am facing a kind of similar situation for another project.
My current line of thought is that the best stable/fast thing is to have the 3D engine as a separate process (as in a true OS process) to which I do send high level commands.
Of course, this makes it necessary to have a DSL to talk with and that extending the 3D engine is somewhat of a pain when in need of new commands.
But it allows to do whatever I want in Pharo without blocking the rendering loop.
What would be the design you'd like to see for Woden, Ronie?
Phil
Best regards, Ronie
2015-05-04 11:36 GMT-03:00 Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>>: Hi!
This is an excellent question. Ronie?
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On May 4, 2015, at 9:33 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
Hi guys,
Iâm not experienced in OpenGL, but Iâve noticed that both Roassal3D and Woden occupy a high level process and are not yielding Processor to anyone else. For example code highlight, spotter, and other lower priority processes are not working as soon as you open a 3D visualization. On the other hand this doesnât happen while using CodeCity (and it also uses OpenGL). Is it very complicated to make Roassal3D and Woden to respect other processes?
Uko
--
On 04 May 2015, at 22:59, Alexandre Bergel <alexandre.bergel@me.com> wrote:
Hi Yuriy!
I gave a try to fix the problem. Now, if the rendered is left untouched, there is no unnecessary refresh. The problem now is that the keystrokes are not properly handled⦠Can you give you try please? Does this solve your problem?
This looks cool! I wonder what we can do with controls, because for now the problem is that after key was pressed nothing else happens, and so the view is not updated. I think that we can either keep it updated on keypressed or update it periodically if any animation has to be done (like movement). But the second approach is more complicated. Uko
Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On May 4, 2015, at 12:09 PM, Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
Sadly, Iâm not very experienced in that topic. I just looked at CodeCity running on my colleagueâs matching and syntax highlighting working. The view is also subclassing GLViewportMorph, but other than that I canât tell why CodeCity is not blocking the other processes.
Uko
On 04 May 2015, at 16:47, phil@highoctane.be <mailto:phil@highoctane.be> wrote:
On Mon, May 4, 2015 at 4:16 PM, Ronie Salgado <roniesalg@gmail.com <mailto:roniesalg@gmail.com>> wrote: Hi Yuriy,
Process and OpenGL are a pain in the ass. This is why I hate the Smalltalk green threads, for the following reasons: - Operating system Thread Local Storage is not respected. The current OpenGL is a thread local variable. - No completely preemptive.
Making Woden and Woden-Roassal to have a lower priority is a problem, because of reduced performance in Woden. When using OpenGL, the functions glFinish or SwapBuffers has to be called to force the execution of commands an display the rendered image in the screen. SwapBuffers usually calls glFlush. And if, v-sync is enabled, it blocks, which does not get well Pharo.
With OSWindow, OpenGL can also be used to render the main Pharo window via SDL2. Because of this, I had to introduce a rendering process in OSWindow, which I am using to serialize all the OpenGL commands. And I guess that it also produces a reduction in performance. This thread is located OSWindowRenderThread.
Perhaps you can fix the problem somewhere in OSWindowRenderThread.
Not having had a look, I suppose that this is a green thread in Pharo.
Why not having a real OS thread doing the glFinish/SwapBuffers instead? and some OpenGL ThreadLocal interface?
I am facing a kind of similar situation for another project.
My current line of thought is that the best stable/fast thing is to have the 3D engine as a separate process (as in a true OS process) to which I do send high level commands.
Of course, this makes it necessary to have a DSL to talk with and that extending the 3D engine is somewhat of a pain when in need of new commands.
But it allows to do whatever I want in Pharo without blocking the rendering loop.
What would be the design you'd like to see for Woden, Ronie?
Phil
Best regards, Ronie
2015-05-04 11:36 GMT-03:00 Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>>: Hi!
This is an excellent question. Ronie?
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On May 4, 2015, at 9:33 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
Hi guys,
Iâm not experienced in OpenGL, but Iâve noticed that both Roassal3D and Woden occupy a high level process and are not yielding Processor to anyone else. For example code highlight, spotter, and other lower priority processes are not working as soon as you open a 3D visualization. On the other hand this doesnât happen while using CodeCity (and it also uses OpenGL). Is it very complicated to make Roassal3D and Woden to respect other processes?
Uko
--
Hi Phil, There are different efforts going on here: - Woden, as far as I understand, is about having a fast platform to make game. This is a very valuable effort, however it takes time to reach this. And indeed, green threads seems to have its limitations. - Roassal3d, which is about visualizing data in 3d. We are slowly getting back to Roassal 3d (now that the Roassal 2d front is more quite, due to the stability of it). Cheers, Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On May 4, 2015, at 10:47 AM, phil@highoctane.be wrote:
On Mon, May 4, 2015 at 4:16 PM, Ronie Salgado <roniesalg@gmail.com <mailto:roniesalg@gmail.com>> wrote: Hi Yuriy,
Process and OpenGL are a pain in the ass. This is why I hate the Smalltalk green threads, for the following reasons: - Operating system Thread Local Storage is not respected. The current OpenGL is a thread local variable. - No completely preemptive.
Making Woden and Woden-Roassal to have a lower priority is a problem, because of reduced performance in Woden. When using OpenGL, the functions glFinish or SwapBuffers has to be called to force the execution of commands an display the rendered image in the screen. SwapBuffers usually calls glFlush. And if, v-sync is enabled, it blocks, which does not get well Pharo.
With OSWindow, OpenGL can also be used to render the main Pharo window via SDL2. Because of this, I had to introduce a rendering process in OSWindow, which I am using to serialize all the OpenGL commands. And I guess that it also produces a reduction in performance. This thread is located OSWindowRenderThread.
Perhaps you can fix the problem somewhere in OSWindowRenderThread.
Not having had a look, I suppose that this is a green thread in Pharo.
Why not having a real OS thread doing the glFinish/SwapBuffers instead? and some OpenGL ThreadLocal interface?
I am facing a kind of similar situation for another project.
My current line of thought is that the best stable/fast thing is to have the 3D engine as a separate process (as in a true OS process) to which I do send high level commands.
Of course, this makes it necessary to have a DSL to talk with and that extending the 3D engine is somewhat of a pain when in need of new commands.
But it allows to do whatever I want in Pharo without blocking the rendering loop.
What would be the design you'd like to see for Woden, Ronie?
Phil
Best regards, Ronie
2015-05-04 11:36 GMT-03:00 Alexandre Bergel <alexandre.bergel@me.com <mailto:alexandre.bergel@me.com>>: Hi!
This is an excellent question. Ronie?
Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu <http://www.bergel.eu/> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On May 4, 2015, at 9:33 AM, Yuriy Tymchuk <yuriy.tymchuk@me.com <mailto:yuriy.tymchuk@me.com>> wrote:
Hi guys,
Iâm not experienced in OpenGL, but Iâve noticed that both Roassal3D and Woden occupy a high level process and are not yielding Processor to anyone else. For example code highlight, spotter, and other lower priority processes are not working as soon as you open a 3D visualization. On the other hand this doesnât happen while using CodeCity (and it also uses OpenGL). Is it very complicated to make Roassal3D and Woden to respect other processes?
Uko
--
participants (4)
-
Alexandre Bergel -
phil＠highoctane.be -
Ronie Salgado -
Yuriy Tymchuk