Roassal3D and Woden process handling

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|

Roassal3D and Woden process handling

Uko2
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
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Roassal3D and Woden process handling

abergel
Hi!

This is an excellent question. Ronie?

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 4, 2015, at 9:33 AM, Yuriy Tymchuk <[hidden email]> 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


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev
Reply | Threaded
Open this post in threaded view
|

Re: Roassal3D and Woden process handling

Ronie Salgado
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 <[hidden email]>:
Hi!

This is an excellent question. Ronie?

Alexandre
-- 
_,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
Alexandre Bergel  http://www.bergel.eu
^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.



On May 4, 2015, at 9:33 AM, Yuriy Tymchuk <[hidden email]> 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



_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev