Must i always call draw ? (glOrtho; performance issues)

[25maxi25maxi25]

Hello

I paint a lot lines (for example in a 5000x5000 area) and display a part with ortho2D (for example 400x400).
I scroll during the world-coordinates (set other values for Ortho2D), but nothing is updated until i (clear and) redraw all lines.
Because no data change i think, it must exist a solution to force a redraw (on screen) without put all lines again into the pipeline...

I have litte performance troubles (call paint require around one second) and so i want ask, if i can improve my program.

swapbuffer, glFlush, glFinish does not update my screen to the new ortho window.

Similar problem, if i change the color of one line... (why) must i draw all lines again ??

General question:
How much objects can i draw without a visible delay ?
I have test and aprox 120000 lines in one second - is this a possible value for a good card ?

Filter not visible lines in my programm will not solve my performance problem,
because the first filter (glScissor) in the pipline remove those lines ... is this correct ?

Thanks for any suggestions
martin

[ZbuffeR]

You may use a display list to avoid re-sending all lines to Opengl. How many lines do you send ?

But your bottleneck is likely to be the line rendering, often consumer 3d cards are not so fast with lines, they prefer textured triangles.

>> Filter not visible lines in my programm will not solve my performance problem,
It may be a good idea though.
Results mostly depends on your hardware/softawer setup.
What is your card/drivers/OS etc ?

[25maxi25maxi25]

The number of lines depend on my data that i visualize (it is like a 2D-CAD picture).
Currently about 3000 but this is only a test sample - i know thats less than 120000 lines,
but so i think it should work without delays...
The speed depend on the (world) size. If i zoom out, i need more time for paint, scroll goes slower...
so i check general limitation...

Currently i have not used display lists, but i will try...

I use win2k (2200MHz, 512 MB RAM) NVIDEA GForce MX 440 with pyopengl (same result with cygwin/c).

A second test on winxp (450 Mhz, 200 MB RAM), ATI Xpert Rage 128 need 3-4 seconds for 120000 lines.

[25maxi25maxi25]

The display list solves the problems with scroll )).

Paint still slow (nothing changed), but when i use list, it will become faster (i hope).

I have a new performance question:

I can paint a line on (1000, 1000 to (1001, 1001)
or
paint all in origin (line (0, 0), (1, 1)) and
then translate.

I have read its better to use glTranslate() insteaet of glMultMatrix, but nothing about painting relative (and move) or absolute.

Thanks

[ZbuffeR]

>> The display list solves the problems with scroll )).
>> Paint still slow (nothing changed), but when i use list, it will become faster (i hope).
Sorry I do not understand, did you used display lists or not ? Don't forget to compile only once, and do only callList each frame.

If you use a display list, you will draw everything allways at the same coords, and one glTranslate to scroll all of them at once.
In generall it is better to have the fewer GL calls, so avoid things like :

for (each line) {
glTranslate(xxx)
glBegin(lines)
glVertex(1)
glVertex(2)
glEnd
}

>> I have read its better to use glTranslate() insteaet of glMultMatrix,
Well, not sure about this. You may want to benchmark it on your machine, but I would say it is quite the same performance wise.

[ZbuffeR]

>> GForce MX 440
Here is where the problem comes from !
In fact those MX cards are not so good.
I did a very quick test, 640x480 window, with lots of diagonal lines, I get about 400 000 lines per seconds with my geforce3 in immediate mode (no DL).
If the lines are smaller, (ie only one pixel) I get about 3 000 000 per second.
So display list may not really help you. It seems to be the card memory bandwidth problem.

Make sure you don't have any antialiasing or line smoothing enabled.

[25maxi25maxi25]

hello

Now i use display lists.
You are right - generate the first picture is still slow ( i will improve my calculations), but
interaction (reuse a lot lists - scroll for example) is now very fast ).

3 000 000 lines.. .. i am far away..

Thanks for your help and suggestions !
martin