Hi all,

I have an application that requires the drawing of lines and arcs of varying
widths.  Because arcs are displayed as a bunch of tiny lines, we end up with
a bunch of vertices.  For instance, a medium-sized model might contain
between 1 and 2 million vertices.  This one model can be displayed in up to
15 different viewports (1-D, 2-D, and 3-D).

For medium-sized models, if I display several viewports, everything is fine,
as long as I am not displaying a 3-D viewport.  If I display, say, 6
viewports, and one is a 3-D viewport, the system grinds to a halt while
trying to display the 3-D viewport.  I can display 9 viewports reasonably
well as long as they are 1- and 2-D.  If I want to display a 3-D viewport, I
can only display 2 or 3 others with it.

Our application is pseudo-client-server, meaning that we have a back-end
thread that processes the model and sends lines and arcs to the client
thread.  The client thread takes care of displaying the information received
from the server thread.  I mention this because the client thread has no
idea of the size of the model until it has received the last line or arc.  I
used to shove all lines and arcs into a single display list, but apparently,
when a display list gets very big, the performance drops way off (at least,
that was my experience).  So I cooked up a scheme to split the drawing among
100 display lists (per viewport).  This solved the performance problem for
individual viewports, but I still have the problem I described above.

Thinking that the 3-D display list is heavier than its 1- and 2-D
counterparts (another point per vertex), I allocated 400 display lists per
3-D viewport and 50 for each of the others.  This had no effect.

I would really appreciate any insight you all might have.  I hope I have
provided enough information.

Thanks in advance!

JAB

"John A. Byerly" <jbyerly_REMOVE@ess-quality.com> wrote in message 
news:AAMAh.5638$8b1.1698@trndny03...
> Hi all,
>
> I have an application that requires the drawing of lines and arcs of 
> varying
> widths.  Because arcs are displayed as a bunch of tiny lines, we end up 
> with
> a bunch of vertices.  For instance, a medium-sized model might contain
> between 1 and 2 million vertices.  This one model can be displayed in up 
> to
> 15 different viewports (1-D, 2-D, and 3-D).
>
> For medium-sized models, if I display several viewports, everything is 
> fine,
> as long as I am not displaying a 3-D viewport.  If I display, say, 6
> viewports, and one is a 3-D viewport, the system grinds to a halt while
> trying to display the 3-D viewport.  I can display 9 viewports reasonably
> well as long as they are 1- and 2-D.  If I want to display a 3-D viewport, 
> I
> can only display 2 or 3 others with it.
>
> Our application is pseudo-client-server, meaning that we have a back-end
> thread that processes the model and sends lines and arcs to the client
> thread.  The client thread takes care of displaying the information 
> received
> from the server thread.  I mention this because the client thread has no
> idea of the size of the model until it has received the last line or arc. 
> I
> used to shove all lines and arcs into a single display list, but 
> apparently,
> when a display list gets very big, the performance drops way off (at 
> least,
> that was my experience).  So I cooked up a scheme to split the drawing 
> among
> 100 display lists (per viewport).  This solved the performance problem for
> individual viewports, but I still have the problem I described above.
>
> Thinking that the 3-D display list is heavier than its 1- and 2-D
> counterparts (another point per vertex), I allocated 400 display lists per
> 3-D viewport and 50 for each of the others.  This had no effect.
>
> I would really appreciate any insight you all might have.  I hope I have
> provided enough information.
>
> Thanks in advance!
>
> JAB
>
>
>
>

1) You didn't describe your hardware environment. If you are trying to draw 
multiple millions of vectors
with a software renderer, you;ll have trouble. What does 
glGetString(GL_RENDERER) tell you ?


2) Are you building new display lists every time you draw? If so, it's not 
worth doing. Don't use display lists unless you
can draw what's in the same display list over & over again many, many times. 
Creating a display list is very slow; just don't do it & your draw calls 
will be faster. They'll be much faster if you use vertex buffers.

3) are you using one opengl context for all 9--15 windows?  Context 
switching between 15 of them will be expensive.

Hope these pointers help.

jbw 

"John A. Byerly" wrote:
> 
> as long as I am not displaying a 3-D viewport.  If I display, say, 6
> viewports, and one is a 3-D viewport, the system grinds to a halt while
> trying to display the 3-D viewport.

