Re: [Pharo-project] [squeak-dev] Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.
On 2010-08-29, at 11:10 AM, stephane ducasse wrote:
John
What I want to understand is what does it means to use open/GL. This means that you use open/GL to implement the primitive? Now I thought that opengl was more vector graphics than bitblt so how does it fit together. Is it because the mac UI is opengl based too?
Stef
Ok let me give you some background, then talk about open/GL The Squeak drawing logic invokes: http://isqueak.org/displayioShowDisplay Which is to say copy this rectangle of data from the Squeak Display Oops data pointer to something that visually shows the user what is going on, since drawing can require a few Smalltalk based calculations resulting in draw events to compose a final image then we also have, http://isqueak.org/ioForceDisplayUpdate To help the process a bit by allowing the drawing subsystem to compose the bits until we are done, then perform the expensive step of visualization. In general the displayioShowDisplay is really fast but the ioForceDisplayUpdate is slow, displayioShowDisplay may not show the bits, but displayioShowDisplay may now (or later... ) Depending on which VM source code (version and platform dependent) you may find that ioForceDisplayUpdate does nothing, or a operating system flush is done to the hardware on every displayioShowDisplay. Where you can see this issue is if you try. Transcript cr;show: [| b | b _ Pen new. Display fillWhite. b place:(Display boundingBox bottomLeft). b hilbert: 9 side: 2 ] timeToRun. Display restore. If this crawls, like taking 30 seconds, then the implementation is flushing every bit draw to the operating system. Well or if you don't see the bits then maybe neither displayioShowDisplay or ioForceDisplayUpdate does any flushing, and all you see is the Display restore results. Now just to make life harder for the VM implementor the Smaltalk code might not call ioForceDisplayUpdate. Then the VM has to do the ioForceDisplayUpdate internally in order not to leave bit's dangling. How this is done again is different from VM to VM. Usually this shows up as a double menu selection highlight. For the 4.2.x series of Macintosh VM we would trigger a operating system flush if more than 20 ms (a settable value) had elapsed, and I did nothing for ioForceDisplayUpdate. But I change this in 5.x and for the iPhone to make ioForceDisplayUpdate the trigger, with a timer that pops if a ioForceDisplayUpdate is not done within 20ms of the last executed displayioShowDisplay. Now about Open/GL, in the past for os-x carbon VM 4.2.X and earlier we used System 7.5.x technology to draw bits, which was quickdraw and quickdraw quartz. When I moved the logic to the iPhone that is not supported technology, because of the interesting drawing logic on the iPhone it took 6 attempts and a long chat with a graphics engineer at Apple. That resulted in using Core Animation to divide the screen into 16 tiles so when a draw happens we note which Tile(s) are dirty based on the rectangle intersections, then on the ioForceDisplayUpdate we generate images for each of the dirty tiles from the Display Oops and tell Core Animation redraw the new tiles. Bert said this seemed slow on OS-X. At this point the next step in our OS-X/iOS drawing path is drop one step lower down and consider Open/GL. I must admit I've not done any open/GL work before so it was a learning opportunity. Although you think of Open/GL as a vector based graphic language it does support what is know as Textures. So instead of providing vectors, you supply bits. So a chunk of data, stating it's RGB, at this depth and pixel layout and size, etc make a chunk of screen glow that is showing the open/GL viewport. Now there are lots of restrictions but the GPUs and drivers have become more friendly so you can supply arbitrary sized rectangles, this was at one time slow, but GPUs have become extremely fast, so slow is fast... In fact on the mac you can supply a arbitrary sized rectangle taken from a much larger rectangle of data, which fits perfectly into the displayioShowDisplay logic. The only hassle is that you need to figure out how the flush should work. So after 3 days of intense effort I can say the algorithm is... displayioShowDisplay collects the union of the rectangles that are being drawn. Nothing more happens... It's pointless to do the glTexImage2D here because 'b hilbert: 9 side: 2' will kill you. Mind we do still watch for a missing ioForceDisplayUpdate. ioForceDisplayUpdate Then takes the union of the rectangles, set a GL viewpoint, and does the glTexImage2D based on figuring out the start point of the top/left pixel of the rectangle to draw, then setups up the coordinate system and finally flush the data. glViewport( subRect.origin.x,subRect.origin.y, subRect.size.width,subRect.size.height ); char *subimg = ((char*)lastBitsIndex) + (unsigned int)(subRect.origin.x + (r.size.height-subRect.origin.y-subRect.size.height)*r.size.width)*4; glTexImage2D( GL_TEXTURE_RECTANGLE_ARB, 0, GL_RGBA, subRect.size.width, subRect.size.height, 0, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, subimg ); glBegin(GL_QUADS); // The -1 is so we flip the coordinate system as os-x and squeak have different views of where (0,0) is... glTexCoord2f(0.0f, 0.0f); glVertex2f(-1.0f, 1.0f); glTexCoord2f(0.0f, subRect.origin.x.size.height); glVertex2f(-1.0f, -1.0f); glTexCoord2f(subRect.origin.x.size.width, subRect.origin.x.size.height); glVertex2f(1.0f, -1.0f); glTexCoord2f(subRect.origin.x.size.width, 0.0f); glVertex2f(1.0f, 1.0f); glEnd(); glFlush() // Ask the hardware to draw this stuff, don't use the more aggressive glFinish() reset the union of draw rectangles. Hint (a) Oddly some people feel they should re-configure the open/GL graphic context on *every* draw cycle, why? (b) People don't read the Apple guidebooks for best practices for doing glTexImage2D, this I know based on Google searches using certain Apple open/GL extension keywords. Notes: This assumes the Squeak display is 32 bits, other resolutions are an exercise for the reader. Actually if the row width is a multiple of 32 bytes then on the Mac things are *much* faster and no copy is made. This is enforced in 5.7b5 by ensuring window size is divisible by 8. When the graphic context is setup when the window is built there is a bunch of cmds to execute, one important one is glPixelStorei( GL_UNPACK_ROW_LENGTH, self.frame.size.width ); and when the window is resized there are a few things to do to indicate how the context has changed. Some platforms like the iPhone might need to do this instead because it doesn't support the GL extension GL_TEXTURE_RECTANGLE_ARB glTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, subRect.size.width, subRect.size.height, 0, GL_RGBA, GL_UNSIGNED_INT_8_8_8_8_REV, NULL ); for( int y = 0; y < subRect.size.height; y++ ) { char *row = ((char*)lastBitsIndex) + ((y + subRect.origin.y)*subRect.size.width + subRect.origin.x) * 4; glTexSubImage2D( GL_TEXTURE_2D, 0, 0, y, subRect.size.width, 1, GL_RGBA, GL_UNSIGNED_BYTE, row ); } -- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Hi, Interesting read, but I am still not sure to understand the implications, so let me ask you another question: is there a way to make use of OpenGL by generating vector graphics from within Pharo? I am particularly interested if there are ways to improve visualization tools like Mondrian to make it use the hardware (and thus maybe have reasonable speed when drawing complex and maybe aliased graphs). Cheers, Doru On 2 Sep 2010, at 01:19, John M McIntosh wrote:
On 2010-08-29, at 11:10 AM, stephane ducasse wrote:
John
What I want to understand is what does it means to use open/GL. This means that you use open/GL to implement the primitive? Now I thought that opengl was more vector graphics than bitblt so how does it fit together. Is it because the mac UI is opengl based too?
Stef
Ok let me give you some background, then talk about open/GL
The Squeak drawing logic invokes: http://isqueak.org/displayioShowDisplay
Which is to say copy this rectangle of data from the Squeak Display Oops data pointer to something that visually shows the user what is going on, since drawing can require a few Smalltalk based calculations resulting in draw events to compose a final image then we also have,
http://isqueak.org/ioForceDisplayUpdate
To help the process a bit by allowing the drawing subsystem to compose the bits until we are done, then perform the expensive step of visualization.
In general the displayioShowDisplay is really fast but the ioForceDisplayUpdate is slow, displayioShowDisplay may not show the bits, but displayioShowDisplay may now (or later... )
Depending on which VM source code (version and platform dependent) you may find that ioForceDisplayUpdate does nothing, or a operating system flush is done to the hardware on every displayioShowDisplay.
Where you can see this issue is if you try.
Transcript cr;show: [| b | b _ Pen new. Display fillWhite. b place:(Display boundingBox bottomLeft). b hilbert: 9 side: 2 ] timeToRun. Display restore.
If this crawls, like taking 30 seconds, then the implementation is flushing every bit draw to the operating system. Well or if you don't see the bits then maybe neither displayioShowDisplay or ioForceDisplayUpdate does any flushing, and all you see is the Display restore results.
Now just to make life harder for the VM implementor the Smaltalk code might not call ioForceDisplayUpdate. Then the VM has to do the ioForceDisplayUpdate internally in order not to leave bit's dangling. How this is done again is different from VM to VM. Usually this shows up as a double menu selection highlight.
For the 4.2.x series of Macintosh VM we would trigger a operating system flush if more than 20 ms (a settable value) had elapsed, and I did nothing for ioForceDisplayUpdate.
But I change this in 5.x and for the iPhone to make ioForceDisplayUpdate the trigger, with a timer that pops if a ioForceDisplayUpdate is not done within 20ms of the last executed displayioShowDisplay.
Now about Open/GL, in the past for os-x carbon VM 4.2.X and earlier we used System 7.5.x technology to draw bits, which was quickdraw and quickdraw quartz.
When I moved the logic to the iPhone that is not supported technology, because of the interesting drawing logic on the iPhone it took 6 attempts and a long chat with a graphics engineer at Apple. That resulted in using Core Animation to divide the screen into 16 tiles so when a draw happens we note which Tile(s) are dirty based on the rectangle intersections, then on the ioForceDisplayUpdate we generate images for each of the dirty tiles from the Display Oops and tell Core Animation redraw the new tiles.
Bert said this seemed slow on OS-X.
At this point the next step in our OS-X/iOS drawing path is drop one step lower down and consider Open/GL.
I must admit I've not done any open/GL work before so it was a learning opportunity.
Although you think of Open/GL as a vector based graphic language it does support what is know as Textures.
So instead of providing vectors, you supply bits. So a chunk of data, stating it's RGB, at this depth and pixel layout and size, etc make a chunk of screen glow that is showing the open/GL viewport.
Now there are lots of restrictions but the GPUs and drivers have become more friendly so you can supply arbitrary sized rectangles, this was at one time slow, but GPUs have become extremely fast, so slow is fast...
In fact on the mac you can supply a arbitrary sized rectangle taken from a much larger rectangle of data, which fits perfectly into the displayioShowDisplay logic.
The only hassle is that you need to figure out how the flush should work. So after 3 days of intense effort I can say the algorithm is...
displayioShowDisplay
collects the union of the rectangles that are being drawn. Nothing more happens... It's pointless to do the glTexImage2D here because 'b hilbert: 9 side: 2' will kill you. Mind we do still watch for a missing ioForceDisplayUpdate.
ioForceDisplayUpdate
Then takes the union of the rectangles, set a GL viewpoint, and does the glTexImage2D based on figuring out the start point of the top/left pixel of the rectangle to draw, then setups up the coordinate system and finally flush the data.
glViewport( subRect.origin.x,subRect.origin.y, subRect.size.width,subRect.size.height );
char *subimg = ((char*)lastBitsIndex) + (unsigned int) (subRect.origin.x + (r.size.height-subRect.origin.y- subRect.size.height)*r.size.width)*4; glTexImage2D( GL_TEXTURE_RECTANGLE_ARB, 0, GL_RGBA, subRect.size.width, subRect.size.height, 0, GL_BGRA, GL_UNSIGNED_INT_8_8_8_8_REV, subimg );
glBegin(GL_QUADS); // The -1 is so we flip the coordinate system as os-x and squeak have different views of where (0,0) is... glTexCoord2f(0.0f, 0.0f); glVertex2f(-1.0f, 1.0f); glTexCoord2f(0.0f, subRect.origin.x.size.height); glVertex2f(-1.0f, -1.0f); glTexCoord2f(subRect.origin.x.size.width, subRect.origin.x.size.height); glVertex2f(1.0f, -1.0f); glTexCoord2f(subRect.origin.x.size.width, 0.0f); glVertex2f(1.0f, 1.0f); glEnd();
glFlush() // Ask the hardware to draw this stuff, don't use the more aggressive glFinish() reset the union of draw rectangles.
Hint (a) Oddly some people feel they should re-configure the open/GL graphic context on *every* draw cycle, why? (b) People don't read the Apple guidebooks for best practices for doing glTexImage2D, this I know based on Google searches using certain Apple open/GL extension keywords.
Notes:
This assumes the Squeak display is 32 bits, other resolutions are an exercise for the reader. Actually if the row width is a multiple of 32 bytes then on the Mac things are *much* faster and no copy is made. This is enforced in 5.7b5 by ensuring window size is divisible by 8.
When the graphic context is setup when the window is built there is a bunch of cmds to execute, one important one is glPixelStorei( GL_UNPACK_ROW_LENGTH, self.frame.size.width ); and when the window is resized there are a few things to do to indicate how the context has changed.
Some platforms like the iPhone might need to do this instead because it doesn't support the GL extension GL_TEXTURE_RECTANGLE_ARB
glTexImage2D( GL_TEXTURE_2D, 0, GL_RGBA, subRect.size.width, subRect.size.height, 0, GL_RGBA, GL_UNSIGNED_INT_8_8_8_8_REV, NULL );
for( int y = 0; y < subRect.size.height; y++ ) { char *row = ((char*)lastBitsIndex) + ((y + subRect.origin.y)*subRect.size.width + subRect.origin.x) * 4; glTexSubImage2D( GL_TEXTURE_2D, 0, 0, y, subRect.size.width, 1, GL_RGBA, GL_UNSIGNED_BYTE, row ); }
-- = = = = = ====================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http:// www.smalltalkconsulting.com = = = = = ======================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "One cannot do more than one can do."
I think if you hunt in the archives you'll find people have attempted to replace Morphic with Open/GL calls via FFI Oh like http://www.squeaksource.com/AlienOpenGL On 2010-09-02, at 8:48 AM, Tudor Girba wrote:
Hi,
Interesting read, but I am still not sure to understand the implications, so let me ask you another question: is there a way to make use of OpenGL by generating vector graphics from within Pharo?
I am particularly interested if there are ways to improve visualization tools like Mondrian to make it use the hardware (and thus maybe have reasonable speed when drawing complex and maybe aliased graphs).
Cheers, Doru
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
On 9/2/2010 11:30 AM, John M McIntosh wrote:
I think if you hunt in the archives you'll find people have attempted to replace Morphic with Open/GL calls via FFI
Or http://www.squeaksource.com/CroquetGL (much more complete w/ extensions etc). Something like this might just work: (OpenGL new) glClearColor: 1.0 with: 0.0 with: 0.0 with: 1.0; swapBuffers. Cheers, - Andreas
On 2010-09-02, at 8:48 AM, Tudor Girba wrote:
Hi,
Interesting read, but I am still not sure to understand the implications, so let me ask you another question: is there a way to make use of OpenGL by generating vector graphics from within Pharo?
I am particularly interested if there are ways to improve visualization tools like Mondrian to make it use the hardware (and thus maybe have reasonable speed when drawing complex and maybe aliased graphs).
Cheers, Doru
-- =========================================================================== John M. McIntosh<johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Ahh! And also what Andreas mentions. AlienOpenGL is not current being maintained and is missing features. Although it works for what i needed it at the moment. Tudor: if you are going to the ESUG we could spend some time with this. Saludos, Fernando On Sep 2, 2010, at 8:54 PM, Andreas Raab wrote:
On 9/2/2010 11:30 AM, John M McIntosh wrote:
I think if you hunt in the archives you'll find people have attempted to replace Morphic with Open/GL calls via FFI
Or http://www.squeaksource.com/CroquetGL (much more complete w/ extensions etc). Something like this might just work:
(OpenGL new) glClearColor: 1.0 with: 0.0 with: 0.0 with: 1.0; swapBuffers.
Cheers, - Andreas
On 2010-09-02, at 8:48 AM, Tudor Girba wrote:
Hi,
Interesting read, but I am still not sure to understand the implications, so let me ask you another question: is there a way to make use of OpenGL by generating vector graphics from within Pharo?
I am particularly interested if there are ways to improve visualization tools like Mondrian to make it use the hardware (and thus maybe have reasonable speed when drawing complex and maybe aliased graphs).
Cheers, Doru
-- =========================================================================== John M. McIntosh<johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Also, if your main goal is to speed up Mondrian, a good idea would be to do some culling, which is fully possible without switching to OpenGL. When I looked some time ago at least, the model was more geared towards easy creation/manipulation than optimized drawing speed. IE. although it keeps a cache of visible items or something similar, my memory is a bit hazy, it still iterates and draws every object in this cache each draw cycle, even if they are off screen. It might not mean much when looking at an overview of a large model, but when zoomed in I was at least able to get decend FPS rather than < 1 FPM ;) Cheers, Henry Note: This is things you'd want to do even if you were rendering with OpenGL, although it performs culling, sending the data for the entire model can be a big overhead. On 02.09.2010 21:41, Fernando olivero wrote:
Ahh! And also what Andreas mentions.
AlienOpenGL is not current being maintained and is missing features. Although it works for what i needed it at the moment.
Tudor: if you are going to the ESUG we could spend some time with this.
Saludos, Fernando
On Sep 2, 2010, at 8:54 PM, Andreas Raab wrote:
On 9/2/2010 11:30 AM, John M McIntosh wrote:
I think if you hunt in the archives you'll find people have attempted to replace Morphic with Open/GL calls via FFI
Oh like http://www.squeaksource.com/AlienOpenGL Or http://www.squeaksource.com/CroquetGL (much more complete w/ extensions etc). Something like this might just work:
(OpenGL new) glClearColor: 1.0 with: 0.0 with: 0.0 with: 1.0; swapBuffers.
Cheers, - Andreas
On 2010-09-02, at 8:48 AM, Tudor Girba wrote:
Hi,
Interesting read, but I am still not sure to understand the implications, so let me ask you another question: is there a way to make use of OpenGL by generating vector graphics from within Pharo?
I am particularly interested if there are ways to improve visualization tools like Mondrian to make it use the hardware (and thus maybe have reasonable speed when drawing complex and maybe aliased graphs).
Cheers, Doru -- =========================================================================== John M. McIntosh<johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
What do you mean by "culling" ? Cheers, Alexandre On 2 Sep 2010, at 17:55, Henrik Sperre Johansen wrote:
Also, if your main goal is to speed up Mondrian, a good idea would be to do some culling, which is fully possible without switching to OpenGL. When I looked some time ago at least, the model was more geared towards easy creation/manipulation than optimized drawing speed. IE. although it keeps a cache of visible items or something similar, my memory is a bit hazy, it still iterates and draws every object in this cache each draw cycle, even if they are off screen. It might not mean much when looking at an overview of a large model, but when zoomed in I was at least able to get decend FPS rather than < 1 FPM ;)
Cheers, Henry
Note: This is things you'd want to do even if you were rendering with OpenGL, although it performs culling, sending the data for the entire model can be a big overhead.
On 02.09.2010 21:41, Fernando olivero wrote:
Ahh! And also what Andreas mentions.
AlienOpenGL is not current being maintained and is missing features. Although it works for what i needed it at the moment.
Tudor: if you are going to the ESUG we could spend some time with this.
Saludos, Fernando
On Sep 2, 2010, at 8:54 PM, Andreas Raab wrote:
On 9/2/2010 11:30 AM, John M McIntosh wrote:
I think if you hunt in the archives you'll find people have attempted to replace Morphic with Open/GL calls via FFI
Oh like http://www.squeaksource.com/AlienOpenGL Or http://www.squeaksource.com/CroquetGL (much more complete w/ extensions etc). Something like this might just work:
(OpenGL new) glClearColor: 1.0 with: 0.0 with: 0.0 with: 1.0; swapBuffers.
Cheers, - Andreas
On 2010-09-02, at 8:48 AM, Tudor Girba wrote:
Hi,
Interesting read, but I am still not sure to understand the implications, so let me ask you another question: is there a way to make use of OpenGL by generating vector graphics from within Pharo?
I am particularly interested if there are ways to improve visualization tools like Mondrian to make it use the hardware (and thus maybe have reasonable speed when drawing complex and maybe aliased graphs).
Cheers, Doru -- =========================================================================== John M. McIntosh<johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 03.09.2010 00:00, Alexandre Bergel wrote:
What do you mean by "culling" ?
Cheers, Alexandre Excluding objects that are not visible in the window from being rendered.
Cheers, Henry
On 2 Sep 2010, at 17:55, Henrik Sperre Johansen wrote:
Also, if your main goal is to speed up Mondrian, a good idea would be to do some culling, which is fully possible without switching to OpenGL. When I looked some time ago at least, the model was more geared towards easy creation/manipulation than optimized drawing speed. IE. although it keeps a cache of visible items or something similar, my memory is a bit hazy, it still iterates and draws every object in this cache each draw cycle, even if they are off screen. It might not mean much when looking at an overview of a large model, but when zoomed in I was at least able to get decend FPS rather than< 1 FPM ;)
Cheers, Henry
Note: This is things you'd want to do even if you were rendering with OpenGL, although it performs culling, sending the data for the entire model can be a big overhead.
On 02.09.2010 21:41, Fernando olivero wrote:
Ahh! And also what Andreas mentions.
AlienOpenGL is not current being maintained and is missing features. Although it works for what i needed it at the moment.
Tudor: if you are going to the ESUG we could spend some time with this.
Saludos, Fernando
On Sep 2, 2010, at 8:54 PM, Andreas Raab wrote:
On 9/2/2010 11:30 AM, John M McIntosh wrote:
I think if you hunt in the archives you'll find people have attempted to replace Morphic with Open/GL calls via FFI
Oh like http://www.squeaksource.com/AlienOpenGL Or http://www.squeaksource.com/CroquetGL (much more complete w/ extensions etc). Something like this might just work:
(OpenGL new) glClearColor: 1.0 with: 0.0 with: 0.0 with: 1.0; swapBuffers.
Cheers, - Andreas
On 2010-09-02, at 8:48 AM, Tudor Girba wrote:
Hi,
Interesting read, but I am still not sure to understand the implications, so let me ask you another question: is there a way to make use of OpenGL by generating vector graphics from within Pharo?
I am particularly interested if there are ways to improve visualization tools like Mondrian to make it use the hardware (and thus maybe have reasonable speed when drawing complex and maybe aliased graphs).
Cheers, Doru -- =========================================================================== John M. McIntosh<johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
This is partially the case in Mondrian. Objects located outside the window are not rendered. However, they are layouted. This is one of the reasons that prevents Mondrian from visualizing, let's say, 1,000,000 nodes. Cheers, Alexandre On 2 Sep 2010, at 18:02, Henrik Sperre Johansen wrote:
On 03.09.2010 00:00, Alexandre Bergel wrote:
What do you mean by "culling" ?
Cheers, Alexandre Excluding objects that are not visible in the window from being rendered.
Cheers, Henry
On 2 Sep 2010, at 17:55, Henrik Sperre Johansen wrote:
Also, if your main goal is to speed up Mondrian, a good idea would be to do some culling, which is fully possible without switching to OpenGL. When I looked some time ago at least, the model was more geared towards easy creation/manipulation than optimized drawing speed. IE. although it keeps a cache of visible items or something similar, my memory is a bit hazy, it still iterates and draws every object in this cache each draw cycle, even if they are off screen. It might not mean much when looking at an overview of a large model, but when zoomed in I was at least able to get decend FPS rather than< 1 FPM ;)
Cheers, Henry
Note: This is things you'd want to do even if you were rendering with OpenGL, although it performs culling, sending the data for the entire model can be a big overhead.
On 02.09.2010 21:41, Fernando olivero wrote:
Ahh! And also what Andreas mentions.
AlienOpenGL is not current being maintained and is missing features. Although it works for what i needed it at the moment.
Tudor: if you are going to the ESUG we could spend some time with this.
Saludos, Fernando
On Sep 2, 2010, at 8:54 PM, Andreas Raab wrote:
On 9/2/2010 11:30 AM, John M McIntosh wrote:
I think if you hunt in the archives you'll find people have attempted to replace Morphic with Open/GL calls via FFI
Oh like http://www.squeaksource.com/AlienOpenGL Or http://www.squeaksource.com/CroquetGL (much more complete w/ extensions etc). Something like this might just work:
(OpenGL new) glClearColor: 1.0 with: 0.0 with: 0.0 with: 1.0; swapBuffers.
Cheers, - Andreas
On 2010-09-02, at 8:48 AM, Tudor Girba wrote:
Hi,
Interesting read, but I am still not sure to understand the implications, so let me ask you another question: is there a way to make use of OpenGL by generating vector graphics from within Pharo?
I am particularly interested if there are ways to improve visualization tools like Mondrian to make it use the hardware (and thus maybe have reasonable speed when drawing complex and maybe aliased graphs).
Cheers, Doru -- =========================================================================== John M. McIntosh<johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 03.09.2010 00:04, Alexandre Bergel wrote:
This is partially the case in Mondrian. Objects located outside the window are not rendered. Ehm, my memory was a bit hazy.
In the version I used, MONode>displayOn: did do culling, no such luck for MOEdge though. Since MOGraphElement>>elementsToDisplay created a cache of ALL the subnodes and subedges of an element (as part of MONode>displayOn:), well, when the top element was told to displayOn:, it saw itself as visible, then displayOn:'ed all the objects and edges in the model (from the z-order sorted elementsToDisplayCache), leading to culling of offscreen objects, but drawing all edges in the entire model. That's what I meant with model more being suited for traversing btw, as the tree-structure itself makes sense for iterating the model, but not for rendering, as what you want from a model specialized for that, is deciding if the sub-elements of a node is safe to cull if the node itself is safe to cull. Cheers, Henry
This is partially the case in Mondrian. Objects located outside the window are not rendered. Ehm, my memory was a bit hazy.
No problem :-)
In the version I used, MONode>displayOn: did do culling, no such luck for MOEdge though.
MOEdge does not do the culling since an edge can be visible without having its two extremity visible. Edges are indeed a problem. Having very non-embedded and very long edges costs a lot.
Since MOGraphElement>>elementsToDisplay created a cache of ALL the subnodes and subedges of an element (as part of MONode>displayOn:), well, when the top element was told to displayOn:, it saw itself as visible, then displayOn:'ed all the objects and edges in the model (from the z-order sorted elementsToDisplayCache), leading to culling of offscreen objects, but drawing all edges in the entire model.
yes, edges are drawn. One way to improve the rendering speed up, is to first display the nodes visible, then continuing the layout in 2 threads, one vertically and another one horizontally (to follow the two scrollbar of the window, since those are likely to be used first when the window appear). But this would imply a major change in the way layout are computed. Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
On 03.09.2010 00:48, Alexandre Bergel wrote:
This is partially the case in Mondrian. Objects located outside the window are not rendered. Ehm, my memory was a bit hazy. No problem :-)
In the version I used, MONode>displayOn: did do culling, no such luck for MOEdge though. MOEdge does not do the culling since an edge can be visible without having its two extremity visible. Edges are indeed a problem. Having very non-embedded and very long edges costs a lot. Unless edges can be curved, a simple rect-rect intersection would be quite sufficient for eliminating lots of edges, at least in the zoomed in scenario.
Since MOGraphElement>>elementsToDisplay created a cache of ALL the subnodes and subedges of an element (as part of MONode>displayOn:), well, when the top element was told to displayOn:, it saw itself as visible, then displayOn:'ed all the objects and edges in the model (from the z-order sorted elementsToDisplayCache), leading to culling of offscreen objects, but drawing all edges in the entire model. yes, edges are drawn. Eh, that was maybe a bit cryptic. What I meant was, even if you do culling at the object level, you're still iterating over the entire model deciding what should be rendered every displayOn: call (if only just to perform an isVisible: check).
What you really need (in _addition_ to the current graph-model, which works great for reporting damage rects etc when manipulating the model), is f.ex. a quad-tree structure based on the physical location of the objects, which can be used for culling during the rendering phase.
One way to improve the rendering speed up, is to first display the nodes visible, then continuing the layout in 2 threads, one vertically and another one horizontally (to follow the two scrollbar of the window, since those are likely to be used first when the window appear). But this would imply a major change in the way layout are computed.
Alexandre The simple way to get better performance is by profiling, and doing less. Doing culling properly is a good and (relatively to what you describe) simple first step.
That, and, I just realized, drawing each visible object once. ;) If I'm not wrong (haven't tested it) the elementsToDisplay is created using allSubNodes/EdgesDo: , so what happens in the cases where displayOn: is called to one of the visible subnodes, which also has visible subnodes? Cheers, Henry
In the version I used, MONode>displayOn: did do culling, no such luck for MOEdge though. MOEdge does not do the culling since an edge can be visible without having its two extremity visible. Edges are indeed a problem. Having very non-embedded and very long edges costs a lot. Unless edges can be curved, a simple rect-rect intersection would be quite sufficient for eliminating lots of edges, at least in the zoomed in scenario.
It makes sense. Currently, all the non-embedded edges are displayed. However, if the window is not between the two extremity, then there is no point in drawing the edge. Something that I should implement. I added a google entry for this: http://code.google.com/p/moose-technology/issues/detail?id=450
What I meant was, even if you do culling at the object level, you're still iterating over the entire model deciding what should be rendered every displayOn: call (if only just to perform an isVisible: check).
Yes
What you really need (in _addition_ to the current graph-model, which works great for reporting damage rects etc when manipulating the model), is f.ex. a quad-tree structure based on the physical location of the objects, which can be used for culling during the rendering phase.
Yes, we have been talking about QuadTree recently. It would be great to have them in Mondrian. However, QuadTree will work well for rendering the nodes. One problem that prevent scalability, is the layout computation. It easily take a lot of time.
That, and, I just realized, drawing each visible object once. ;) If I'm not wrong (haven't tested it) the elementsToDisplay is created using allSubNodes/EdgesDo: , so what happens in the cases where displayOn: is called to one of the visible subnodes, which also has visible subnodes?
A subnode is removed from elementsToDisplay if its parent is displayed and uses a bitmap cache (in #updateOwner). Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Hi, Unfortunately, I won't be going to ESUG this year. Cheers, Doru On 2 Sep 2010, at 21:41, Fernando olivero wrote:
Ahh! And also what Andreas mentions.
AlienOpenGL is not current being maintained and is missing features. Although it works for what i needed it at the moment.
Tudor: if you are going to the ESUG we could spend some time with this.
Saludos, Fernando
On Sep 2, 2010, at 8:54 PM, Andreas Raab wrote:
On 9/2/2010 11:30 AM, John M McIntosh wrote:
I think if you hunt in the archives you'll find people have attempted to replace Morphic with Open/GL calls via FFI
Or http://www.squeaksource.com/CroquetGL (much more complete w/ extensions etc). Something like this might just work:
(OpenGL new) glClearColor: 1.0 with: 0.0 with: 0.0 with: 1.0; swapBuffers.
Cheers, - Andreas
On 2010-09-02, at 8:48 AM, Tudor Girba wrote:
Hi,
Interesting read, but I am still not sure to understand the implications, so let me ask you another question: is there a way to make use of OpenGL by generating vector graphics from within Pharo?
I am particularly interested if there are ways to improve visualization tools like Mondrian to make it use the hardware (and thus maybe have reasonable speed when drawing complex and maybe aliased graphs).
Cheers, Doru
-- = = = = = = = ==================================================================== John M. McIntosh<johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = = = = = ====================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Beauty is where we see it."
Thanks, it looks interesting. Cheers, Doru On 2 Sep 2010, at 20:54, Andreas Raab wrote:
On 9/2/2010 11:30 AM, John M McIntosh wrote:
I think if you hunt in the archives you'll find people have attempted to replace Morphic with Open/GL calls via FFI
Or http://www.squeaksource.com/CroquetGL (much more complete w/ extensions etc). Something like this might just work:
(OpenGL new) glClearColor: 1.0 with: 0.0 with: 0.0 with: 1.0; swapBuffers.
Cheers, - Andreas
On 2010-09-02, at 8:48 AM, Tudor Girba wrote:
Hi,
Interesting read, but I am still not sure to understand the implications, so let me ask you another question: is there a way to make use of OpenGL by generating vector graphics from within Pharo?
I am particularly interested if there are ways to improve visualization tools like Mondrian to make it use the hardware (and thus maybe have reasonable speed when drawing complex and maybe aliased graphs).
Cheers, Doru
-- = = = = = = ===================================================================== John M. McIntosh<johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = = = = =====================================================================
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- www.tudorgirba.com "Value is always contextual."
On Sep 2, 2010, at 8:30 PM, John M McIntosh wrote:
I think if you hunt in the archives you'll find people have attempted to replace Morphic with Open/GL calls via FFI
I recall an attempt to use OpenGL as a renderer for a Morphic Canvas. If you look at the IWST09 Lumiere paper you can find references.
Oh like http://www.squeaksource.com/AlienOpenGL
On 2010-09-02, at 8:48 AM, Tudor Girba wrote:
Hi,
Interesting read, but I am still not sure to understand the implications, so let me ask you another question: is there a way to make use of OpenGL by generating vector graphics from within Pharo?
Yes, this is what i had in mind when i programmed Lumiere. And somehow was achieved, except for text rendering. Using AlienOpenGL you get an OpenGL "canvas", that can be embeded into the Morphic framework. Somehow like a "hole" in the Display, where you have a OpenGL + OS area in the back. (Althoug depends on the vm, because some of them dont handle well transparency of the World , i recall Linux was the only one working ..check out HoleLW of the CUIS LightWidgets framework) If you want the two world to coexist, ( Lumiere ) then you have to take care of translating Morphic points into OpenGL points. But the infrastructure is there to easily achieve it. Though i think that Igor's port to OpenGL is a better way to go.
I am particularly interested if there are ways to improve visualization tools like Mondrian to make it use the hardware (and thus maybe have reasonable speed when drawing complex and maybe aliased graphs).
A Mondrian renderer that interfaced to OpenGL for drawing could be implemented using the mechanism explained before.
Cheers, Doru
-- =========================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com ===========================================================================
<smime.p7s><ATT00001..txt>
participants (6)
-
Alexandre Bergel -
Andreas Raab -
Fernando olivero -
Henrik Sperre Johansen -
John M McIntosh -
Tudor Girba