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, [email protected] wrote: > > > > On Mon, May 4, 2015 at 4:16 PM, Ronie Salgado <[email protected] > <mailto:[email protected]>> 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 <[email protected] > <mailto:[email protected]>>: > 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 <[email protected] >> <mailto:[email protected]>> 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 > > > > > > -- > >