There is no difference between 2D and 3D in OpenGL
(it's what we call "homogeneous coordinates").

The problem must be elsewhere.


-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.


We�re judging how a candidate will handle a nuclear
crisis by how well his staff creates campaign ads.
It�s a completely nonsensical process.

"fungus" <umailMY@SOCKSartlum.com> wrote in message
news:FzUAh.546$ak1.101@news.ono.com...
> "John A. Byerly" wrote:
> >
> > as long as I am not displaying a 3-D viewport.  If I display, say, 6
> > viewports, and one is a 3-D viewport, the system grinds to a halt while
> > trying to display the 3-D viewport.
>
> There is no difference between 2D and 3D in OpenGL
> (it's what we call "homogeneous coordinates").

I suspected this might be the case, but I thought it was worth a shot.

> The problem must be elsewhere.

Thanks.  I'll keep looking.

JAB

"jbwest" <jbwest@comcast.net> wrote in message
news:4K-dncoJAZNeS07YnZ2dnUVZ_oernZ2d@comcast.com...
>
> "John A. Byerly" <jbyerly_REMOVE@ess-quality.com> wrote in message
> news:AAMAh.5638$8b1.1698@trndny03...
> > Hi all,
> >
> > I have an application that requires the drawing of lines and arcs of
> > varying
> > widths.  Because arcs are displayed as a bunch of tiny lines, we end up
> > with
> > a bunch of vertices.  For instance, a medium-sized model might contain
> > between 1 and 2 million vertices.  This one model can be displayed in up
> > to
> > 15 different viewports (1-D, 2-D, and 3-D).
> >
> > For medium-sized models, if I display several viewports, everything is
> > fine,
> > as long as I am not displaying a 3-D viewport.  If I display, say, 6
> > viewports, and one is a 3-D viewport, the system grinds to a halt while
> > trying to display the 3-D viewport.  I can display 9 viewports
reasonably
> > well as long as they are 1- and 2-D.  If I want to display a 3-D
viewport,
> > I
> > can only display 2 or 3 others with it.
> >
> > Our application is pseudo-client-server, meaning that we have a back-end
> > thread that processes the model and sends lines and arcs to the client
> > thread.  The client thread takes care of displaying the information
> > received
> > from the server thread.  I mention this because the client thread has no
> > idea of the size of the model until it has received the last line or
arc.
> > I
> > used to shove all lines and arcs into a single display list, but
> > apparently,
> > when a display list gets very big, the performance drops way off (at
> > least,
> > that was my experience).  So I cooked up a scheme to split the drawing
> > among
> > 100 display lists (per viewport).  This solved the performance problem
for
> > individual viewports, but I still have the problem I described above.
> >
> > Thinking that the 3-D display list is heavier than its 1- and 2-D
> > counterparts (another point per vertex), I allocated 400 display lists
per
> > 3-D viewport and 50 for each of the others.  This had no effect.
> >
> > I would really appreciate any insight you all might have.  I hope I have
> > provided enough information.
> >
> > Thanks in advance!
> >
> > JAB
> >
> >
> >
> >
>
> 1) You didn't describe your hardware environment. If you are trying to
draw
> multiple millions of vectors
> with a software renderer, you;ll have trouble. What does
> glGetString(GL_RENDERER) tell you ?
>
>
> 2) Are you building new display lists every time you draw? If so, it's not
> worth doing. Don't use display lists unless you
> can draw what's in the same display list over & over again many, many
times.
> Creating a display list is very slow; just don't do it & your draw calls
> will be faster. They'll be much faster if you use vertex buffers.
>
> 3) are you using one opengl context for all 9--15 windows?  Context
> switching between 15 of them will be expensive.
>
> Hope these pointers help.
>
> jbw

1) Sorry.  I am running on a Gateway laptop.  glGetString(GL_RENDERER) ==
"MOBILITY RADEON 9700 x86/SSE2"

2) I build the display lists to boost performance with panning and
minimize/maximize.  The display lists are rebuilt for zooming and window
resizing (unfortunate, but necessary).  As for vertex buffers (vertex
arrays?), I looked into this, but there are enough shapes intermingled
(GL_LINES, GL_LINE_STRIP, GL_QUADS, and GL_QUAD_STRIP) that I figured it
would be a mess to manage.

3) I created a separate context for each viewport.  I tried to use a single
context, but was unsuccessful.  I have a Splitter Window object, which
contains any number of Pane objects (the Pane is the viewport).  A Pane
simply draws stuff, and the Splitter Window manages the size and placement
of each pane, and allows the user to dynamically change the size of the
Panes. Both objects support user interaction via the mouse.  I tried
creating a context and sharing it amongst the Pane objects, but that didn't
work.  I suspect that in order to use a single context for all viewports, I
would need to combine the Splitter Window and the Pane objects into one
object.  Do you agree?  Or could I retain my current objects and have OpenGL
draw to a context "on top of" each Pane?  In other words, the OpenGL context
essentially covers the whole area of the Splitter Window, but draws to
viewports that correspond to the area of each Pane.  Did that make any
sense?  I saw a NeHe tutorial where the guy draws 4 separate perspectives by
creating viewports on each frame update.  Apparently this operation is
pretty fast, because the animation was very smooth.

Thanks for your help!

JAB

John A. Byerly wrote:
> I have an application that requires the drawing of lines and arcs of
> varying
> widths.  Because arcs are displayed as a bunch of tiny lines, we end up
> with
> a bunch of vertices.  For instance, a medium-sized model might contain
> between 1 and 2 million vertices.

Can you simplify the geometry without altering the result significantly
(e.g. multiresolution methods, level of detail) to reduce that vertex
count?

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet

Jon Harrop wrote:
> John A. Byerly wrote:
>> Because arcs are displayed as a bunch of tiny lines, we end up
>> with
>> a bunch of vertices.  For instance, a medium-sized model might contain
>> between 1 and 2 million vertices.
> 
> Can you simplify the geometry without altering the result significantly
> (e.g. multiresolution methods, level of detail) to reduce that vertex
> count?
> 

