Polyline slow
john wayne
thousand of points and it is fast to draw a second array of data with
the same dimension of the first one. The only difference in the two
arrays is that the first graph is less linear than the second but the
time to elaborate it is about ten times than the second. Ten times!!??
Is it possible? How can I make it faster
YoungJin Shin
I tested Polyline with one thousand random data, but it's not slow.
Also, I can't catch any difference between data sets. Could you show
me the test code or data?
john wayne
> I tested Polyline with one thousand random data, but it's not slow.
> Also, I can't catch any difference between data sets. Could you show
> me the test code or data?
I've tested it too a lot of times but this is the first time I see
this thing. At this moment i don't understand what happen, why
polyline is so slow, I test its speed using GetTickCount() and with
two arrays of CPoint data I see that one is slow at least ten times
than the other one. Have you any idea how I can find where is the
slowdown? What is causing it?
john wayne
I've found where is the problem :(. All data in the array are ok but
when I try to draw the graph with polyline I see the slowdown. The
problem is in the width of the Pen that I use to draw. Using a pen
with width 1 I see that polyline work very fine, but using width 2 or
3 it become very slow. More width more slow.
YoungJin Shin
I got it. 2 width pen is incredibly slower than 1 width pen. But I
think that it's reasonable time. I can't feel anything related drawing
speed. Tick count variable is the only thing which shows me the
difference of drawing speed.
If you want to make it faster, you should reduce the point data. One
general way is drawing points in visible area.
Tim Roberts
Absolutely correct. Lines of width 1 (or 0) can be accelerated by even
very primitive graphics hardware. Lines wider than 1, called "geometric
wide lines," are actually drawn as filled polygons, and are not accelerated
nearly as well.
--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.
Alan Carre
news:8167f5ef-3051-4dbd...@a29g2000pra.googlegroups.com...
That's because it's using a process called "dithering" to make the line
appear "smooth / straight". Just find any article on dithering and you'll
see why it is so slow. Lots of averaging going on, and various extra
(near-invisible) pixels drawn to produce this effect. Maybe there's a flag
to turn off dithering if you really want a width-2 line (but it will look
very choppy!).
If you're just interested to see how the effect works, load up any paint
program (PSP for instance) and select the line-drawing tool. Select any
width you like and draw the an angled line, both with and without dithering.
From afar you'll see a dramatic difference in the quality of the line drawn.
Zoomed in you'll see how the effect is achieved.
- Alan Carre
Alan Carre
"dithering". My bad... either way.
In any case, the idea is to create the illusion of straightness where no
actual straight line can be drawn.
- Alan Carre
Ben Voigt [C++ MVP]
doesn't explain the change in speed from linewidth == 1 to linewidth > 1.
Tim explained that.
"Alan Carre" <al...@twilightgames.com> wrote in message
news:uQUF#YHXJH...@TK2MSFTNGP04.phx.gbl...
Alan Carre
news:02304918-F60C-4510...@microsoft.com...
> But also, the anti-aliasing step is needed for lines of any width, so it
> doesn't explain the change in speed from linewidth == 1 to linewidth > 1.
> Tim explained that.
Oh, ic. I didn't realize. I wonder why it can only do it for size 1 (invoke
HA)...
- Alan Carre
Alan Carre
news:02304918-F60C-4510...@microsoft.com...
> doesn't explain the change in speed from linewidth == 1 to linewidth > 1.
> Tim explained that.
Just thinking... given what Tim had to say... if you want a line of width 2+
then the answer is to simply draw 2+ lines offset perpendicular to the
direction of the line. Or you, if it's just size 3 something trvial like
this would do it (God help me if someone hasn't already posted this...):
MoveTo(x0,y0);
LineTo(x1,y1);
MoveTo(x0,y0-1);
LineTo(x1,y1-1);
MoveTo(x0,y0+1);
LineTo(x1,y1+1);
And there you go. Line of width 3, all anti-aliased and using Hardware
accel.
- Alan Carre
Ben Voigt [C++ MVP]
pixel 100% covered by a single width two line vs a pixel half covered by a
width one line and then also half covered by the other width one line. In
the first case your alpha is 1.0, in the second case only .75
"Alan Carre" <al...@twilightgames.com> wrote in message
news:uKW7CJIX...@TK2MSFTNGP03.phx.gbl...
Ben Voigt [C++ MVP]
antialiasing algorithm optimized for linewidth==1, while other linewidths
have to use the generic version.
"Alan Carre" <al...@twilightgames.com> wrote in message
news:u7JVF#HXJHA...@TK2MSFTNGP02.phx.gbl...
Alan Carre
> Except that under the alpha-blending rules, you get different results from
> a pixel 100% covered by a single width two line vs a pixel half covered by
> a width one line and then also half covered by the other width one line.
> In the first case your alpha is 1.0, in the second case only .75
Perhaps, but this might look good enough for his purposes. The important
thing is that the boundaries appear semi-correct and that it doesn't have
obvious "holes". One would have to try it and see how well it works. If it
looks ok and it's fast, why not? [of course you'd wrap it up in your own
DrawLine function so you don't have to write all that down]
- Alan Carre
P.S. And as well, one could always try to add some extra filling with
additional start-end permutations (ie. criss-crossing)...
Tim Roberts
>
>Just thinking... given what Tim had to say... if you want a line of width 2+
>then the answer is to simply draw 2+ lines offset perpendicular to the
>direction of the line. Or you, if it's just size 3 something trvial like
>this would do it (God help me if someone hasn't already posted this...):
>
>MoveTo(x0,y0);
>LineTo(x1,y1);
>MoveTo(x0,y0-1);
>LineTo(x1,y1-1);
>MoveTo(x0,y0+1);
>LineTo(x1,y1+1);
>
>And there you go. Line of width 3, all anti-aliased and using Hardware
>accel.
No, it's not that easy. Once lines get wider than one pixel, now you have
to worry about the line cap style: rounded, beveled, mitered. Plus, you
have to guarantee that two lines that meet at an angle don't leave
unattractive gaps.
The Windows GDI developers defined all of these rules very precisely in
order to produce the most pleasing representations. A graphics hardware
developer is required to make sure that his display is pixel-for-pixel
identical to the Windows standard for these lines. GDI doesn't even ASK
hardware to do wide lines. It just sends down a filled polygon.
By the way, GDI lines of width 1 are not anti-aliased, again because of the
pixel-accurate requirement.
Alan Carre
news:04m6k4psdgi04j2ek...@4ax.com...
> By the way, GDI lines of width 1 are not anti-aliased, again because of
> the
> pixel-accurate requirement.
That's not what Ben Voigt [C++ MVP] had to say about it. Quoting:
"Ben Voigt [C++ MVP]" <r...@nospam.nospam> wrote in message
news:69B39729-FED0-4593...@microsoft.com...
> My understanding is that the hardware has a specific instantiation of the
> antialiasing algorithm optimized for linewidth==1, while other linewidths
> have to use the generic version.
Although he doesn't seem 100% sure about it.
- Alan Carre
Alan Carre
> By the way, GDI lines of width 1 are not anti-aliased, again because of
> the
> pixel-accurate requirement.
Oh, I forgot to add... an anti-aliased line of width 1 is not only feasable,
it's quite normal. Here, have a look:
http://www.twilightgames.com/alantemp/dithered_line_at_1_pixel.png
Unless there's some other requirement that I'm unaware of, these are 1 pixel
thick, fully-dithered lines (the diagonal one shows this much more clearly
than the other, more slanted, ones).
- Alan Carre
Alan Carre
lexical-hiccup I guess ;)
ANTI-ALIASED! grrr.
- Alan Carre
http://www.twilightgames.com
Tim Roberts
>"Tim Roberts" <ti...@probo.com> wrote:
>> "Alan Carre" <al...@twilightgames.com> wrote:
>> By the way, GDI lines of width 1 are not anti-aliased, again because of
>> the > pixel-accurate requirement.
>
>Oh, I forgot to add... an anti-aliased line of width 1 is not only feasable,
>it's quite normal. Here, have a look:
>
>http://www.twilightgames.com/alantemp/dithered_line_at_1_pixel.png
>
>Unless there's some other requirement that I'm unaware of, these are 1 pixel
>thick, fully-dithered lines (the diagonal one shows this much more clearly
>than the other, more slanted, ones).
You are assuming that the application you examined is actually using the
GDI line drawing APIs. Applications that want antialiased lines (and many
do) draw them using their own algorithms. The line APIs won't do it.
Alan Carre
> You are assuming that the application you examined is actually using the
> GDI line drawing APIs. Applications that want antialiased lines (and many
> do) draw them using their own algorithms. The line APIs won't do it.
I am assuming nothing.
You said that 1 pixel width lines are not anti-aliased "due to the 1 pixel
width restriction" and I was pointing out that, as far as anti-aliasing is
concerned, that is not a "logical" restriction. One can draw anti-aliased
lines 1 pixel wide. I am saying only that "logically", width == 1 is not a
restriction.
Whether or not the GDI sees that as a restriction is another story (which I
think I noted quite clearly by saying "unless there's some other restriction
that I'm unaware of").
- Alan Carre
Ben Voigt [C++ MVP]
"Alan Carre" <al...@twilightgames.com> wrote in message
news:eug6m$RXJHA...@TK2MSFTNGP02.phx.gbl...
Well, there's more than one way to draw a polyline, and as this isn't a
graphics toolkit specific group but rather a C++ group, I'm having to
summarize a zillion different graphics and hardware combinations. Since I
mentioned alpha channel and hardware acceleration it's fairly certain I
wasn't thinking of vanilla GDI. The wide variation in hardware platforms
leads to considerable uncertainty, I was actually making an inference based
on Tim's earlier post about changing from line primitives to filled shapes,
and I didn't want to sound authoritative, just offer my interpretation of
Tim's comments.
I don't doubt that Tim is perfectly correct that GDI lines of width 1 are
not antialiased. But you sure can have GDI+ or OpenGL lines of width 1
which are, and anyone concerned about performance of 2-D graphing would
likely be using OpenGL (since DirectDraw seems to be obsolete leaving
Microsoft without a 2-D acceleration API until WPF came out).
>
> - Alan Carre
>
>
Tamas Demjen
> Absolutely correct. Lines of width 1 (or 0) can be accelerated by even
> very primitive graphics hardware. Lines wider than 1, called "geometric
> wide lines," are actually drawn as filled polygons, and are not accelerated
> nearly as well.
I confirm that. I maintain a virtual PDF printer driver, and thick lines
are coming through as filled paths. If the miter is angled, that means
a filled polygon, but if it's rounded, it involves Bezier curves as
well. It is significantly more complex to render than a single 1-pixel
line, even if it's accelerated.
On the other hand, applications can render the same content various
different ways. For example, a line in Adobe Illustrator or Fireworks
doesn't get painted as a GDI line. We explained how GDI works. Not every
application uses GDI to paint lines. Even GDI+ works differently (it
doesn't use hardware acceleration). In GDI+ you can turn anti-aliasing
on and off.
Another possibility is to use Direct X.
Tom
john wayne
If used the pen with 2 or more width chose not aliased which is faster
than an aliased version. OpenGL and Direct Draw are another speech
Tim Roberts
>
>In anyway polyline could have both functions aliased and not aliased.
>If used the pen with 2 or more width chose not aliased which is faster
>than an aliased version.
Of course it COULD, but that's not the point. The FACT is that GDI and GDI
drivers do not to antialiasing on lines. Plain and simple. Sure, there
are lots of other ways to draw lines. Those ways have their own
guarantees.
>OpenGL and Direct Draw are another speech
DirectDraw doesn't do lines, but OpenGL and Direct3D do, and they can
certainly do antialiasing.