Howdy, Stranger!

It looks like you're new here. If you want to get involved, click one of these buttons!

Categories

Welcome to the new platform of Programmer's Heaven! We apologize for the inconvenience caused, if you visited us from a broken link of the previous version. The main reason to move to a new platform is to provide more effective and collaborative experience to you all. Please feel free to experience the new platform and use its exciting features. Contact us for any issue that you need to get clarified. We are more than happy to help you.

Dots in C# and Slow Graphics - HELP

horatiu665horatiu665 Posts: 4Member
Hi there. I'm new here.

I have a form application in Visual C# where I draw lots of dots. I mean about the whole screen, full of individual dots with area of 1 pixel. I am using FillRectangle() for this purpose, as DrawLine() is more than 10 times slower, plus it can only draw 2 pixels minimum.[b] My problem is that it takes a while to draw them. [/b]

First I thought it's the calculation for what color the dots will have (it's just black and white btw), but then I made it so the calculation's results are saved in a matrix of screen size, with values of 0 and 1, and then the matrix is "drawn" onto the screen.[b] This doesn't make the problem go away.[/b]

If you want details about the actual code, I can post them/it, just ask so.

I realized that the problem is with the actual rendering of graphics. I read on a lot of different sites, and searched different queries, but [b]never found anything[/b] remotely related to my problem. Usually people draw images or animations, not individual pixels, and that may make my problem so unique.

I have had other problems with this, solved them, but I have reached 3 conclusions:
1. C# sucks at drawing dots
2. There may well be no way to draw graphics faster in C#
3. My Computer Science teacher sucks monkey b@llz

I have nowhere else to search, so I will start as of today writing in forums (for now only this one) and hopefully, someone will help me figure this out, and potentially help others with the same type of problem.

[b]How do you hardware-accelerate the graphics rendering in C#?[/b] Would that be a solution? I hope to receive answers from friendly, competent programmers.

Comments

  • iameskeiameske Posts: 3Member
    Hi, have you tried threading? If your procedures are not sequential, asynchronous methods may help you. You can try this code as an example.

    My method to async:
    [code]
    static void MyMethod(object s)
    {
    // print dots
    }
    [/code]
    Call method and assign it to a new thread:
    [code]System.Threading.ThreadPool.QueueUserWorkItem(MyMethod, null);[/code]
    You can create multiple threads (including it in a loop) if you are still not satisfied with its performance. Hope this can help.
  • horatiu665horatiu665 Posts: 4Member
    *nevermind, see next post*
  • horatiu665horatiu665 Posts: 4Member
    Hahaha! I've created 16 threads that work simultaneously with 16 parts of the screen and they are drawing it MEGA slow!! (compared to the full screen draw I had before)
    Moreover, they are sometimes not drawing anything at all. Probably because there are so many of them, and they are not safe-coded, but I'm not working on that idea anymore.
    Also, whenever there is a draw-over (like a messagebox that appears over part of the screen), the threads all start redrawing - that's because the paint event is only one function and it calls all the threads to redraw regardless of the screen.
    I also just tried with 2 threads that just split the drawing screen in half vertically. An amazing thing happened: the first half was drawn, then the second half, but then when I tried to overdraw with a window, multiple threads seemed to be running on the first half. The drawing was being completed from multiple points at the same time, obviously very slow. That's because the paint event must have been triggered a few times, before the threads were completed, and I didn't use names for them.

    This is not a solution! Threading only slows things down if it isn't safe coded, and can only be good if you need to do fewer, shorter tasks. At least that's what I have learned.

    I used this page as help for threading:
    http://www.albahari.com/threading/
  • iameskeiameske Posts: 3Member
    Sorry if it didn't help. I suggested threading because it worked like a charm for me once when I wrote a program that searches a string in a recursive file search algorithm. I create threads on every file iteration.

    That aside, may I ask if you use Thread.Start or ThreadPool.QueueUserWorkItem? You see, even if they both kick off another thread, there is a fine line between the two.

    ThreadPool advantages:
    1. Reuses threads.
    2. Knows the limit of how many threads can be created (depending on your machine). If you reached that limit, other created threads will be on queue.
    3. Starts and ends threads automatically. You don't need to explicitly start and end them. Once a thread is free, it will assign the task to that thread.
    4. Better start and end thread overhead than Thread.Start. So it is optimized for creating multiple threads.

    Honestly, I never use Thread.Start. Regardless of how many threads I will create. So sir, if you don't mind, how about trying threading again with the example I wrote just below your first post?

  • iameskeiameske Posts: 3Member
    Sorry if it didn't help. I suggested threading because it worked like a charm for me once when I wrote a program that searches a string in a recursive file search algorithm. I create threads on every file iteration.

    That aside, may I ask if you use Thread.Start or ThreadPool.QueueUserWorkItem? You see, even if they both kick off another thread, there is a fine line between the two.

    ThreadPool advantages:
    1. Reuses threads.
    2. Knows the limit of how many threads can be created (depending on your machine). If you reached that limit, other created threads will be on queue.
    3. Starts and ends threads automatically. You don't need to explicitly start and end them. Once a thread is free, it will assign the task to that thread.
    4. Better start and end thread overhead than Thread.Start. So it is optimized for creating multiple threads.

    Honestly, I never use Thread.Start. Regardless of how many threads I will create. So sir, if you don't mind, how about trying threading again with the example I wrote just below your first post?

Sign In or Register to comment.