eg If two lines have matching end->start points
then you could merge them into a single line if
they have similar slope.


-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.


We�re judging how a candidate will handle a nuclear
crisis by how well his staff creates campaign ads.
It�s a completely nonsensical process.

"John A. Byerly" <jbyerly_REMOVE@ess-quality.com> wrote in message 
news:oj_Ah.4037$103.3831@trndny05...
>
> "jbwest" <jbwest@comcast.net> wrote in message
> news:4K-dncoJAZNeS07YnZ2dnUVZ_oernZ2d@comcast.com...
>>
>> "John A. Byerly" <jbyerly_REMOVE@ess-quality.com> wrote in message
>> news:AAMAh.5638$8b1.1698@trndny03...
>> > Hi all,
>> >
>> > I have an application that requires the drawing of lines and arcs of
>> > varying
>> > widths.  Because arcs are displayed as a bunch of tiny lines, we end up
>> > with
>> > a bunch of vertices.  For instance, a medium-sized model might contain
>> > between 1 and 2 million vertices.  This one model can be displayed in 
>> > up
>> > to
>> > 15 different viewports (1-D, 2-D, and 3-D).
>> >
>> > For medium-sized models, if I display several viewports, everything is
>> > fine,
>> > as long as I am not displaying a 3-D viewport.  If I display, say, 6
>> > viewports, and one is a 3-D viewport, the system grinds to a halt while
>> > trying to display the 3-D viewport.  I can display 9 viewports
> reasonably
>> > well as long as they are 1- and 2-D.  If I want to display a 3-D
> viewport,
>> > I
>> > can only display 2 or 3 others with it.
>> >
>> > Our application is pseudo-client-server, meaning that we have a 
>> > back-end
>> > thread that processes the model and sends lines and arcs to the client
>> > thread.  The client thread takes care of displaying the information
>> > received
>> > from the server thread.  I mention this because the client thread has 
>> > no
>> > idea of the size of the model until it has received the last line or
> arc.
>> > I
>> > used to shove all lines and arcs into a single display list, but
>> > apparently,
>> > when a display list gets very big, the performance drops way off (at
>> > least,
>> > that was my experience).  So I cooked up a scheme to split the drawing
>> > among
>> > 100 display lists (per viewport).  This solved the performance problem
> for
>> > individual viewports, but I still have the problem I described above.
>> >
>> > Thinking that the 3-D display list is heavier than its 1- and 2-D
>> > counterparts (another point per vertex), I allocated 400 display lists
> per
>> > 3-D viewport and 50 for each of the others.  This had no effect.
>> >
>> > I would really appreciate any insight you all might have.  I hope I 
>> > have
>> > provided enough information.
>> >
>> > Thanks in advance!
>> >
>> > JAB
>> >
>> >
>> >
>> >
>>
>> 1) You didn't describe your hardware environment. If you are trying to
> draw
>> multiple millions of vectors
>> with a software renderer, you;ll have trouble. What does
>> glGetString(GL_RENDERER) tell you ?
>>
>>
>> 2) Are you building new display lists every time you draw? If so, it's 
>> not
>> worth doing. Don't use display lists unless you
>> can draw what's in the same display list over & over again many, many
> times.
>> Creating a display list is very slow; just don't do it & your draw calls
>> will be faster. They'll be much faster if you use vertex buffers.
>>
>> 3) are you using one opengl context for all 9--15 windows?  Context
>> switching between 15 of them will be expensive.
>>
>> Hope these pointers help.
>>
>> jbw
>
> 1) Sorry.  I am running on a Gateway laptop.  glGetString(GL_RENDERER) ==
> "MOBILITY RADEON 9700 x86/SSE2"
>
> 2) I build the display lists to boost performance with panning and
> minimize/maximize.  The display lists are rebuilt for zooming and window
> resizing (unfortunate, but necessary).  As for vertex buffers (vertex
> arrays?), I looked into this, but there are enough shapes intermingled
> (GL_LINES, GL_LINE_STRIP, GL_QUADS, and GL_QUAD_STRIP) that I figured it
> would be a mess to manage.
>
> 3) I created a separate context for each viewport.  I tried to use a 
> single
> context, but was unsuccessful.  I have a Splitter Window object, which
> contains any number of Pane objects (the Pane is the viewport).  A Pane
> simply draws stuff, and the Splitter Window manages the size and placement
> of each pane, and allows the user to dynamically change the size of the
> Panes. Both objects support user interaction via the mouse.  I tried
> creating a context and sharing it amongst the Pane objects, but that 
> didn't
> work.  I suspect that in order to use a single context for all viewports, 
> I
> would need to combine the Splitter Window and the Pane objects into one
> object.  Do you agree?  Or could I retain my current objects and have 
> OpenGL
> draw to a context "on top of" each Pane?  In other words, the OpenGL 
> context
> essentially covers the whole area of the Splitter Window, but draws to
> viewports that correspond to the area of each Pane.  Did that make any
> sense?  I saw a NeHe tutorial where the guy draws 4 separate perspectives 
> by
> creating viewports on each frame update.  Apparently this operation is
> pretty fast, because the animation was very smooth.
>
> Thanks for your help!
>
> JAB
>
>

