[Pharo-project] fun with NBOpenGL
On 24 February 2012 01:26, Lawson English <lenglish5@cox.net> wrote:
I was experimenting a little bit. What is the best way, using code, Â to put an GLViewportMorph into a scrollpane? the things I have tried so far seem to either crash Pharo or not work as I expect.
By default GLViewportMorph copying a rendered stuff from gl buffer directly to Display form to avoid extra copying. This trick is not fully compatible with morphic, since it ignoring clipping bounds etc. If you want to have full integration with morphic, first turn on "useOwnForm" flag first then viewport will copy rendered pixels into own buffer, which is then can be used for subsequent drawing on morphic canvas. See GLViewportMorph>>drawOn: aCanvas Probably we should add a bounds checking in NBGLDisplay>>updateForm: aForm bounds: aBounds because if you go outside of form's bounds, you have imminent crash due to memory corruption. What can be done, code can be rewritten to take into account a canvas clipping + origin, to get more correct (and safe) copying of rendered pixels, but still avoiding extra copy to intermediate form. Anyways, i don't like the fact that it copying the rendered stuff from video memory back to main memory, and then copying stuff back to video memory (but this time by morphic + VM). But this was a cheap way to get demo working and morphic integration. If i would be making app which using opengl for rendering, i would never copy things like that, because it just a waste of cycles causing a big impact to frame rate. What works for demo, is not really applicable in serious application.  :) In serious app, i'd rather copy morphic Display form into separate texture and then render it along with other  stuff, which is already in video memory. But this approach needs more time investments, which currently i don't have, and actually heavily depends on what you want from your app. Anyways, if there's someone who having spare time to fix NBGLDisplay>>updateForm:bounds: implementation to make it safer, i would appreciate that. -- Best regards, Igor Stasenko.
On Feb 24, 2012, at 4:05 AM, Igor Stasenko wrote:
Anyways, i don't like the fact that it copying the rendered stuff from video memory back to main memory, and then copying stuff back to video memory (but this time by morphic + VM). But this was a cheap way to get demo working and morphic integration.
If i would be making app which using opengl for rendering, i would never copy things like that, because it just a waste of cycles causing a big impact to frame rate. What works for demo, is not really applicable in serious application. :) In serious app, i'd rather copy morphic Display form into separate texture and then render it along with other stuff, which is already in video memory. But this approach needs more time investments, which currently i don't have, and actually heavily depends on what you want from your app.
I think you'd have to ditch the idea of rendering the Display bitmap entirely, if you want to write GL windows to screen directly. Otherwise, you would _never_ get compositing correct, think translucent morphs on top of the GL window for example. As such, you'd need to rewrite the entire compositing window manager using GL buffers, and only as a side-effect flush the rendering results to a Display there for purely backwards-compatability reasons. Cheers, Henry
On 24 February 2012 11:22, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On Feb 24, 2012, at 4:05 AM, Igor Stasenko wrote:
Anyways, i don't like the fact that it copying the rendered stuff from video memory back to main memory, and then copying stuff back to video memory (but this time by morphic + VM). But this was a cheap way to get demo working and morphic integration.
If i would be making app which using opengl for rendering, i would never copy things like that, because it just a waste of cycles causing a big impact to frame rate. What works for demo, is not really applicable in serious application.  :) In serious app, i'd rather copy morphic Display form into separate texture and then render it along with other  stuff, which is already in video memory. But this approach needs more time investments, which currently i don't have, and actually heavily depends on what you want from your app.
I think you'd have to ditch the idea of rendering the Display bitmap entirely, if you want to write GL windows to screen directly. Otherwise, you would _never_ get compositing correct, think translucent morphs on top of the GL window for example.
Yes, but this is for cases if i want to make opengl stuff embedded into morphic world. But if i don't want it, i don't need to care :)
As such, you'd need to rewrite the entire compositing window manager using GL buffers, and only as a side-effect flush the rendering results to a Display there for purely backwards-compatability reasons.
If we would have an easy control of host windows, i.e. a way to create new windows and create GL contexts for them in a way we want. But today's VMs having little for that. What needs to be done first is to make image to be in direct control of host windows, so then we can control GL & Display in a way we want. Because right now, VM doing "magic" with main window by binding Display form to it , and the code which updates it also there, so you simply cannot do any compositing et all , since the code you need to modify is on VM side.
Cheers, Henry
-- Best regards, Igor Stasenko.
On Feb 24, 2012, at 2:04 PM, Igor Stasenko wrote:
On 24 February 2012 11:22, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On Feb 24, 2012, at 4:05 AM, Igor Stasenko wrote:
Anyways, i don't like the fact that it copying the rendered stuff from video memory back to main memory, and then copying stuff back to video memory (but this time by morphic + VM). But this was a cheap way to get demo working and morphic integration.
If i would be making app which using opengl for rendering, i would never copy things like that, because it just a waste of cycles causing a big impact to frame rate. What works for demo, is not really applicable in serious application. :) In serious app, i'd rather copy morphic Display form into separate texture and then render it along with other stuff, which is already in video memory. But this approach needs more time investments, which currently i don't have, and actually heavily depends on what you want from your app.
I think you'd have to ditch the idea of rendering the Display bitmap entirely, if you want to write GL windows to screen directly. Otherwise, you would _never_ get compositing correct, think translucent morphs on top of the GL window for example.
Yes, but this is for cases if i want to make opengl stuff embedded into morphic world. But if i don't want it, i don't need to care :)
As such, you'd need to rewrite the entire compositing window manager using GL buffers, and only as a side-effect flush the rendering results to a Display there for purely backwards-compatability reasons.
If we would have an easy control of host windows, i.e. a way to create new windows and create GL contexts for them in a way we want. But today's VMs having little for that. What needs to be done first is to make image to be in direct control of host windows, so then we can control GL & Display in a way we want. Because right now, VM doing "magic" with main window by binding Display form to it , and the code which updates it also there, so you simply cannot do any compositing et all , since the code you need to modify is on VM side.
Multiple window support is orthogonal to compositing OGL/Morphic correctly through writing a window manager (badly worded, I meant composition manager) for the current way display is handled. You'd theoretically only need two things from the VM to do so; a handle to the context of the current window; and a way to modify the Display that does not automatically trigger a "built-in" redisplay. The compositing in that window could all use VBO/FBO's (bound to said context of course), and display done directly by the (written in smalltalk, using OGL to display) composition manager, sidestepping all VM logic. (well, and ensuring you redraw *after* VM logic triggers automatically, like when window is resized) As long as the Display bitmap is updated accordingly as well, external users shouldn't even be affected. Cheers, Henry
On 24 February 2012 14:26, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On Feb 24, 2012, at 2:04 PM, Igor Stasenko wrote:
On 24 February 2012 11:22, Henrik Johansen <henrik.s.johansen@veloxit.no> wrote:
On Feb 24, 2012, at 4:05 AM, Igor Stasenko wrote:
Anyways, i don't like the fact that it copying the rendered stuff from video memory back to main memory, and then copying stuff back to video memory (but this time by morphic + VM). But this was a cheap way to get demo working and morphic integration.
If i would be making app which using opengl for rendering, i would never copy things like that, because it just a waste of cycles causing a big impact to frame rate. What works for demo, is not really applicable in serious application.  :) In serious app, i'd rather copy morphic Display form into separate texture and then render it along with other  stuff, which is already in video memory. But this approach needs more time investments, which currently i don't have, and actually heavily depends on what you want from your app.
I think you'd have to ditch the idea of rendering the Display bitmap entirely, if you want to write GL windows to screen directly. Otherwise, you would _never_ get compositing correct, think translucent morphs on top of the GL window for example.
Yes, but this is for cases if i want to make opengl stuff embedded into morphic world. But if i don't want it, i don't need to care :)
As such, you'd need to rewrite the entire compositing window manager using GL buffers, and only as a side-effect flush the rendering results to a Display there for purely backwards-compatability reasons.
If we would have an easy control of host windows, i.e. a way to create new windows and create GL contexts for them in a way we want. But today's VMs having little for that. What needs to be done first is to make image to be in direct control of host windows, so then we can control GL & Display in a way we want. Because right now, VM doing "magic" with main window by binding Display form to it , and the code which updates it also there, so you simply cannot do any compositing et all , since the code you need to modify is on VM side.
Multiple window support is orthogonal to compositing OGL/Morphic correctly through writing a window manager (badly worded, I meant composition manager) for the current way display is handled.
Unfortunately, if i would control creation of main window (and hence creation of GL context for it ), then it would be much easier to sidestep all VM functionality and use flicker-free things like swapBuffers, when update to window is required. So, it is not quite orthogonal, because if you look at Mac VMs, its using opengl by its own and it means that it creating own gl context and managing it behind the scenes (see sqSqueakOSXNSView.m in platforms/iOS/vm).
You'd theoretically only need two things from the VM to do so; a handle to the context of the current window; and a way to modify the Display that does not automatically trigger a "built-in" redisplay. The compositing in that window could all use VBO/FBO's (bound to said context of course), and display done directly by the (written in smalltalk, using OGL to display) composition manager, sidestepping all VM logic. (well, and ensuring you redraw *after* VM logic triggers automatically, like when window is resized) As long as the Display bitmap is updated accordingly as well, external users shouldn't even be affected.
what would be really nice is to have callbacks to language side when request to update is received. Then i can decide what to do in order to update the window. But right now i'd rather avoid investing too much effort in "seamless" integration of morphic and GL, because without changing the VM interface the implementation will be cumbersome and will contain many different bells and whistles... The central part of OpenGL game is controlling creation of context and its various parameters. Without such control you often cannot ensure that you will have certain hardware functionality accessible, because depending on the way how you creating a context OS may block it and provide oldish or even software-based renderer for you. -- Best regards, Igor Stasenko.
participants (2)
-
Henrik Johansen -
Igor Stasenko