Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.
Locked
12
12
Re: [squeak-dev] Re: Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.
 
|
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<[hidden email]> Twitter: squeaker68882 >>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>>> =========================================================================== >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.
|
|
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<[hidden email]> Twitter: squeaker68882 >>>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>>>> =========================================================================== >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.
|
|
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<[hidden email]> Twitter: squeaker68882 >>>>>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>>>>> =========================================================================== >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>> _______________________________________________ >>>> Pharo-project mailing list >>>> [hidden email] >>>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >>> >>> _______________________________________________ >>> Pharo-project mailing list >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.
|
|
In reply to this post by Fernando olivero-2
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 >>> >>> 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<[hidden email]> Twitter: >>> squeaker68882 >>> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >>> = >>> = >>> = >>> = >>> = >>> = >>> = >>> ==================================================================== >>> >>> >>> >>> >>> >>> >>> >>> >> >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Beauty is where we see it." _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.
|
|
In reply to this post by Andreas.Raab
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 >> >> 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<[hidden email]> Twitter: >> squeaker68882 >> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com >> = >> = >> = >> = >> = >> = >> ===================================================================== >> >> >> >> >> >> >> >> > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project -- www.tudorgirba.com "Value is always contextual." _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.
|
|
In reply to this post by Alexandre Bergel
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.
|
|
>> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.
|
|
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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Re: [squeak-dev] Re: Experimental Cocoa OS-X based Squeak Cog JIT VM 5.8b4.
|
|
>>> 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 ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
«
Return to Pharo Smalltalk Developers
|
1 view|%1 views
| Free forum by Nabble | Edit this page |