Hmm, switching between 9--15 contexts could be a problem. Try to test with a 
very degenerate, simple dataset. That might be the source of the slowdown.

You surely can (should) have all Panes use one context, they just need to 
(wgl/glx)MakeCurrent() on themselves before drawing.

"jbwest" <jbwest@comcast.net> wrote in message
news:8rydnbZBiP8hiUjYnZ2dnUVZ_ternZ2d@comcast.com...
>
> "John A. Byerly" <jbyerly_REMOVE@ess-quality.com> wrote in message
> news:oj_Ah.4037$103.3831@trndny05...
> >
> > "jbwest" <jbwest@comcast.net> wrote in message
> > news:4K-dncoJAZNeS07YnZ2dnUVZ_oernZ2d@comcast.com...
> >>
> >> "John A. Byerly" <jbyerly_REMOVE@ess-quality.com> wrote in message
> >> news:AAMAh.5638$8b1.1698@trndny03...
> >> > Hi all,
> >> >
> >> > I have an application that requires the drawing of lines and arcs of
> >> > varying
> >> > widths.  Because arcs are displayed as a bunch of tiny lines, we end
up
> >> > with
> >> > a bunch of vertices.  For instance, a medium-sized model might
contain
> >> > between 1 and 2 million vertices.  This one model can be displayed in
> >> > up
> >> > to
> >> > 15 different viewports (1-D, 2-D, and 3-D).
> >> >
> >> > For medium-sized models, if I display several viewports, everything
is
> >> > fine,
> >> > as long as I am not displaying a 3-D viewport.  If I display, say, 6
> >> > viewports, and one is a 3-D viewport, the system grinds to a halt
while
> >> > trying to display the 3-D viewport.  I can display 9 viewports
> > reasonably
> >> > well as long as they are 1- and 2-D.  If I want to display a 3-D
> > viewport,
> >> > I
> >> > can only display 2 or 3 others with it.
> >> >
> >> > Our application is pseudo-client-server, meaning that we have a
> >> > back-end
> >> > thread that processes the model and sends lines and arcs to the
client
> >> > thread.  The client thread takes care of displaying the information
> >> > received
> >> > from the server thread.  I mention this because the client thread has
> >> > no
> >> > idea of the size of the model until it has received the last line or
> > arc.
> >> > I
> >> > used to shove all lines and arcs into a single display list, but
> >> > apparently,
> >> > when a display list gets very big, the performance drops way off (at
> >> > least,
> >> > that was my experience).  So I cooked up a scheme to split the
drawing
> >> > among
> >> > 100 display lists (per viewport).  This solved the performance
problem
> > for
> >> > individual viewports, but I still have the problem I described above.
> >> >
> >> > Thinking that the 3-D display list is heavier than its 1- and 2-D
> >> > counterparts (another point per vertex), I allocated 400 display
lists
> > per
> >> > 3-D viewport and 50 for each of the others.  This had no effect.
> >> >
> >> > I would really appreciate any insight you all might have.  I hope I
> >> > have
> >> > provided enough information.
> >> >
> >> > Thanks in advance!
> >> >
> >> > JAB
> >> >
> >> >
> >> >
> >> >
> >>
> >> 1) You didn't describe your hardware environment. If you are trying to
> > draw
> >> multiple millions of vectors
> >> with a software renderer, you;ll have trouble. What does
> >> glGetString(GL_RENDERER) tell you ?
> >>
> >>
> >> 2) Are you building new display lists every time you draw? If so, it's
> >> not
> >> worth doing. Don't use display lists unless you
> >> can draw what's in the same display list over & over again many, many
> > times.
> >> Creating a display list is very slow; just don't do it & your draw
calls
> >> will be faster. They'll be much faster if you use vertex buffers.
> >>
> >> 3) are you using one opengl context for all 9--15 windows?  Context
> >> switching between 15 of them will be expensive.
> >>
> >> Hope these pointers help.
> >>
> >> jbw
> >
> > 1) Sorry.  I am running on a Gateway laptop.  glGetString(GL_RENDERER)
==
> > "MOBILITY RADEON 9700 x86/SSE2"
> >
> > 2) I build the display lists to boost performance with panning and
> > minimize/maximize.  The display lists are rebuilt for zooming and window
> > resizing (unfortunate, but necessary).  As for vertex buffers (vertex
> > arrays?), I looked into this, but there are enough shapes intermingled
> > (GL_LINES, GL_LINE_STRIP, GL_QUADS, and GL_QUAD_STRIP) that I figured it
> > would be a mess to manage.
> >
> > 3) I created a separate context for each viewport.  I tried to use a
> > single
> > context, but was unsuccessful.  I have a Splitter Window object, which
> > contains any number of Pane objects (the Pane is the viewport).  A Pane
> > simply draws stuff, and the Splitter Window manages the size and
placement
> > of each pane, and allows the user to dynamically change the size of the
> > Panes. Both objects support user interaction via the mouse.  I tried
> > creating a context and sharing it amongst the Pane objects, but that
> > didn't
> > work.  I suspect that in order to use a single context for all
viewports,
> > I
> > would need to combine the Splitter Window and the Pane objects into one
> > object.  Do you agree?  Or could I retain my current objects and have
> > OpenGL
> > draw to a context "on top of" each Pane?  In other words, the OpenGL
> > context
> > essentially covers the whole area of the Splitter Window, but draws to
> > viewports that correspond to the area of each Pane.  Did that make any
> > sense?  I saw a NeHe tutorial where the guy draws 4 separate
perspectives
> > by
> > creating viewports on each frame update.  Apparently this operation is
> > pretty fast, because the animation was very smooth.
> >
> > Thanks for your help!
> >
> > JAB
> >
> >
>
> Hmm, switching between 9--15 contexts could be a problem. Try to test with
a
> very degenerate, simple dataset. That might be the source of the slowdown.
>
> You surely can (should) have all Panes use one context, they just need to
> (wgl/glx)MakeCurrent() on themselves before drawing.

