NBOpenGL
Locked
 
|
Hi Igor, i have a question regarding the design of NBOpenGL.
Why does the following offscreen method, deals with windows? NBOffscreenDisplay >>createOpenGLContext ctx := NBHostWindowContext createSpecificForPlatform. ctx createWindow: extent. ctx createContext: ctx defaultPixelFormat. I'm trying to include in the framework, support for MacOSX, starting with offscreen drawables support using CGL, therefore i would like to modify it to: NBOffscreenDisplay >>createOpenGLContext ctx := NBDisplayContext createSpecificForPlatform. ctx createContext: ctx defaultPixelFormat. NBGLDisplay NBDisplayContext NBOffscreenDisplay NBWindowedDisplay NBWinContext NBUnixContext NBMacOSXContext What do you think? Fernando |
|
|
the formatting of the "uml" is wrong!
On Fri, Dec 9, 2011 at 10:46 AM, [hidden email] <[hidden email]> wrote: > Hi Igor, i have a question regarding the design of NBOpenGL. > > Why does the following offscreen method, deals with windows? > > NBOffscreenDisplay >>createOpenGLContext > ctx := NBHostWindowContext createSpecificForPlatform. > ctx createWindow: extent. > ctx createContext: ctx defaultPixelFormat. > > I'm trying to include in the framework, support for MacOSX, starting > with offscreen drawables support using CGL, therefore i would like to > modify it to: > > > NBOffscreenDisplay >>createOpenGLContext > ctx := NBDisplayContext createSpecificForPlatform. > ctx createContext: ctx defaultPixelFormat. > > > NBGLDisplay > > NBDisplayContext > NBOffscreenDisplay NBWindowedDisplay > NBWinContext NBUnixContext > NBMacOSXContext > > > What do you think? > Fernando > |
|
|
On 09.12.2011 10:56, Fernando Olivero wrote:
> the formatting of the "uml" is wrong! > > On Fri, Dec 9, 2011 at 10:46 AM, [hidden email] > <[hidden email]> wrote: >> Hi Igor, i have a question regarding the design of NBOpenGL. >> >> Why does the following offscreen method, deals with windows? >> >> NBOffscreenDisplay>>createOpenGLContext >> ctx := NBHostWindowContext createSpecificForPlatform. >> ctx createWindow: extent. >> ctx createContext: ctx defaultPixelFormat. >> >> I'm trying to include in the framework, support for MacOSX, starting >> with offscreen drawables support using CGL, therefore i would like to >> modify it to: >> >> >> NBOffscreenDisplay>>createOpenGLContext >> ctx := NBDisplayContext createSpecificForPlatform. >> ctx createContext: ctx defaultPixelFormat. >> >> >> NBGLDisplay >> >> NBDisplayContext >> NBOffscreenDisplay NBWindowedDisplay >> NBWinContext NBUnixContext >> NBMacOSXContext >> >> >> What do you think? >> Fernando >> contexts for exisiting windows, so you have to make a new window (and destroy it after if you don't intend to use it), just to get a new context with different capabilities. That's not specific to offscreen rendering contexts though, (nor pixelformats, another windows artifact) but creating contexts on windows, so it probably could/should/must be refactored when moving to multi-platform. TLDR; You'd break it on windows just removing that line. Cheers, Henry |
|
|
In reply to this post by Fernando olivero-2
On 09.12.2011 11:27, Henrik Sperre Johansen wrote:
> > That's not specific to offscreen rendering contexts though, (nor > pixelformats, another windows artifact) I should perhaps say; they're not Windows specific as such, but the implementation in NBOpenGL is. Personally, I'd rather have createContext: taking a crossplatform pixel/buffer format as argument, the platform context transcribe that into the native object needed as parameter for context creation, and some sort of way to check if the context created actually matched your specification. Makes the whole "Your context was invalid for those operations" class of errors a lot more transparent, which I've found to be the source of trouble multiple times at least. Cheers, Henry |
|
|
(resending message due to mailer problem)
Since it works now only for Windows, i didn't thought a lot about platform-neutral stuff. Creating and initializing an opengl context is platform-specific, and it is hard to tell what you may need to create it. Regarding opengl on mac: - i just uploaded the initial snapshot of opengl bindings for mac, see NBOpenGL-Mac package. it can create a context using NBMacContextManager new createContext but i am a bit puzzled what to do next, because it looks like CGL library allows you to create only a fullscreen contexts, and only Carbon/Cocoa frameworks allowing you to make a windowed context by attaching context to specific 'drawable'. So, Fernando (or others), if you know more, take a look what can be done. Maybe it was a mistake to use CGL interface for it, maybe i should write bindings using Carbon interface, but since it promised by apple to be deprecated and removed from system, i don't know what to do (and Cocoa is an Objective-C, and making calls to Objective-C code is completely different story). On 9 December 2011 11:34, Henrik Sperre Johansen <[hidden email]> wrote: > On 09.12.2011 11:27, Henrik Sperre Johansen wrote: >> >> >> That's not specific to offscreen rendering contexts though, (nor >> pixelformats, another windows artifact) > > I should perhaps say; they're not Windows specific as such, but the > implementation in NBOpenGL is. > Personally, I'd rather have createContext: taking a crossplatform > pixel/buffer format as argument, the platform context transcribe that into > the native object needed as parameter for context creation, and some sort of > way to check if the context created actually matched your specification. > Makes the whole "Your context was invalid for those operations" class of > errors a lot more transparent, which I've found to be the source of trouble > multiple times at least. > > Cheers, > Henry > -- Best regards, Igor Stasenko. |
|
|
In reply to this post by Henrik Sperre Johansen
Thanks Henrik for the info, now's its clear to me.
Igor, excellent news! i was struggling with NativeBoost, almost have a working version of CGL, but i'm eager to see your implementation. Yes, CGL only provide either fullscreen of offscreen contexts. Cocoa (and Carbon) adds the windowing layer on top of CGL. I'll analyze how to overcome this problem now, cause i want to start rendering with Cairo ASAP! Fernando On Fri, Dec 9, 2011 at 3:06 PM, Igor Stasenko <[hidden email]> wrote: > (resending message due to mailer problem) > > Since it works now only for Windows, i didn't thought a lot about > platform-neutral stuff. > Creating and initializing an opengl context is platform-specific, and > it is hard to tell what you may need to create it. > > Regarding opengl on mac: > - i just uploaded the initial snapshot of opengl bindings for mac, see > NBOpenGL-Mac package. > it can create a context using > NBMacContextManager new createContext > > but i am a bit puzzled what to do next, because it looks like CGL > library allows you to create only a fullscreen contexts, > and only Carbon/Cocoa frameworks allowing you to make a windowed > context by attaching context to specific 'drawable'. > So, Fernando (or others), if you know more, take a look what can be done. > Maybe it was a mistake to use CGL interface for it, maybe i should > write bindings using Carbon interface, but > since it promised by apple to be deprecated and removed from system, i > don't know what to do (and Cocoa is an Objective-C, > and making calls to Objective-C code is completely different story). > > On 9 December 2011 11:34, Henrik Sperre Johansen > <[hidden email]> wrote: >> On 09.12.2011 11:27, Henrik Sperre Johansen wrote: >>> >>> >>> That's not specific to offscreen rendering contexts though, (nor >>> pixelformats, another windows artifact) >> >> I should perhaps say; they're not Windows specific as such, but the >> implementation in NBOpenGL is. >> Personally, I'd rather have createContext: taking a crossplatform >> pixel/buffer format as argument, the platform context transcribe that into >> the native object needed as parameter for context creation, and some sort of >> way to check if the context created actually matched your specification. >> Makes the whole "Your context was invalid for those operations" class of >> errors a lot more transparent, which I've found to be the source of trouble >> multiple times at least. >> >> Cheers, >> Henry >> > > > > -- > Best regards, > Igor Stasenko. > |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |