Drawing API problem

[adobeAtul]

I am using Drawing API for drawing lines from one point to another. The points are coming from .net part(middle tier) at the interval of 25 msec. It works fine for some time. But after some time, drawing becomes slow. Is it related to some thing like graphics memory? A weird idea!

[Colin Holgate]

When you draw you're creating more and more curves, and that eventually takes enough CPU to be noticeably slow. What is the nature of what you're drawing? There are a few ways to solve the problem, but knowing what it looks like would help a lot.

[kglad]

you should be able to draw thousands of lines without bogging down your application, but eventually things will slow once you get beyond 100000 lines.

if you check my website, under snippets/mandelbrot you'll see a graphing application that draws about 600 x 600 = 360000 line segments (1pixel each). and the performance is pretty good, especially considering all the calculations taking place to determine the color of the line segment.

if you have more lines than this, you're probably doing something wrong and if your performance is worse than the mandelbrot rendering, you're probably doing something wrong.

[Colin Holgate]

This page takes about 3% CPU on my 2.3 GHz core 2 duo, and your page makes that jump to 140-150% CPU, so it is very demanding to draw a lot of lines. Also, do you keep all curves around, or do you get rid of them when they're faded to black? You could do your page by clearing the sprite every frame, and drawing all of the curves every time, which means there's never too many still in action.

[kglad]

ummm, how does your computer use 140% of its cpu?

[Colin Holgate]

It's a Core 2 Duo, it has two cores. That means your swf is demanding enough to use 100% of one core, and 50% of the other (or some combination that totals 150). Entire empires have ran on less CPU!

Do you remove curves after they've faded to black?

[Colin Holgate]

It's a Core 2 Duo, it has two cores. That means your swf is demanding enough to use 100% of one core, and 50% of the other (or some combination that totals 150). Entire empires have ran on less CPU!

Do you remove curves after they've faded to black?

[kglad]

nothing is removed until a drawing starts.

do you have a video card?

with the mandelbrot rendering my cpu maxes at:

10% - intel i7 920 @ 2.67 ghz

50% - amd 64, 4400+, 2.2ghz

[Colin Holgate]

>>do you have a video card?

Yes, because my Braille reading isn't so great. The video card helps me see what you've said a lot easier.

>>with the mandelbrot rendering my cpu maxes at:
>>10% - intel i7 920 @ 2.67 ghz
>>50% - amd 64, 4400+, 2.2ghz

The figures I gave were just for the spirograph on your home page. Where is the Mandelbrot you're testing with?

[kglad]

if you check my website, under snippets/mandelbrot

[Colin Holgate]

Thanks. The Mandelbrot one is a wide range, from 6 to 90 percent, a lot less demanding that the spirograph.

Back to the original problem, the performance of drawing curves is down to the number curves that need to be rendered. Any number of pixels in a bitmap can be set without it affecting the CPU load (except while you're doing setpixels).

adobeAtul, can you say more about the nature of the image you're making?

[kglad]

the mandelbrot draws hundreds of thousands of lines.

[Colin Holgate]

I'm not sure why you would do a moveTo(x,y), lineTo(x+1,y), 360,000 times, when you could do 360,000 setPixels into one bitmap.

Poor adobeAtul is going to overwhelmed when returning to this thread! I would still like to know what the nature of the drawing is to be. If it's based on data coming from a web feed, it's not likely to be a mandelbrot set.

[adobeAtul]

Hi thanks all for your reply.

Colin,

we are trying to draw lines from the points that we recieve from .net end which are the part of bezier curves. At .net some complex patterns are breakup into bezier curves and pass the points one by one to flash end at regular interval.
What we do is just draw a line to current point from the previous point and move the cursor. With these we are also doing calculation like checking the points whether they are within the our display object range or not and rotating the cursor along the direction of curve path.
But all these works, fine till some 5000 points but afterwards it starts getting slow down. Again I am using spirit as display object for drawing.

please help me out of these problem.

[adobeAtul]

can anybody help? its urgent please help..

[Colin Holgate]

It just sounds like you have too many curves. If you changed your approach to doing setPixel into a bitmap, instead of lineTo, the performance would get dramatically better.

How many new curves are coming in each second? Do you ever have to erase an earlier curve?

[kglad]

i thought i was drawing those lines because i started looking ahead along the x-axis to see when the color would change. as long as the color stayed the same, i used one line.

but, as i recall, that ended up using so much cpu to look-ahead, find the first point where the color changed, draw the line one pixel short of that color-change point and continue, that it was more efficient to draw one pixel lines.

reading your message i thought you might be right, it would be more efficient to set the pixels one-by-one. so, i just now went back to look at my code and i'm doing just that. i'm not drawing 1 pixel lines.

i don't remember when i made that change. the mandelbrot rendering has undergone about 5 or 10 major revisions as i've had different ideas about improving the rendering speed. (in as2, it could take up to 45 minutes to render the maximally magnified graphs.)

when i redid this in as3, i used setPixel() (for the solid colors) and setPixel32() (for the "shades" of black) and that worked so well i haven't looked at my code for about 1.5 years. so, i forget what i had done and mislead you.

[Greg Dove]

When you say bezier curves I presume you mean quadratic bezier curves that the native drawing API uses? Or are you converting spline data or cubic beziers to native drawing api parameters from the .net data in flash as well? Some of these calculations can take time for large data sets if done with an emphasis on highly accurate approximations in flash.

Here are a bunch of questions I could think of:

How are you receiving the drawing data? are they coming in via xml, for example? (Are you sure its the drawing activity that is slow and not the parsing of data). Are they coming in as 5000 points or incrementally over time?

Are you clearing and redrawing from the start of drawing sequence each time (it seems not, but just wanted to check)?

Are you drawing to a single Sprite's graphics context or are you creating layered Sprites to hold subsequent portions of the rendered drawing?

when you say 'rotating the cursor' along the path...are you animating anything as well? How are you checking the point intersection - bounds based? or against a rendered shape?

The last thing I can think of is: are you using some of the advanced lineStyle settings? some of these settings can slow things down substantially with large and complex drawings, whereas other settings are much faster. Also even specifying the default settings can be slower than not specifying them. But again, this is usually only noticeable for very long drawing paths.

Your post doesn't have enough information to advise directly, but perhaps if you answer those questions it might provide us some clues.