I cut the resolution of my arcs from 1/2 degree to 2 degrees and I was able
to display 11 panes (including 2 3-D panes).  This may be a workable
solution for me.

I just saw in another thread someone discussing the use of graphics card
memory and what happens if it fills up.  Since I am using display lists
pretty heavily, could this be my problem?  In other words, with medium and
large models (> 1 million vertices), could I be encountering a situation
where my graphics card memory is full and I am using system RAM?  If so, is
there anything to be gained by reducing the number of display lists (or
eliminating them altogether)?  Or will I have to play tricks with the model
itself to reduce the number of vertices?

Thanks!

JAB

"John A. Byerly" <jbyerly_REMOVE@ess-quality.com> wrote in message 
news:XxkBh.6$2w.4@trndny09...
>
> "jbwest" <jbwest@comcast.net> wrote in message
> news:8rydnbZBiP8hiUjYnZ2dnUVZ_ternZ2d@comcast.com...
>>
>> "John A. Byerly" <jbyerly_REMOVE@ess-quality.com> wrote in message
>> news:oj_Ah.4037$103.3831@trndny05...
>> >
>> > "jbwest" <jbwest@comcast.net> wrote in message
>> > news:4K-dncoJAZNeS07YnZ2dnUVZ_oernZ2d@comcast.com...
>> >>
>> >> "John A. Byerly" <jbyerly_REMOVE@ess-quality.com> wrote in message
>> >> news:AAMAh.5638$8b1.1698@trndny03...
>> >> > Hi all,
>> >> >
>> >> > I have an application that requires the drawing of lines and arcs of
>> >> > varying
>> >> > widths.  Because arcs are displayed as a bunch of tiny lines, we end
> up
>> >> > with
>> >> > a bunch of vertices.  For instance, a medium-sized model might
> contain
>> >> > between 1 and 2 million vertices.  This one model can be displayed 
>> >> > in
>> >> > up
>> >> > to
>> >> > 15 different viewports (1-D, 2-D, and 3-D).
>> >> >
>> >> > For medium-sized models, if I display several viewports, everything
> is
>> >> > fine,
>> >> > as long as I am not displaying a 3-D viewport.  If I display, say, 6
>> >> > viewports, and one is a 3-D viewport, the system grinds to a halt
> while
>> >> > trying to display the 3-D viewport.  I can display 9 viewports
>> > reasonably
>> >> > well as long as they are 1- and 2-D.  If I want to display a 3-D
>> > viewport,
>> >> > I
>> >> > can only display 2 or 3 others with it.
>> >> >
>> >> > Our application is pseudo-client-server, meaning that we have a
>> >> > back-end
>> >> > thread that processes the model and sends lines and arcs to the
> client
>> >> > thread.  The client thread takes care of displaying the information
>> >> > received
>> >> > from the server thread.  I mention this because the client thread 
>> >> > has
>> >> > no
>> >> > idea of the size of the model until it has received the last line or
>> > arc.
>> >> > I
>> >> > used to shove all lines and arcs into a single display list, but
>> >> > apparently,
>> >> > when a display list gets very big, the performance drops way off (at
>> >> > least,
>> >> > that was my experience).  So I cooked up a scheme to split the
> drawing
>> >> > among
>> >> > 100 display lists (per viewport).  This solved the performance
> problem
>> > for
>> >> > individual viewports, but I still have the problem I described 
>> >> > above.
>> >> >
>> >> > Thinking that the 3-D display list is heavier than its 1- and 2-D
>> >> > counterparts (another point per vertex), I allocated 400 display
> lists
>> > per
>> >> > 3-D viewport and 50 for each of the others.  This had no effect.
>> >> >
>> >> > I would really appreciate any insight you all might have.  I hope I
>> >> > have
>> >> > provided enough information.
>> >> >
>> >> > Thanks in advance!
>> >> >
>> >> > JAB
>> >> >
>> >> >
>> >> >
>> >> >
>> >>
>> >> 1) You didn't describe your hardware environment. If you are trying to
>> > draw
>> >> multiple millions of vectors
>> >> with a software renderer, you;ll have trouble. What does
>> >> glGetString(GL_RENDERER) tell you ?
>> >>
>> >>
>> >> 2) Are you building new display lists every time you draw? If so, it's
>> >> not
>> >> worth doing. Don't use display lists unless you
>> >> can draw what's in the same display list over & over again many, many
>> > times.
>> >> Creating a display list is very slow; just don't do it & your draw
> calls
>> >> will be faster. They'll be much faster if you use vertex buffers.
>> >>
>> >> 3) are you using one opengl context for all 9--15 windows?  Context
>> >> switching between 15 of them will be expensive.
>> >>
>> >> Hope these pointers help.
>> >>
>> >> jbw
>> >
>> > 1) Sorry.  I am running on a Gateway laptop.  glGetString(GL_RENDERER)
> ==
>> > "MOBILITY RADEON 9700 x86/SSE2"
>> >
>> > 2) I build the display lists to boost performance with panning and
>> > minimize/maximize.  The display lists are rebuilt for zooming and 
>> > window
>> > resizing (unfortunate, but necessary).  As for vertex buffers (vertex
>> > arrays?), I looked into this, but there are enough shapes intermingled
>> > (GL_LINES, GL_LINE_STRIP, GL_QUADS, and GL_QUAD_STRIP) that I figured 
>> > it
>> > would be a mess to manage.
>> >
>> > 3) I created a separate context for each viewport.  I tried to use a
>> > single
>> > context, but was unsuccessful.  I have a Splitter Window object, which
>> > contains any number of Pane objects (the Pane is the viewport).  A Pane
>> > simply draws stuff, and the Splitter Window manages the size and
> placement
>> > of each pane, and allows the user to dynamically change the size of the
>> > Panes. Both objects support user interaction via the mouse.  I tried
>> > creating a context and sharing it amongst the Pane objects, but that
>> > didn't
>> > work.  I suspect that in order to use a single context for all
> viewports,
>> > I
>> > would need to combine the Splitter Window and the Pane objects into one
>> > object.  Do you agree?  Or could I retain my current objects and have
>> > OpenGL
>> > draw to a context "on top of" each Pane?  In other words, the OpenGL
>> > context
>> > essentially covers the whole area of the Splitter Window, but draws to
>> > viewports that correspond to the area of each Pane.  Did that make any
>> > sense?  I saw a NeHe tutorial where the guy draws 4 separate
> perspectives
>> > by
>> > creating viewports on each frame update.  Apparently this operation is
>> > pretty fast, because the animation was very smooth.
>> >
>> > Thanks for your help!
>> >
>> > JAB
>> >
>> >
>>
>> Hmm, switching between 9--15 contexts could be a problem. Try to test 
>> with
> a
>> very degenerate, simple dataset. That might be the source of the 
>> slowdown.
>>
>> You surely can (should) have all Panes use one context, they just need to
>> (wgl/glx)MakeCurrent() on themselves before drawing.
>
> I cut the resolution of my arcs from 1/2 degree to 2 degrees and I was 
> able
> to display 11 panes (including 2 3-D panes).  This may be a workable
> solution for me.
>
> I just saw in another thread someone discussing the use of graphics card
> memory and what happens if it fills up.  Since I am using display lists
> pretty heavily, could this be my problem?  In other words, with medium and
> large models (> 1 million vertices), could I be encountering a situation
> where my graphics card memory is full and I am using system RAM?  If so, 
> is
> there anything to be gained by reducing the number of display lists (or
> eliminating them altogether)?  Or will I have to play tricks with the 
> model
> itself to reduce the number of vertices?
>
> Thanks!
>
> JAB
>
>
>


