[cross-posting this reply because it certainly seems relevant to both
Pharo and Squeak] This seems to me to be roundabout, and will make sure that any Mac version of OpenGL will be far slower than any Windows version. What I'm not understanding is how the current OpenGL libs can render directly on the screen on a Mac, while the Igor's can't. The Croquet OpenGL package appears to be grabbing something from the Baloon3D plugin, I think. Has anyone looked at how THAT tells OpenGL libs to render to the appropriate area on the system window? primCreateRenderer: flags x: x y: y w: w h: h <primitive: 'primitiveCreateRendererFlags' module:'B3DAcceleratorPlugin'> ^nil L On 1/11/12 1:22 AM, Fernando Olivero wrote: > I've developed a CocoaUI app, which implements the example you copied. > A cocoa window, with a custom NSView, which renders an OpenGL surface. > The app also catches events, and notifies it via sockets. > > My idea is to render within Pharo to a frame buffer object(offscreen > rendering), and communicate the redisplay to the cocoa app via sockets > (IPC). > > So we can code all the UI in Smalltalk, using offscreen rendering as a > means to draw to a native OS X window. > > I will continue experimenting with this approach, to assess its > performance and usability. Wether IPC via sockets is fast enough, > amongst other technical challenges. > > Yes, i noticed two that the OpenGL info in the Mac, returns 'APPLE > SOFTWARE RENDERER 2.1". Surely we can find a way to solve this > problem, i will look into Lawson's link. > > Fernando > pd: Enjoy the vacations Igor, have a pint or two. > > On Wed, Jan 11, 2012 at 1:21 AM, Igor Stasenko<[hidden email]> wrote: >> On 10 January 2012 21:28, Stéphane Ducasse<[hidden email]> wrote: >>> thanks >>> >>> May be this page is interesting: <a href="http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8">http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8 >>> >>> Igor how is london :) ? >>> >>> Crowded? >> like hell. :) >> Kiev is more or less same in this regard, so i already having immunity >> >> Yes, i will definitely get back to this issue, once i return from vacation. >> And now i should stop reading and replying mails and spend time on >> just resting :) >> >> -- >> Best regards, >> Igor Stasenko. >> > |
On 11.01.2012, at 18:34, Lawson English wrote: > [cross-posting this reply because it certainly seems relevant to both Pharo and Squeak] > > > This seems to me to be roundabout, and will make sure that any Mac version of OpenGL will be far slower than any Windows version. > > What I'm not understanding is how the current OpenGL libs can render directly on the screen on a Mac, while the Igor's can't. The Croquet OpenGL package appears to be grabbing something from the Baloon3D plugin, I think. Has anyone looked at how THAT tells OpenGL libs to render to the appropriate area on the system window? > > primCreateRenderer: flags x: x y: y w: w h: h > <primitive: 'primitiveCreateRendererFlags' module:'B3DAcceleratorPlugin'> > ^nil > L This primitive encapsulates the platform-dependent part of creating an OpenGL rendering context. OpenGL itself is platform-independent, but creating a window is not. The plugin has code for Mac, Windows, and Unix. So this creates a new borderless window that gets embedded in the "big" main window. It also creates an OpenGL context for that window and makes it current. After calling the primitive you can use any OpenGL commands to draw directly into it using the hardware renderer. I don't see a good reason why you would not want to use it. - Bert - > On 1/11/12 1:22 AM, Fernando Olivero wrote: >> I've developed a CocoaUI app, which implements the example you copied. >> A cocoa window, with a custom NSView, which renders an OpenGL surface. >> The app also catches events, and notifies it via sockets. >> >> My idea is to render within Pharo to a frame buffer object(offscreen >> rendering), and communicate the redisplay to the cocoa app via sockets >> (IPC). >> >> So we can code all the UI in Smalltalk, using offscreen rendering as a >> means to draw to a native OS X window. >> >> I will continue experimenting with this approach, to assess its >> performance and usability. Wether IPC via sockets is fast enough, >> amongst other technical challenges. >> >> Yes, i noticed two that the OpenGL info in the Mac, returns 'APPLE >> SOFTWARE RENDERER 2.1". Surely we can find a way to solve this >> problem, i will look into Lawson's link. >> >> Fernando >> pd: Enjoy the vacations Igor, have a pint or two. >> >> On Wed, Jan 11, 2012 at 1:21 AM, Igor Stasenko<[hidden email]> wrote: >>> On 10 January 2012 21:28, Stéphane Ducasse<[hidden email]> wrote: >>>> thanks >>>> >>>> May be this page is interesting: <a href="http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8">http://developer.apple.com/library/mac/#documentation/GraphicsImaging/Conceptual/OpenGL-MacProgGuide/opengl_drawing/opengl_drawing.html#//apple_ref/doc/uid/TP40001987-CH404-SW8 >>>> >>>> Igor how is london :) ? >>>> >>>> Crowded? >>> like hell. :) >>> Kiev is more or less same in this regard, so i already having immunity >>> >>> Yes, i will definitely get back to this issue, once i return from vacation. >>> And now i should stop reading and replying mails and spend time on >>> just resting :) >>> >>> -- >>> Best regards, >>> Igor Stasenko. |
Am 11.01.2012 19:18, schrieb Bert Freudenberg:
> ... > This primitive encapsulates the platform-dependent part of creating an OpenGL rendering context. OpenGL itself is platform-independent, but creating a window is not. The plugin has code for Mac, Windows, and Unix. > > So this creates a new borderless window that gets embedded in the "big" main window. It also creates an OpenGL context for that window and makes it current. After calling the primitive you can use any OpenGL commands to draw directly into it using the hardware renderer. I don't see a good reason why you would not want to use it. > > - Bert - > I'm currently also experimenting with this (under Linux) and it looks like this does not fully work on my system - the OpenGL output seems to be displayed for a very short moment, and then only teh Squeak desktop is visible again. Of course, it's nice to have the platform-dependent part within the primitive, but at least for Windows and Linux/X11 creating an OpenGL context is not really difficult, so since we already have platform-dependent OpenGL subclasses anyway, there is no strong reason to keep the context creation stuff in primitive code. Cheers, Hans-Martin |
In reply to this post by LawsonEnglish
[squeak dev added back in]
Even so, i think there's a very windows-centric thing going on that need not exist. might be wrong of course. L On 1/11/12 11:01 AM, ncalexan wrote: On Wed, Jan 11, 2012 at 9:34 AM, Lawson English-2 [via Smalltalk] |
In reply to this post by Hans-Martin Mosner
[pharo list added back in]
WOuld it be best to have a VM primitive that actually gives this info in a cross-platform way since it is going to be more and more useful as time goes on? On 1/11/12 11:56 AM, Hans-Martin Mosner wrote: > > I'm currently also experimenting with this (under Linux) and it looks like this does not fully work on my system - the > OpenGL output seems to be displayed for a very short moment, and then only teh Squeak desktop is visible again. > Of course, it's nice to have the platform-dependent part within the primitive, but at least for Windows and Linux/X11 > creating an OpenGL context is not really difficult, so since we already have platform-dependent OpenGL subclasses > anyway, there is no strong reason to keep the context creation stuff in primitive code. > > Cheers, > Hans-Martin > > |
In reply to this post by Hans-Martin Mosner
[pharo list added back in for real this time]
Would it be best to have a VM primitive that actually gives this info in a cross-platform way since it is going to be more and more useful as time goes on? On 1/11/12 11:56 AM, Hans-Martin Mosner wrote: > Am 11.01.2012 19:18, schrieb Bert Freudenberg: >> ... >> This primitive encapsulates the platform-dependent part of creating an OpenGL rendering context. OpenGL itself is platform-independent, but creating a window is not. The plugin has code for Mac, Windows, and Unix. >> >> So this creates a new borderless window that gets embedded in the "big" main window. It also creates an OpenGL context for that window and makes it current. After calling the primitive you can use any OpenGL commands to draw directly into it using the hardware renderer. I don't see a good reason why you would not want to use it. >> >> - Bert - >> > I'm currently also experimenting with this (under Linux) and it looks like this does not fully work on my system - the > OpenGL output seems to be displayed for a very short moment, and then only teh Squeak desktop is visible again. > Of course, it's nice to have the platform-dependent part within the primitive, but at least for Windows and Linux/X11 > creating an OpenGL context is not really difficult, so since we already have platform-dependent OpenGL subclasses > anyway, there is no strong reason to keep the context creation stuff in primitive code. > > Cheers, > Hans-Martin > > |
On 11 January 2012 20:10, Lawson English <[hidden email]> wrote:
> [pharo list added back in for real this time] > > Would it be best to have a VM primitive that actually gives this info in a > cross-platform way since it is going to be more and more useful as time goes > on? > one big issue with such primitive is lack of options which i able to contol for context i creating. As you may know there's a lot of different options , like - depth buffer bits, color buffer bits, alpha bits number of back buffers, subpixel antialiazing, auxuliarry buffers etc as i said before in other posts.. it is really hard to create a primitive which will allow you to control all those options, especially a cross-platform one. I know that for most users you could take 1 pixel format, 1 back buffer and you free to go, but it just doesn't feels right to me, why we should lose all the variety of control and put constrains at context creation stage. That's why i striving for controlling context creation at image side, and if that requires writing a platform-specific code in image, so be it. But then i could make sure that you could access all OpenGL capabilities similar to C/C++ code, without limitations. For beginners, these options may mean nothing, but for those who dealing with OpenGL at more advanced levels, trust me, they simply cannot live without it. Many advanced opengl examples and rendering techniques requiring fine control on context creation. > On 1/11/12 11:56 AM, Hans-Martin Mosner wrote: >> >> Am 11.01.2012 19:18, schrieb Bert Freudenberg: >>> >>> ... >>> This primitive encapsulates the platform-dependent part of creating an >>> OpenGL rendering context. OpenGL itself is platform-independent, but >>> creating a window is not. The plugin has code for Mac, Windows, and Unix. >>> >>> So this creates a new borderless window that gets embedded in the "big" >>> main window. It also creates an OpenGL context for that window and makes it >>> current. After calling the primitive you can use any OpenGL commands to draw >>> directly into it using the hardware renderer. I don't see a good reason why >>> you would not want to use it. >>> >>> - Bert - >>> >> I'm currently also experimenting with this (under Linux) and it looks like >> this does not fully work on my system - the >> OpenGL output seems to be displayed for a very short moment, and then only >> teh Squeak desktop is visible again. >> Of course, it's nice to have the platform-dependent part within the >> primitive, but at least for Windows and Linux/X11 >> creating an OpenGL context is not really difficult, so since we already >> have platform-dependent OpenGL subclasses >> anyway, there is no strong reason to keep the context creation stuff in >> primitive code. >> >> Cheers, >> Hans-Martin >> >> > > -- Best regards, Igor Stasenko. |
On 1/11/12 3:54 PM, ncalexan wrote: On Wed, Jan 11, 2012 at 2:40 PM, Igor Stasenko [via Smalltalk] I guess it depends on your definition of primitive and just what it can do. L. |
In reply to this post by Igor Stasenko
There's bound to be a way. Perhaps an array of requests, followed by an
array of responses, that can be normalized in a cross-platform way? The fact that the responses might be platform specific doesn't matter as long as they are consistent within the platform, right? You just need 2-way glue: 1 way to create the query and the other to put the query in a cross-platform format that can be used by the rest of the system. L. On 1/11/12 3:39 PM, Igor Stasenko wrote: > On 11 January 2012 20:10, Lawson English<[hidden email]> wrote: >> [pharo list added back in for real this time] >> >> Would it be best to have a VM primitive that actually gives this info in a >> cross-platform way since it is going to be more and more useful as time goes >> on? >> > one big issue with such primitive is lack of options which i able to > contol for context i creating. > As you may know there's a lot of different options , like > - depth buffer bits, color buffer bits, alpha bits number of back > buffers, subpixel antialiazing, > auxuliarry buffers etc > > as i said before in other posts.. it is really hard to create a > primitive which will allow > you to control all those options, especially a cross-platform one. > > I know that for most users you could take 1 pixel format, 1 back > buffer and you free to go, > but it just doesn't feels right to me, why we should lose all the > variety of control and put constrains at context creation stage. > That's why i striving for controlling context creation at image side, > and if that requires writing a platform-specific code > in image, so be it. But then i could make sure that you could access > all OpenGL capabilities similar to C/C++ code, > without limitations. > For beginners, these options may mean nothing, but for those who > dealing with OpenGL at more advanced levels, trust me, > they simply cannot live without it. Many advanced opengl examples and > rendering techniques requiring fine control on context creation. > > > >> On 1/11/12 11:56 AM, Hans-Martin Mosner wrote: >>> Am 11.01.2012 19:18, schrieb Bert Freudenberg: >>>> ... >>>> This primitive encapsulates the platform-dependent part of creating an >>>> OpenGL rendering context. OpenGL itself is platform-independent, but >>>> creating a window is not. The plugin has code for Mac, Windows, and Unix. >>>> >>>> So this creates a new borderless window that gets embedded in the "big" >>>> main window. It also creates an OpenGL context for that window and makes it >>>> current. After calling the primitive you can use any OpenGL commands to draw >>>> directly into it using the hardware renderer. I don't see a good reason why >>>> you would not want to use it. >>>> >>>> - Bert - >>>> >>> I'm currently also experimenting with this (under Linux) and it looks like >>> this does not fully work on my system - the >>> OpenGL output seems to be displayed for a very short moment, and then only >>> teh Squeak desktop is visible again. >>> Of course, it's nice to have the platform-dependent part within the >>> primitive, but at least for Windows and Linux/X11 >>> creating an OpenGL context is not really difficult, so since we already >>> have platform-dependent OpenGL subclasses >>> anyway, there is no strong reason to keep the context creation stuff in >>> primitive code. >>> >>> Cheers, >>> Hans-Martin >>> >>> >> > > |
http://www.youtube.com/watch?v=F5GHRaIwCS4
nowhere near where it could be. With NBOpenGL and GLDisplay, things would be much snappier and easier. Of course, at this point, we need to start discussing how to integrate OpenGL errors into the squeak debugging system so that the IDE remains stable... L. On 1/13/12 10:29 AM, Lawson English wrote: > There's bound to be a way. Perhaps an array of requests, followed by > an array of responses, that can be normalized in a cross-platform way? > > The fact that the responses might be platform specific doesn't matter > as long as they are consistent within the platform, right? > You just need 2-way glue: 1 way to create the query and the other to > put the query in a cross-platform format that can be used by the rest > of the system. > > L. > > On 1/11/12 3:39 PM, Igor Stasenko wrote: >> On 11 January 2012 20:10, Lawson English<[hidden email]> wrote: >>> [pharo list added back in for real this time] >>> >>> Would it be best to have a VM primitive that actually gives this >>> info in a >>> cross-platform way since it is going to be more and more useful as >>> time goes >>> on? >>> >> one big issue with such primitive is lack of options which i able to >> contol for context i creating. >> As you may know there's a lot of different options , like >> - depth buffer bits, color buffer bits, alpha bits number of back >> buffers, subpixel antialiazing, >> auxuliarry buffers etc >> >> as i said before in other posts.. it is really hard to create a >> primitive which will allow >> you to control all those options, especially a cross-platform one. >> >> I know that for most users you could take 1 pixel format, 1 back >> buffer and you free to go, >> but it just doesn't feels right to me, why we should lose all the >> variety of control and put constrains at context creation stage. >> That's why i striving for controlling context creation at image side, >> and if that requires writing a platform-specific code >> in image, so be it. But then i could make sure that you could access >> all OpenGL capabilities similar to C/C++ code, >> without limitations. >> For beginners, these options may mean nothing, but for those who >> dealing with OpenGL at more advanced levels, trust me, >> they simply cannot live without it. Many advanced opengl examples and >> rendering techniques requiring fine control on context creation. >> >> >> >>> On 1/11/12 11:56 AM, Hans-Martin Mosner wrote: >>>> Am 11.01.2012 19:18, schrieb Bert Freudenberg: >>>>> ... >>>>> This primitive encapsulates the platform-dependent part of >>>>> creating an >>>>> OpenGL rendering context. OpenGL itself is platform-independent, but >>>>> creating a window is not. The plugin has code for Mac, Windows, >>>>> and Unix. >>>>> >>>>> So this creates a new borderless window that gets embedded in the >>>>> "big" >>>>> main window. It also creates an OpenGL context for that window and >>>>> makes it >>>>> current. After calling the primitive you can use any OpenGL >>>>> commands to draw >>>>> directly into it using the hardware renderer. I don't see a good >>>>> reason why >>>>> you would not want to use it. >>>>> >>>>> - Bert - >>>>> >>>> I'm currently also experimenting with this (under Linux) and it >>>> looks like >>>> this does not fully work on my system - the >>>> OpenGL output seems to be displayed for a very short moment, and >>>> then only >>>> teh Squeak desktop is visible again. >>>> Of course, it's nice to have the platform-dependent part within the >>>> primitive, but at least for Windows and Linux/X11 >>>> creating an OpenGL context is not really difficult, so since we >>>> already >>>> have platform-dependent OpenGL subclasses >>>> anyway, there is no strong reason to keep the context creation >>>> stuff in >>>> primitive code. >>>> >>>> Cheers, >>>> Hans-Martin >>>> >>>> >>> >> >> > > > |
On 14 January 2012 07:12, Lawson English <[hidden email]> wrote:
> http://www.youtube.com/watch?v=F5GHRaIwCS4 > > nowhere near where it could be. With NBOpenGL and GLDisplay, things would be > much snappier and easier. Of course, at this point, we need to start > discussing how to integrate OpenGL errors into the squeak debugging system > so that the IDE remains stable... > well, one of the ideas is to use fallback display in case of openGL error(s). And render not to GL context but to bitmap. Then you can actually use debugger to debug GL calls step by step without interfering with GL stack/state. Another approach would be to create a separate GL context and use it for debugger. But then you need to keep an eye for switching active contexts at right moment. > L. > -- Best regards, Igor Stasenko. |
Sounds good.
BTW, the trend of popularity continues. This latest video http://www.youtube.com/watch?v=F5GHRaIwCS4 has had 45 views since I put it up yesterday and the first video on that topic is now at 145 views (my most popular video took 2 months to get that many views). Once you get NBOpenGL and GLDisplay cross-platform, I suspect there will be a rather large number of OpenGL programmers testing how it works. Games, GUI testing, algorithmic and other technical visualization. Cobalt/Croquet integration, etc. Lots of potential here. L. On 1/14/12 7:22 AM, Igor Stasenko wrote: > On 14 January 2012 07:12, Lawson English<[hidden email]> wrote: >> http://www.youtube.com/watch?v=F5GHRaIwCS4 >> >> nowhere near where it could be. With NBOpenGL and GLDisplay, things would be >> much snappier and easier. Of course, at this point, we need to start >> discussing how to integrate OpenGL errors into the squeak debugging system >> so that the IDE remains stable... >> > well, one of the ideas is to use fallback display in case of openGL error(s). > And render not to GL context but to bitmap. Then you can actually use > debugger to debug GL calls step by step > without interfering with GL stack/state. > Another approach would be to create a separate GL context and use it > for debugger. But then you need to keep an eye > for switching active contexts at right moment. > >> L. >> |
On 14 January 2012 20:14, Lawson English <[hidden email]> wrote:
> Sounds good. > > BTW, the trend of popularity continues. This latest video > http://www.youtube.com/watch?v=F5GHRaIwCS4 has had 45 views since I put it > up yesterday and the first video on that topic is now at 145 views (my most > popular video took 2 months to get that many views). Once you get NBOpenGL > and GLDisplay cross-platform, I suspect there will be a rather large number > of OpenGL programmers testing how it works. > I know that graphics attracts a lot of people. A good (and working) graphics solution attracts even more brave and adventurous souls. Been there, swam there a lot :) > Games, GUI testing, algorithmic and other technical visualization. > Cobalt/Croquet integration, etc. Lots of potential here. > > > L. > > > On 1/14/12 7:22 AM, Igor Stasenko wrote: >> >> On 14 January 2012 07:12, Lawson English<[hidden email]> wrote: >>> >>> http://www.youtube.com/watch?v=F5GHRaIwCS4 >>> >>> nowhere near where it could be. With NBOpenGL and GLDisplay, things would >>> be >>> much snappier and easier. Of course, at this point, we need to start >>> discussing how to integrate OpenGL errors into the squeak debugging >>> system >>> so that the IDE remains stable... >>> >> well, one of the ideas is to use fallback display in case of openGL >> error(s). >> And render not to GL context but to bitmap. Then you can actually use >> debugger to debug GL calls step by step >> without interfering with GL stack/state. >> Another approach would be to create a separate GL context and use it >> for debugger. But then you need to keep an eye >> for switching active contexts at right moment. >> >>> L. >>> > > -- Best regards, Igor Stasenko. |
The latest video in the saga: http://www.youtube.com/watch?v=TsJmBwi9lDY
BTW, the video I mentioned a day or so ago now has 90 views, in only 3 days. People who want to promote squeak/pharo/seaside/etc to the world at large should take note. L. On 1/14/12 12:20 PM, Igor Stasenko wrote: > [...] >>> well, one of the ideas is to use fallback display in case of openGL >>> error(s). >>> And render not to GL context but to bitmap. Then you can actually use >>> debugger to debug GL calls step by step >>> without interfering with GL stack/state. >>> Another approach would be to create a separate GL context and use it >>> for debugger. But then you need to keep an eye >>> for switching active contexts at right moment. >>> >>>> L. >>>> >> > > |
That is really Igor's job, not mine. I'm just throwing together stuff
using the original Croquet OpenGL calls and making videos of what I'm doing. L. On 1/17/12 10:31 AM, Alexandre Bergel wrote: > Keep going. I would love to have opengl well integrated. > > Alexandre > > > > On 16 Jan 2012, at 23:44, Lawson English wrote: > >> The latest video in the saga: http://www.youtube.com/watch?v=TsJmBwi9lDY >> >> BTW, the video I mentioned a day or so ago now has 90 views, in only 3 days. >> >> People who want to promote squeak/pharo/seaside/etc to the world at large should take note. >> >> L. >> >> >> >> >> On 1/14/12 12:20 PM, Igor Stasenko wrote: >>> [...] >>>>> well, one of the ideas is to use fallback display in case of openGL >>>>> error(s). >>>>> And render not to GL context but to bitmap. Then you can actually use >>>>> debugger to debug GL calls step by step >>>>> without interfering with GL stack/state. >>>>> Another approach would be to create a separate GL context and use it >>>>> for debugger. But then you need to keep an eye >>>>> for switching active contexts at right moment. >>>>> >>>>>> L. >>>>>> >>> >> |
In reply to this post by LawsonEnglish
sigh, I'm getting disk access constantly when my little GUI opengl
thingie runs. The max FPS is 10ish. Package is: OpenGL-Tutorial-LDE.32 in monticello repository: 'http://croquet-src-01.oit.duke.edu:8886/Contributions' suggestions? Thanks. L. |
Apparently there was a glError that I wasn't catching, so the disk
address issue has gone away: the Baloon3D plugin was logging errors I didn't catch. However, I'm not sure how to efficiently blit GUI updates to the gl texture, so suggestions appreciated. Looking at the Squeak3D.log file, it seems to me that Baloon3D already has access to all the values that Igor is using to setup his NBOpenGL and GLCanvas packages. Would it be better to leverage that as a cross-platform initialization for OpenGL instead of another plugin? From Squeak3D log: ### Attempting to find hardware renderer x: 0 y: 0 w: 638 h: 475 Selected pixel format: AGL_RENDERER_ID : 0x1021A02 AGL_OFFSCREEN : GL_FALSE AGL_FULLSCREEN : GL_FALSE AGL_WINDOW : GL_TRUE AGL_ACCELERATED : GL_TRUE AGL_ROBUST : GL_FALSE AGL_BACKING_STORE : GL_FALSE AGL_MP_SAFE : GL_TRUE AGL_COMPLIANT : GL_TRUE AGL_MULTISCREEN : GL_TRUE AGL_BUFFER_SIZE : 32 AGL_LEVEL : 0 AGL_PIXEL_SIZE : 32 AGL_DEPTH_SIZE : 24 AGL_STENCIL_SIZE : 8 AGL_3_BIT AGL_AUX_BUFFERS : 0 OpenGL vendor: ATI Technologies Inc. OpenGL renderer: ATI Radeon HD 2600 OpenGL Engine OpenGL version: 2.1 ATI-1.6.36 OpenGL extensions: GL_ARB_transpose_matrix GL_ARB_vertex_program GL_ARB_vertex_blend GL_ARB_window_pos GL_ARB_shader_objects GL_ARB_vertex_shader GL_ARB_shading_language_100 GL_EXT_multi_draw_arrays GL_EXT_clip_volume_hint GL_EXT_rescale_normal GL_EXT_draw_range_elements GL_EXT_fog_coord GL_EXT_gpu_program_parameters GL_EXT_geometry_shader4 GL_EXT_transform_feedback GL_APPLE_client_storage GL_APPLE_specular_vector GL_APPLE_transform_hint GL_APPLE_packed_pixels GL_APPLE_fence GL_APPLE_vertex_array_object GL_APPLE_vertex_program_evaluators GL_APPLE_element_array GL_APPLE_flush_render GL_APPLE_aux_depth_stencil GL_NV_texgen_reflection GL_NV_light_max_exponent GL_IBM_rasterpos_clip GL_SGIS_generate_mipmap GL_ARB_imaging GL_ARB_point_parameters GL_ARB_texture_env_crossbar GL_ARB_texture_border_clamp GL_ARB_multitexture GL_ARB_texture_env_add GL_ARB_texture_cube_map GL_ARB_texture_env_dot3 GL_ARB_multisample GL_ARB_texture_env_combine GL_ARB_texture_compression GL_ARB_texture_mirrored_repeat GL_ARB_shadow GL_ARB_depth_texture GL_ARB_shadow_ambient GL_ARB_fragment_program GL_ARB_fragment_program_shadow GL_ARB_fragment_shader GL_ARB_occlusion_query GL_ARB_point_sprite GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object GL_ARB_pixel_buffer_object GL_ARB_draw_buffers GL_ARB_shader_texture_lod GL_ARB_color_buffer_float GL_ARB_half_float_vertex GL_ARB_texture_rg GL_ARB_texture_compression_rgtc GL_ARB_framebuffer_object GL_EXT_compiled_vertex_array GL_EXT_draw_buffers2 GL_EXT_framebuffer_object GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample GL_EXT_texture_rectangle GL_ARB_texture_rectangle GL_EXT_texture_env_add GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract GL_EXT_texture_lod_bias GL_EXT_abgr GL_EXT_bgra GL_EXT_stencil_wrap GL_EXT_texture_filter_anisotropic GL_EXT_separate_specular_color GL_EXT_secondary_color GL_EXT_blend_func_separate GL_EXT_shadow_funcs GL_EXT_stencil_two_side GL_EXT_texture_compression_s3tc GL_EXT_texture_compression_dxt1 GL_EXT_texture_sRGB GL_EXT_blend_equation_separate GL_EXT_texture_mirror_clamp GL_EXT_packed_depth_stencil GL_EXT_bindable_uniform GL_EXT_texture_integer GL_EXT_gpu_shader4 GL_EXT_framebuffer_sRGB GL_EXT_provoking_vertex GL_APPLE_flush_buffer_range GL_APPLE_ycbcr_422 GL_APPLE_rgb_422 GL_APPLE_vertex_array_range GL_APPLE_texture_range GL_APPLE_float_pixels GL_ATI_texture_float GL_ARB_texture_float GL_ARB_half_float_pixel GL_APPLE_pixel_buffer GL_APPLE_object_purgeable GL_NV_blend_square GL_NV_fog_distance GL_NV_conditional_render GL_ATI_texture_mirror_once GL_ATI_blend_equation_separate GL_ATI_blend_weighted_minmax GL_ATI_texture_env_combine3 GL_ATI_separate_stencil GL_ATI_texture_compression_3dc GL_SGIS_texture_edge_clamp GL_SGIS_texture_lod GL_SGI_color_matrix GL_EXT_texture_array GL_EXT_vertex_array_bgra GL_ARB_instanced_arrays GL_ARB_depth_buffer_float GL_EXT_packed_float GL_EXT_texture_shared_exponent ### Renderer created! (id = 0) On 1/18/12 1:31 PM, Lawson English wrote: > sigh, I'm getting disk access constantly when my little GUI opengl > thingie runs. The max FPS is 10ish. > Package is: OpenGL-Tutorial-LDE.32 > in monticello repository: > 'http://croquet-src-01.oit.duke.edu:8886/Contributions' > > > suggestions? > > > Thanks. > > L. > > > |
On 20 January 2012 01:29, Lawson English <[hidden email]> wrote:
> Apparently there was a glError that I wasn't catching, so the disk address > issue has gone away: the Baloon3D plugin was logging errors I didn't catch. > > However, I'm not sure how to efficiently blit GUI updates to the gl texture, > so suggestions appreciated. > > Looking at the Squeak3D.log file, it seems to me that Baloon3D already has > access to all the values that Igor is using to setup his NBOpenGL and > GLCanvas packages. Would it be better to leverage that as a cross-platform > initialization for OpenGL instead of another plugin? > My point is following: the more logic you put into VM code (plugin etc), the more limited you are. Because instead of deciding by yourself, what you prefer and what not, someone else deciding for you. I hate constraints, especially in such performance sensitive areas as graphics, where changing a single flag value could mean 10x difference in performance (if not 100x). If we ever need some helpers from VM side is mainly glue code to obtain some handles to resources (like main window handle, etc). But all levers of controls should be at language side, VM should serve as a dummy servant who has no idea what you going to do and just strictly following your orders. > From Squeak3D log: > > > ### Attempting to find hardware renderer > x: 0 > y: 0 > w: 638 > h: 475 > > > Selected pixel format: > AGL_RENDERER_ID : 0x1021A02 > AGL_OFFSCREEN : GL_FALSE > AGL_FULLSCREEN : GL_FALSE > AGL_WINDOW : GL_TRUE > AGL_ACCELERATED : GL_TRUE > AGL_ROBUST : GL_FALSE > AGL_BACKING_STORE : GL_FALSE > AGL_MP_SAFE : GL_TRUE > AGL_COMPLIANT : GL_TRUE > AGL_MULTISCREEN : GL_TRUE > AGL_BUFFER_SIZE : 32 > AGL_LEVEL : 0 > AGL_PIXEL_SIZE : 32 > AGL_DEPTH_SIZE : 24 > AGL_STENCIL_SIZE : 8 > AGL_3_BIT > AGL_AUX_BUFFERS : 0 > > OpenGL vendor: ATI Technologies Inc. > OpenGL renderer: ATI Radeon HD 2600 OpenGL Engine > OpenGL version: 2.1 ATI-1.6.36 > OpenGL extensions: GL_ARB_transpose_matrix GL_ARB_vertex_program > GL_ARB_vertex_blend GL_ARB_window_pos GL_ARB_shader_objects > GL_ARB_vertex_shader GL_ARB_shading_language_100 GL_EXT_multi_draw_arrays > GL_EXT_clip_volume_hint GL_EXT_rescale_normal GL_EXT_draw_range_elements > GL_EXT_fog_coord GL_EXT_gpu_program_parameters GL_EXT_geometry_shader4 > GL_EXT_transform_feedback GL_APPLE_client_storage GL_APPLE_specular_vector > GL_APPLE_transform_hint GL_APPLE_packed_pixels GL_APPLE_fence > GL_APPLE_vertex_array_object GL_APPLE_vertex_program_evaluators > GL_APPLE_element_array GL_APPLE_flush_render GL_APPLE_aux_depth_stencil > GL_NV_texgen_reflection GL_NV_light_max_exponent GL_IBM_rasterpos_clip > GL_SGIS_generate_mipmap GL_ARB_imaging GL_ARB_point_parameters > GL_ARB_texture_env_crossbar GL_ARB_texture_border_clamp GL_ARB_multitexture > GL_ARB_texture_env_add GL_ARB_texture_cube_map GL_ARB_texture_env_dot3 > GL_ARB_multisample GL_ARB_texture_env_combine GL_ARB_texture_compression > GL_ARB_texture_mirrored_repeat GL_ARB_shadow GL_ARB_depth_texture > GL_ARB_shadow_ambient GL_ARB_fragment_program GL_ARB_fragment_program_shadow > GL_ARB_fragment_shader GL_ARB_occlusion_query GL_ARB_point_sprite > GL_ARB_texture_non_power_of_two GL_ARB_vertex_buffer_object > GL_ARB_pixel_buffer_object GL_ARB_draw_buffers GL_ARB_shader_texture_lod > GL_ARB_color_buffer_float GL_ARB_half_float_vertex GL_ARB_texture_rg > GL_ARB_texture_compression_rgtc GL_ARB_framebuffer_object > GL_EXT_compiled_vertex_array GL_EXT_draw_buffers2 GL_EXT_framebuffer_object > GL_EXT_framebuffer_blit GL_EXT_framebuffer_multisample > GL_EXT_texture_rectangle GL_ARB_texture_rectangle GL_EXT_texture_env_add > GL_EXT_blend_color GL_EXT_blend_minmax GL_EXT_blend_subtract > GL_EXT_texture_lod_bias GL_EXT_abgr GL_EXT_bgra GL_EXT_stencil_wrap > GL_EXT_texture_filter_anisotropic GL_EXT_separate_specular_color > GL_EXT_secondary_color GL_EXT_blend_func_separate GL_EXT_shadow_funcs > GL_EXT_stencil_two_side GL_EXT_texture_compression_s3tc > GL_EXT_texture_compression_dxt1 GL_EXT_texture_sRGB > GL_EXT_blend_equation_separate GL_EXT_texture_mirror_clamp > GL_EXT_packed_depth_stencil GL_EXT_bindable_uniform GL_EXT_texture_integer > GL_EXT_gpu_shader4 GL_EXT_framebuffer_sRGB GL_EXT_provoking_vertex > GL_APPLE_flush_buffer_range GL_APPLE_ycbcr_422 GL_APPLE_rgb_422 > GL_APPLE_vertex_array_range GL_APPLE_texture_range GL_APPLE_float_pixels > GL_ATI_texture_float GL_ARB_texture_float GL_ARB_half_float_pixel > GL_APPLE_pixel_buffer GL_APPLE_object_purgeable GL_NV_blend_square > GL_NV_fog_distance GL_NV_conditional_render GL_ATI_texture_mirror_once > GL_ATI_blend_equation_separate GL_ATI_blend_weighted_minmax > GL_ATI_texture_env_combine3 GL_ATI_separate_stencil > GL_ATI_texture_compression_3dc GL_SGIS_texture_edge_clamp > GL_SGIS_texture_lod GL_SGI_color_matrix GL_EXT_texture_array > GL_EXT_vertex_array_bgra GL_ARB_instanced_arrays GL_ARB_depth_buffer_float > GL_EXT_packed_float GL_EXT_texture_shared_exponent > ### Renderer created! (id = 0) > > > > > > > > On 1/18/12 1:31 PM, Lawson English wrote: >> >> sigh, I'm getting disk access constantly when my little GUI opengl thingie >> runs. The max FPS is 10ish. >> Package is: OpenGL-Tutorial-LDE.32 >> in monticello repository: >> 'http://croquet-src-01.oit.duke.edu:8886/Contributions' >> >> >> suggestions? >> >> >> Thanks. >> >> L. >> >> >> > > -- Best regards, Igor Stasenko. |
Free forum by Nabble | Edit this page |