On Feb 24, 2012, at 2:04 PM, Igor Stasenko wrote: > On 24 February 2012 11:22, Henrik Johansen <[email protected]> > 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