Are you sharing display lists or do each of the windows have not only the 
weight of theor own context but also theor own copies of the display list ? 
If so, 2 very big reasons why performance would be very bad.

jbw

> could I be encountering a situation
> where my graphics card memory is full and I am using system RAM?

Translation: "Can I use up all my RAM"?

Ummmm, that would be "yes"...

> If so, is there anything to be gained by reducing the
> number of display lists

Same answer.

 > (or eliminating them altogether)?

Think of your graphics RAM as a cache. If you're
thrashing the cache then you lose 100% of the
benefits it gives you.


-- 
<\___/>
/ O O \
\_____/  FTB.    For email, remove my socks.


We�re judging how a candidate will handle a nuclear
crisis by how well his staff creates campaign ads.
It�s a completely nonsensical process.

John A. Byerly wrote:
> I cut the resolution of my arcs from 1/2 degree to 2 degrees and I was
> able
> to display 11 panes (including 2 3-D panes).  This may be a workable
> solution for me.

I assume the data is shared between panes?

> I just saw in another thread someone discussing the use of graphics card
> memory and what happens if it fills up.  Since I am using display lists
> pretty heavily, could this be my problem?

Yes. Plot a graph of the performance vs complexity and see if it jumps. If
so, then it is likely to be a cache effect (e.g. caching in system memory
instead of on the graphics card).

> In other words, with medium and 
> large models (> 1 million vertices), could I be encountering a situation
> where my graphics card memory is full and I am using system RAM?

Absolutely.

> If so, 
> is there anything to be gained by reducing the number of display lists (or
> eliminating them altogether)?

I'd go for increasing the number of display lists first, so that each one is
smaller. Again, are you sharing data between display lists, e.g. by having
a single vertex array and multiple index arrays?

