Administrator
|
On Monday, February 28, 2011 06:55:36 Sven Gothel wrote:
> Native SWT Binding Test > > Hi all .. a 1st experimental demo for a native SWT / JOGL binding > working on Linux and Windows, both 32 and 64bit. > > --- > > New GLDrawableFactory createProxySurface(..) method > http://jogamp.org/git/?p=jogl.git;a=commit;h=254052b54cebdb957d83e46e377534ef263d6029 > > Pimp up SWTAccessor for our needs: > http://jogamp.org/git/?p=jogl.git;a=commit;h=f9ae06b4df8daa5e780e392543cb06cb9a6293c9 > http://jogamp.org/git/?p=jogl.git;a=commit;h=e0b2133b1dafef6750885d53fe85e2bc9530c2c9 > > The new native test case/impl: > http://jogamp.org/git/?p=jogl.git;a=commit;h=10ea39d665f0cb50204d1965a0739ca15119e86f > > --- > Works with OSX/Cocoa as well now: http://jogamp.org/git/?p=jogl.git;a=commit;h=83570ff52f67d8f0f7fe978e178bf7825041bee3 http://jogamp.org/git/?p=jogl.git;a=commit;h=c1e542ad0150e5327b1ed9d9980d4eeb81720cde > Now we can see how to make a nice integration, > ie using NEWT or keep it special in the SWT realm. IMHO the best control and least code would be to implement analog to NewtCanvasAWT a NewtCanvasSWT. All it needs is to gather the native handles (done), and use the existing NEWT native window parenting. We may also need to fwd a few SWT UI events to NEWT via SWT listener. > > Cheers, Sven > > -- health & wealth mailto:[hidden email] ; http://jausoft.com land : +49 (471) 4707742 ; cell: +49 (151) 28145941 Timezone CET: PST+9, EST+6, UTC+1 |
Administrator
|
I know this is just an experimental demo, but I'm a little scared looking at it Does this mean that createExternalGLContext() won't get its last few bugs fixed, so this would be the only supported method of using JOGL 2 in SWT?
On the good side, this would give SWT a GL 3+ context on Windows and Linux (and eventually Mac, once Apple upgrades their GL support). I guess there's no alternative to using reflection, since we can't extend the SWT classes directly (because they're platform-specific and we're not). But is it possible for the ProxySurface to automatically track the size and position of the Composite? It would be nice if I could just write this: GLContext glcontext = factory.createExternalContext(swtcanvas, caps); without having the ProxySurface and GLDrawable be visible (since they shouldn't get used in an SWT app anyway). |
Administrator
|
Hmm, the more I think about this new method, the more I like it, assuming the use case can be made simple enough
It could provide a clear motivation for engineering/scientific SWT users to switch to JOGL 2, since it would fix the lack of multisampling on Windows (I think engineering/scientific users probably care more about multisampling than they do about a GL 3/4 context). |
Administrator
|
In reply to this post by Sven Gothel
Would such an integration use a NEWT canvas or SWT OpenGL Canvas? I prefer the first option.
Julien Gouesse | Personal blog | Website
|
Administrator
|
In reply to this post by Wade Walker
On Tuesday, March 01, 2011 04:09:10 Wade Walker [via jogamp] wrote:
> > I know this is just an experimental demo, but I'm a little scared looking at > it Does this mean that createExternalGLContext() won't get its last few > bugs fixed, so this would be the only supported method of using JOGL 2 in > SWT? No. We need the external stuff for other things as well :) Let's talk about this bug (SWT related IMHO) in a diff thread. > > On the good side, this would give SWT a GL 3+ context on Windows and Linux > (and eventually Mac, once Apple upgrades their GL support). > I guess there's > no alternative to using reflection, since we can't extend the SWT classes > directly (because they're platform-specific and we're not). Yes, we need this hack :) > But is it > possible for the ProxySurface to automatically track the size and position > of the Composite? It would be nice if I could just write this: > > GLContext glcontext = factory.createExternalContext(swtcanvas, caps); > > without having the ProxySurface and GLDrawable be visible (since they > shouldn't get used in an SWT app anyway). This demos 'just' shows that you can do something with the native handles and we got 'em right. This is not yet enough for an SWT binding, since on some platforms (X11/GTK) the native pixel format (FBConfigID ..) is already chosen. We would need the same procedure as for NewtCanvasAWT, - get the native SWT handle - create our own child window to the native SWT one, using our pixelformat selection. - maybe fwd a few native/SWT events Then we have it well integrated. > > On Tuesday, March 01, 2011 04:53:48 Wade Walker [via jogamp] wrote: > > Hmm, the more I think about this new method, the more I like it, assuming the > use case can be made simple enough > > It could provide a clear motivation for engineering/scientific SWT users to > switch to JOGL 2, since it would fix the lack of multisampling on Windows (I > think engineering/scientific users probably care more about multisampling > than they do about a GL 3/4 context). Sure, any GL profile, even on mobile platform, and pixelformat. ~Sven > |
Administrator
|
I created an enhancement request for the SWT GLCanvas at https://jogamp.org/bugzilla/show_bug.cgi?id=484 so we can track this and so people can be CCed on progress.
|
Free forum by Nabble | Edit this page |