Re: [osg-users] Speeding Up osgText?
Nope, we rarely use the backdrop feature. I'll look into optimizing the
code based on the comment.
If I do make some modifications that seem to benefit, what procedures do
I need to take to get these changes integrated into the OSG baseline?
Are the procedures posted on the website?
Thanks.
Ryan H. Kawicki
The Boeing Company
Training Systems Services
Software Engineer
-Original Message-
From: E. Wing [mailto:[EMAIL PROTECTED]
Sent: Saturday, September 06, 2008 6:46 AM
To: OpenSceneGraph Users
Subject: Re: [osg-users] Speeding Up osgText?
void Text::computePositions()
{
unsigned int size =
osg::maximum(osg::DisplaySettings::instance()-getMaxNumberOfGraphicsC
on
texts(),_autoTransformCache.size());
// FIXME: OPTIMIZE: This would be one of the ideal locations to
// call computeAverageGlypthWidthAndHeight(). It is out of the
contextID loop
// so the value would be computed fewer times. But the code will
need changes
// to get the value down to the locations it is needed. (Either
pass through parameters
// or member variables, but we would need a system to know if the
values are stale.)
for(unsigned int i=0;isize;++i)
{
computePositions(i);
}
}
So I am not an expert on the osgText implementation, but I think I am
the one that wrote that comment. I wrote that when I added the backdrop
text and gradient feature to osgText. My strategy was to make the least
amount of structural changes as possible because the implementation was
sufficiently complicated enough, so optimization wasn't my goal.
I think that above block already existed in some form before my changes,
but as I was refactoring trying to fit in the new features, I think I
took note of that block of code and added that comment realizing it
could be faster. I suggest if you are looking for a way to speed things
up, you could try to do exactly what that comment says. I honestly don't
remember the code at this point, and I never really profiled how much
time was spent in that loop. But I think it is one of the more
staightforward and obvious places that can be optimized (but probably
tedious).
Another thing to note is with the backdrop feature on, it isn't terribly
efficient if I recall, because it needs to repeat for every direction of
the shadow. So if you do outline text, you multiply by 8 or 9 passes. So
don't turn on backdrop text if there are performance problems.
-Eric
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.or
g
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
Re: [osg-users] Speeding Up osgText?
void Text::computePositions()
{
unsigned int size =
osg::maximum(osg::DisplaySettings::instance()-getMaxNumberOfGraphicsCon
texts(),_autoTransformCache.size());
// FIXME: OPTIMIZE: This would be one of the ideal locations to
// call computeAverageGlypthWidthAndHeight(). It is out of the
contextID loop
// so the value would be computed fewer times. But the code will
need changes
// to get the value down to the locations it is needed. (Either pass
through parameters
// or member variables, but we would need a system to know if the
values are stale.)
for(unsigned int i=0;isize;++i)
{
computePositions(i);
}
}
So I am not an expert on the osgText implementation, but I think I am
the one that wrote that comment. I wrote that when I added the
backdrop text and gradient feature to osgText. My strategy was to make
the least amount of structural changes as possible because the
implementation was sufficiently complicated enough, so optimization
wasn't my goal.
I think that above block already existed in some form before my
changes, but as I was refactoring trying to fit in the new features, I
think I took note of that block of code and added that comment
realizing it could be faster. I suggest if you are looking for a way
to speed things up, you could try to do exactly what that comment
says. I honestly don't remember the code at this point, and I never
really profiled how much time was spent in that loop. But I think it
is one of the more staightforward and obvious places that can be
optimized (but probably tedious).
Another thing to note is with the backdrop feature on, it isn't
terribly efficient if I recall, because it needs to repeat for every
direction of the shadow. So if you do outline text, you multiply by 8
or 9 passes. So don't turn on backdrop text if there are performance
problems.
-Eric
___
osg-users mailing list
osg-users@lists.openscenegraph.org
http://lists.openscenegraph.org/listinfo.cgi/osg-users-openscenegraph.org
[osg-users] Speeding Up osgText?
This is in reference to a previous question that has been posed. Sorry
if this has already been addressed.
http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2
008-April/009652.html
Our application seems to be hitting this same issue. We are trying to
render quite a bit of text on the screen, and we seem to be getting
burned by both the setText( ... ) and the drawImplementation.
We are currently using an older version of OSG, but we are planning on
moving to 2.6.0 relatively soon. I have looked at our current version
of osgText and the 2.6.0 version and can conclude that this will still
be an issue.
Our application is building the text shapes with SCREEN_COORDS for the
character size mode and SCREEN for axis alignment.
What I have noticed is that for each text shape update, the function
computeGlyphRepresentation is called to recompute the glyph information.
This function then calls the function computePositions. Here is what
compute positions looks like.
void Text::computePositions()
{
unsigned int size =
osg::maximum(osg::DisplaySettings::instance()-getMaxNumberOfGraphicsCon
texts(),_autoTransformCache.size());
// FIXME: OPTIMIZE: This would be one of the ideal locations to
// call computeAverageGlypthWidthAndHeight(). It is out of the
contextID loop
// so the value would be computed fewer times. But the code will
need changes
// to get the value down to the locations it is needed. (Either pass
through parameters
// or member variables, but we would need a system to know if the
values are stale.)
for(unsigned int i=0;isize;++i)
{
computePositions(i);
}
}
As can be seen by the first line, the maximum size is being obtained
from the maximum number of graphics contexts or the size of
_autoTransformCache. For me this is set to 32, since the default was
never being changed. The computePositions function is a very expensive
operation, and a minor flaw in our design was causing a huge impact in
performance. It might be a good idea to either assert on or to check
the traversalNumber from the _autoTransformCache to make sure the
context is a valid one.
Performance is still down for our application. I think some of the
problem is related to this computePositions function still. Our
application is frequently setting text, so we incur a CPU hit to
recalculate all the glyph vertices. When the text is visible, we incur
the same CPU hit to recalculate all the glyph vertices since the
_autoTransformCache model view matrix are always different between the
update of the text and the current state of the draw phase. Here's the
draw implementation for text.
void Text::drawImplementation(osg::State state) const
{
unsigned int contextID = state.getContextID();
CODE REMOVED
if (_characterSizeMode!=OBJECT_COORDS || _autoRotateToScreen)
{
CODE REMOVED
AutoTransformCache atc = _autoTransformCache[contextID];
const osg::Matrix modelview = state.getModelViewMatrix();
const osg::Matrix projection = state.getProjectionMatrix();
CODE REMOVED
bool doUpdate = atc._traversalNumber==-1;
if (atc._traversalNumber=0)
{
if (atc._modelview!=modelview)
{
doUpdate = true;
}
else if (width!=atc._width || height!=atc._height)
{
doUpdate = true;
}
else if (atc._projection!=projection)
{
doUpdate = true;
}
}
atc._traversalNumber = frameNumber;
atc._width = width;
atc._height = height;
if (doUpdate)
{
atc._transformedPosition = newTransformedPosition;
atc._projection = projection;
atc._modelview = modelview;
computePositions(contextID);
}
}
CODE REMOVED
}
With the draw implementation above and the setText all being called
within a render frame, we are computing the glyph vertices twice. I
think we can speed things up a bit, but I need some information.
Is there a reason as to why we need to call computePositions from within
computeGlyphRepresentation if the drawImplementation will already take
care of that? As far as I can see, computeGlyphRepresentation is
already doing the calculations for the bounding box. Makes sense that
we only have that information. We can then just allow the
drawImplementation do the nasty work of recalculating the vertices by
calling computePositions.
Does anyone have any suggestions that might help in improving
performance? I am wondering if some of this work could be moved from
the CPU and pushed to the GPU.
Sorry for the long post and thanks for any suggestions.
Ryan H. Kawicki
The Boeing Company
Training Systems Services
Software Engineer
___
osg-users mailing list
Re: [osg-users] Speeding Up osgText?
Hi Ryan,
can't answer your question immediately but i am embarking on a lot of
work around osgText so thanks for the heads up and the detailed post.
I'll consider your points as i work through what i need to do. Will
obviously post feedback to the group.
rgds
Nick
Kawicki, Ryan H wrote:
This is in reference to a previous question that has been posed. Sorry
if this has already been addressed.
http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2
008-April/009652.html
Our application seems to be hitting this same issue. We are trying to
render quite a bit of text on the screen, and we seem to be getting
burned by both the setText( ... ) and the drawImplementation.
We are currently using an older version of OSG, but we are planning on
moving to 2.6.0 relatively soon. I have looked at our current version
of osgText and the 2.6.0 version and can conclude that this will still
be an issue.
Our application is building the text shapes with SCREEN_COORDS for the
character size mode and SCREEN for axis alignment.
What I have noticed is that for each text shape update, the function
computeGlyphRepresentation is called to recompute the glyph information.
This function then calls the function computePositions. Here is what
compute positions looks like.
void Text::computePositions()
{
unsigned int size =
osg::maximum(osg::DisplaySettings::instance()-getMaxNumberOfGraphicsCon
texts(),_autoTransformCache.size());
// FIXME: OPTIMIZE: This would be one of the ideal locations to
// call computeAverageGlypthWidthAndHeight(). It is out of the
contextID loop
// so the value would be computed fewer times. But the code will
need changes
// to get the value down to the locations it is needed. (Either pass
through parameters
// or member variables, but we would need a system to know if the
values are stale.)
for(unsigned int i=0;isize;++i)
{
computePositions(i);
}
}
As can be seen by the first line, the maximum size is being obtained
from the maximum number of graphics contexts or the size of
_autoTransformCache. For me this is set to 32, since the default was
never being changed. The computePositions function is a very expensive
operation, and a minor flaw in our design was causing a huge impact in
performance. It might be a good idea to either assert on or to check
the traversalNumber from the _autoTransformCache to make sure the
context is a valid one.
Performance is still down for our application. I think some of the
problem is related to this computePositions function still. Our
application is frequently setting text, so we incur a CPU hit to
recalculate all the glyph vertices. When the text is visible, we incur
the same CPU hit to recalculate all the glyph vertices since the
_autoTransformCache model view matrix are always different between the
update of the text and the current state of the draw phase. Here's the
draw implementation for text.
void Text::drawImplementation(osg::State state) const
{
unsigned int contextID = state.getContextID();
CODE REMOVED
if (_characterSizeMode!=OBJECT_COORDS || _autoRotateToScreen)
{
CODE REMOVED
AutoTransformCache atc = _autoTransformCache[contextID];
const osg::Matrix modelview = state.getModelViewMatrix();
const osg::Matrix projection = state.getProjectionMatrix();
CODE REMOVED
bool doUpdate = atc._traversalNumber==-1;
if (atc._traversalNumber=0)
{
if (atc._modelview!=modelview)
{
doUpdate = true;
}
else if (width!=atc._width || height!=atc._height)
{
doUpdate = true;
}
else if (atc._projection!=projection)
{
doUpdate = true;
}
}
atc._traversalNumber = frameNumber;
atc._width = width;
atc._height = height;
if (doUpdate)
{
atc._transformedPosition = newTransformedPosition;
atc._projection = projection;
atc._modelview = modelview;
computePositions(contextID);
}
}
CODE REMOVED
}
With the draw implementation above and the setText all being called
within a render frame, we are computing the glyph vertices twice. I
think we can speed things up a bit, but I need some information.
Is there a reason as to why we need to call computePositions from within
computeGlyphRepresentation if the drawImplementation will already take
care of that? As far as I can see, computeGlyphRepresentation is
already doing the calculations for the bounding box. Makes sense that
we only have that information. We can then just allow the
drawImplementation do the nasty work of recalculating the vertices by
calling computePositions.
Does anyone have any suggestions that might help in improving
performance? I am wondering if
Re: [osg-users] Speeding Up osgText?
On Fri, 2008-09-05 at 22:53 +0100, Nick Bryan wrote:
Hi Ryan,
can't answer your question immediately but i am embarking on a lot of
work around osgText so thanks for the heads up and the detailed post.
I'll consider your points as i work through what i need to do. Will
obviously post feedback to the group.
I'd be very interested in know what and how and why you're doing
this. :)
I've been asking about some osgText for months to improve osgWidget, but
haven't really made any impressions I don't think (we're all pretty
busy, as it were).
As such, I have begun (and am almost finished!) writing an OSG NodeKit
called osgPango, which uses the Pango library to layout text, create
high-quality subpixel fonts renderings, etc. Whether or not anyone else
will be interested in it is hard to say, but I intend on using it for my
own purpose because I get superb font quality (even shadows and
outlines!) and a simplified API.
I had originally intended to just hack osgText, but the code is far too
complicated for me to grok. :) So I just ended up writing a different
NodeKit for it, which will be compaitble with osgWidget for sure (in the
form of osgPango::Label and osgPango::Input).
I have posted many times about osgText in the past, and if you would
like I can recall those links here for you to check out (particularly
with regards to quality--see osgfont--and the inability to insure that
all quads are pixel-aligned and that I can access the extents of each
text glyph individually for input...)
rgds
Nick
Kawicki, Ryan H wrote:
This is in reference to a previous question that has been posed. Sorry
if this has already been addressed.
http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2
008-April/009652.html
Our application seems to be hitting this same issue. We are trying to
render quite a bit of text on the screen, and we seem to be getting
burned by both the setText( ... ) and the drawImplementation.
We are currently using an older version of OSG, but we are planning on
moving to 2.6.0 relatively soon. I have looked at our current version
of osgText and the 2.6.0 version and can conclude that this will still
be an issue.
Our application is building the text shapes with SCREEN_COORDS for the
character size mode and SCREEN for axis alignment.
What I have noticed is that for each text shape update, the function
computeGlyphRepresentation is called to recompute the glyph information.
This function then calls the function computePositions. Here is what
compute positions looks like.
void Text::computePositions()
{
unsigned int size =
osg::maximum(osg::DisplaySettings::instance()-getMaxNumberOfGraphicsCon
texts(),_autoTransformCache.size());
// FIXME: OPTIMIZE: This would be one of the ideal locations to
// call computeAverageGlypthWidthAndHeight(). It is out of the
contextID loop
// so the value would be computed fewer times. But the code will
need changes
// to get the value down to the locations it is needed. (Either pass
through parameters
// or member variables, but we would need a system to know if the
values are stale.)
for(unsigned int i=0;isize;++i)
{
computePositions(i);
}
}
As can be seen by the first line, the maximum size is being obtained
from the maximum number of graphics contexts or the size of
_autoTransformCache. For me this is set to 32, since the default was
never being changed. The computePositions function is a very expensive
operation, and a minor flaw in our design was causing a huge impact in
performance. It might be a good idea to either assert on or to check
the traversalNumber from the _autoTransformCache to make sure the
context is a valid one.
Performance is still down for our application. I think some of the
problem is related to this computePositions function still. Our
application is frequently setting text, so we incur a CPU hit to
recalculate all the glyph vertices. When the text is visible, we incur
the same CPU hit to recalculate all the glyph vertices since the
_autoTransformCache model view matrix are always different between the
update of the text and the current state of the draw phase. Here's the
draw implementation for text.
void Text::drawImplementation(osg::State state) const
{
unsigned int contextID = state.getContextID();
CODE REMOVED
if (_characterSizeMode!=OBJECT_COORDS || _autoRotateToScreen)
{
CODE REMOVED
AutoTransformCache atc = _autoTransformCache[contextID];
const osg::Matrix modelview = state.getModelViewMatrix();
const osg::Matrix projection = state.getProjectionMatrix();
CODE REMOVED
bool doUpdate = atc._traversalNumber==-1;
if (atc._traversalNumber=0)
{
if (atc._modelview!=modelview)
{
Re: [osg-users] Speeding Up osgText?
Jeremy I didn't pick up on OSG until July this year so I'm very much a
newbie. I've spent time playing around and reading the newsgroup but
have yet to do anything serious. Having read up on Pango I'm pretty
interested in your work and maybe i don't need to do anything - if only ;-)
Nick
Jeremy Moles wrote:
On Fri, 2008-09-05 at 22:53 +0100, Nick Bryan wrote:
Hi Ryan,
can't answer your question immediately but i am embarking on a lot of
work around osgText so thanks for the heads up and the detailed post.
I'll consider your points as i work through what i need to do. Will
obviously post feedback to the group.
I'd be very interested in know what and how and why you're doing
this. :)
I've been asking about some osgText for months to improve osgWidget, but
haven't really made any impressions I don't think (we're all pretty
busy, as it were).
As such, I have begun (and am almost finished!) writing an OSG NodeKit
called osgPango, which uses the Pango library to layout text, create
high-quality subpixel fonts renderings, etc. Whether or not anyone else
will be interested in it is hard to say, but I intend on using it for my
own purpose because I get superb font quality (even shadows and
outlines!) and a simplified API.
I had originally intended to just hack osgText, but the code is far too
complicated for me to grok. :) So I just ended up writing a different
NodeKit for it, which will be compaitble with osgWidget for sure (in the
form of osgPango::Label and osgPango::Input).
I have posted many times about osgText in the past, and if you would
like I can recall those links here for you to check out (particularly
with regards to quality--see osgfont--and the inability to insure that
all quads are pixel-aligned and that I can access the extents of each
text glyph individually for input...)
rgds
Nick
Kawicki, Ryan H wrote:
This is in reference to a previous question that has been posed. Sorry
if this has already been addressed.
http://lists.openscenegraph.org/htdig.cgi/osg-users-openscenegraph.org/2
008-April/009652.html
Our application seems to be hitting this same issue. We are trying to
render quite a bit of text on the screen, and we seem to be getting
burned by both the setText( ... ) and the drawImplementation.
We are currently using an older version of OSG, but we are planning on
moving to 2.6.0 relatively soon. I have looked at our current version
of osgText and the 2.6.0 version and can conclude that this will still
be an issue.
Our application is building the text shapes with SCREEN_COORDS for the
character size mode and SCREEN for axis alignment.
What I have noticed is that for each text shape update, the function
computeGlyphRepresentation is called to recompute the glyph information.
This function then calls the function computePositions. Here is what
compute positions looks like.
void Text::computePositions()
{
unsigned int size =
osg::maximum(osg::DisplaySettings::instance()-getMaxNumberOfGraphicsCon
texts(),_autoTransformCache.size());
// FIXME: OPTIMIZE: This would be one of the ideal locations to
// call computeAverageGlypthWidthAndHeight(). It is out of the
contextID loop
// so the value would be computed fewer times. But the code will
need changes
// to get the value down to the locations it is needed. (Either pass
through parameters
// or member variables, but we would need a system to know if the
values are stale.)
for(unsigned int i=0;isize;++i)
{
computePositions(i);
}
}
As can be seen by the first line, the maximum size is being obtained
from the maximum number of graphics contexts or the size of
_autoTransformCache. For me this is set to 32, since the default was
never being changed. The computePositions function is a very expensive
operation, and a minor flaw in our design was causing a huge impact in
performance. It might be a good idea to either assert on or to check
the traversalNumber from the _autoTransformCache to make sure the
context is a valid one.
Performance is still down for our application. I think some of the
problem is related to this computePositions function still. Our
application is frequently setting text, so we incur a CPU hit to
recalculate all the glyph vertices. When the text is visible, we incur
the same CPU hit to recalculate all the glyph vertices since the
_autoTransformCache model view matrix are always different between the
update of the text and the current state of the draw phase. Here's the
draw implementation for text.
void Text::drawImplementation(osg::State state) const
{
unsigned int contextID = state.getContextID();
CODE REMOVED
if (_characterSizeMode!=OBJECT_COORDS || _autoRotateToScreen)
{
CODE REMOVED
AutoTransformCache atc = _autoTransformCache[contextID];
const osg::Matrix modelview = state.getModelViewMatrix();
const osg::Matrix projection = state.getProjectionMatrix();