> Or will I have to play tricks with the model itself to reduce the number
> of vertices? 

You should always do that. It is easy and very effective.

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet

"Jon Harrop" <jon@ffconsultancy.com> wrote in message 
news:45d766b0$0$8741$ed2619ec@ptn-nntp-reader02.plus.net...
> John A. Byerly wrote:
>> I cut the resolution of my arcs from 1/2 degree to 2 degrees and I was
>> able
>> to display 11 panes (including 2 3-D panes).  This may be a workable
>> solution for me.
>
> I assume the data is shared between panes?
>
>> I just saw in another thread someone discussing the use of graphics card
>> memory and what happens if it fills up.  Since I am using display lists
>> pretty heavily, could this be my problem?
>
> Yes. Plot a graph of the performance vs complexity and see if it jumps. If
> so, then it is likely to be a cache effect (e.g. caching in system memory
> instead of on the graphics card).
>
>> In other words, with medium and
>> large models (> 1 million vertices), could I be encountering a situation
>> where my graphics card memory is full and I am using system RAM?
>
> Absolutely.
>
>> If so,
>> is there anything to be gained by reducing the number of display lists 
>> (or
>> eliminating them altogether)?
>
> I'd go for increasing the number of display lists first, so that each one 
> is
> smaller. Again, are you sharing data between display lists, e.g. by having
> a single vertex array and multiple index arrays?
>
>> Or will I have to play tricks with the model itself to reduce the number
>> of vertices?
>
> You should always do that. It is easy and very effective.
>
> -- 
> Dr Jon D Harrop, Flying Frog Consultancy
> OCaml for Scientists
> http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet


it sounds to me like you have a new set of display lists for each window and 
each separate context; an extremly wasteful strategy.

jbw

Hello,
> 
> I cut the resolution of my arcs from 1/2 degree to 2 degrees and I was able
> to display 11 panes (including 2 3-D panes).  This may be a workable
> solution for me.

May I ask why are you using such a resolution for drawing arcs?

IMHO, it is bit to extensive, full circle would be drawn using 720 
segments (1/2 deg resolution), which implies that all segments would be 
just couple of dots of length, or even less, if the viewport is smaller.

Just for the reference, HPGL/2, Packard's plot language, by default uses 
5 degrees resolution while drawing arcs (72 segment's for full circle).


best regards,
Gordan

"jbwest" <jbwest@comcast.net> wrote in message
news:fMqdna_ALaD4QEXYnZ2dnUVZ_qemnZ2d@comcast.com...
>
> it sounds to me like you have a new set of display lists for each window
and
> each separate context; an extremly wasteful strategy.

I do, and I suspect this is the problem.

This project has been a trial by fire for me, so I have made some bad
decisions along the way while I learned OpenGL.

Since we are so close to a release, my boss wants me to get the performance
to a reasonable level quickly.  Unfortunately, that means I won't have time
to rearrange my design to use a single context.  Every time I try to use a
single context, I have problems, so I will have to start from ground level
and go from there.

Thanks for your help!

JAB

"Jon Harrop" <jon@ffconsultancy.com> wrote in message
news:45d766b0$0$8741$ed2619ec@ptn-nntp-reader02.plus.net...
> John A. Byerly wrote:
> > I cut the resolution of my arcs from 1/2 degree to 2 degrees and I was
> > able
> > to display 11 panes (including 2 3-D panes).  This may be a workable
> > solution for me.
>
> I assume the data is shared between panes?

Yes, but maybe not in the way you mean.  I have two classes, one for lines,
the other for arcs.  A collection of these is contained in my model object.
I build the display lists by iterating the collection and having the line
and arc objects draw themselves.

> > I just saw in another thread someone discussing the use of graphics card
> > memory and what happens if it fills up.  Since I am using display lists
> > pretty heavily, could this be my problem?
>
> Yes. Plot a graph of the performance vs complexity and see if it jumps. If
> so, then it is likely to be a cache effect (e.g. caching in system memory
> instead of on the graphics card).

This seems to be the case.

> > In other words, with medium and
> > large models (> 1 million vertices), could I be encountering a situation
> > where my graphics card memory is full and I am using system RAM?
>
> Absolutely.
>
> > If so,
> > is there anything to be gained by reducing the number of display lists
(or
> > eliminating them altogether)?
>
> I'd go for increasing the number of display lists first, so that each one
is
> smaller. Again, are you sharing data between display lists, e.g. by having
> a single vertex array and multiple index arrays?

I did try this (both increasing and decreasing the number of display lists,
actually).  Neither modification had any effect.  But if I am overloading my
graphics RAM, I don't imagine this would help anyway.

> > Or will I have to play tricks with the model itself to reduce the number
> > of vertices?
>
> You should always do that. It is easy and very effective.

Unfortunately, I am just now coming to that realization.  I am decreasing
the resolution on my arcs and implementing an algorithm to combine lines of
similar slopes (suggestions made in this thread, I must mention).  My boss
is a bit concerned about arcs looking "chunky" at extreme zooms, but we can
address that if it is a problem.

I think my big performance problem is my use of multiple contexts (another
point made in this thread.  Thanks!).  I just won't have the time to fix
that problem for this release.

JAB

"Leclerc" <gordan.sikic.remove@this.inet.hr> wrote in message
news:ercvb3$ntm$1@sunce.iskon.hr...
> Hello,
> >
> > I cut the resolution of my arcs from 1/2 degree to 2 degrees and I was
able
> > to display 11 panes (including 2 3-D panes).  This may be a workable
> > solution for me.
>
> May I ask why are you using such a resolution for drawing arcs?
>
> IMHO, it is bit to extensive, full circle would be drawn using 720
> segments (1/2 deg resolution), which implies that all segments would be
> just couple of dots of length, or even less, if the viewport is smaller.
>
> Just for the reference, HPGL/2, Packard's plot language, by default uses
> 5 degrees resolution while drawing arcs (72 segment's for full circle).

Thanks for the info.  I have made the arc resolution configurable, and using
4 degrees resolution really cuts down on the number of vertices in the
model.  The big reason for the extreme resolution was the fear that arcs
will look "chunky" at close zoom.  I guess we will cross that bridge when we
get to it.

JAB

On Wed, 14 Feb 2007 23:05:04 GMT, "John A. Byerly"
<jbyerly_REMOVE@ess-quality.com> wrote:

>I would really appreciate any insight you all might have.  I hope I have
>provided enough information.

A bit late, and not really an OpenGL solution, but could you
change the resolution of your arcs depending on the size
of the viewport? An arc with 1000 vertices seen over only
a few pixels could be faster represented with only 10
vertices. Not sure how practical this is in your case,
but I've heard this sort of technique be used in games.
(The further away the object, the simpler the model)


Easy to use graphics effects:
http://www.ransen.com/

"Owen Ransen" <willy@wonker.com> wrote in message
news:2snrt2h65sjhvf6g1gr8j8l6jk2g5lqqfg@4ax.com...
> On Wed, 14 Feb 2007 23:05:04 GMT, "John A. Byerly"
> <jbyerly_REMOVE@ess-quality.com> wrote:
>
> >I would really appreciate any insight you all might have.  I hope I have
> >provided enough information.
>
> A bit late, and not really an OpenGL solution, but could you
> change the resolution of your arcs depending on the size
> of the viewport? An arc with 1000 vertices seen over only
> a few pixels could be faster represented with only 10
> vertices. Not sure how practical this is in your case,
> but I've heard this sort of technique be used in games.
> (The further away the object, the simpler the model)

Thanks for the suggestion.  I just finished a conversation in which we
decided to do our arcs in terms of pixels per chord.  Basically, this means
that the resolution of our arcs will be visually appealing, regardless of
their apparent size.

Also in this conversation, I found out that I really overdid the original
arc resolution of 1/2 degree.  Way too many vertices for no visual benefit.

Thanks!

JAB

John A. Byerly wrote:
> Yes, but maybe not in the way you mean.  I have two classes, one for
> lines,
> the other for arcs.  A collection of these is contained in my model
> object. I build the display lists by iterating the collection and having
> the line and arc objects draw themselves.

Does the same vertex information appear in many different display lists?

>> > I just saw in another thread someone discussing the use of graphics
>> > card
>> > memory and what happens if it fills up.  Since I am using display lists
>> > pretty heavily, could this be my problem?
>>
>> Yes. Plot a graph of the performance vs complexity and see if it jumps.
>> If so, then it is likely to be a cache effect (e.g. caching in system
>> memory instead of on the graphics card).
> 
> This seems to be the case.

Then you should try anything that might reduce the amount of RAM required on
the graphics card.

>> I'd go for increasing the number of display lists first, so that each one
> is
>> smaller. Again, are you sharing data between display lists, e.g. by
>> having a single vertex array and multiple index arrays?
> 
> I did try this (both increasing and decreasing the number of display
> lists,
> actually).  Neither modification had any effect.  But if I am overloading
> my graphics RAM, I don't imagine this would help anyway.

It might not help, it might make it worse. But that gives you information
about where the bottleneck is.

>> > Or will I have to play tricks with the model itself to reduce the
>> > number of vertices?
>>
>> You should always do that. It is easy and very effective.
> 
> Unfortunately, I am just now coming to that realization.  I am decreasing
> the resolution on my arcs and implementing an algorithm to combine lines
> of
> similar slopes (suggestions made in this thread, I must mention).  My boss
> is a bit concerned about arcs looking "chunky" at extreme zooms, but we
> can address that if it is a problem.

Use a multiresolution technique to flatten lines as much as possible whilst
remaining insignificantly different, i.e. as a function of the zoom.

> I think my big performance problem is my use of multiple contexts (another
> point made in this thread.  Thanks!).  I just won't have the time to fix
> that problem for this release.

Right. If you've got the "same" display list in multiple contexts then 

-- 
Dr Jon D Harrop, Flying Frog Consultancy
OCaml for Scientists
http://www.ffconsultancy.com/products/ocaml_for_scientists/index.html?usenet

John A. Byerly wrote:
> I won't have time to rearrange my design to use a single context.

You don't necessarily need a single context, just a single
set of display lists shared between your contexts. Most
OpenGL implementations provide an option when you create
a context to have it share display lists and textures with
another context.

--
Greg