Why is CUSTOMDRAW performance so bad? - Programmer

This is a discussion on Why is CUSTOMDRAW performance so bad? - Programmer ; I'm trying to use CUSTOMDRAW to draw a tree view control. If I turn on "show windows while dragging" and move a window over my custom control in circles, the repainting is brutal for most of application windows (ie, the ...

+ Reply to Thread
Results 1 to 12 of 12

Thread: Why is CUSTOMDRAW performance so bad?

  1. Why is CUSTOMDRAW performance so bad?

    I'm trying to use CUSTOMDRAW to draw a tree view control. If I turn on "show
    windows while dragging" and move a window over my custom control in circles,
    the repainting is brutal for most of application windows (ie, the main
    frame, status bar, etc). I have the same issue at work where I am using
    CUSTOMDRAW to draw a list view control.

    Maybe I am doing something wrong in both cases...

    case CDDS_PREPAINT:

    return CDRF_NOTIFYITEMDRAW;

    case CDDS_ITEMPREPAINT:

    {

    PRGDrawItem(hWnd, lpNMTVCD);

    return CDRF_SKIPDEFAULT;

    }

    default:

    return CDRF_SKIPDEFAULT;

    If I comment out most of the PRGDrawItem() function, the painting is much
    less brutal...

    this function is double-buffering... painting each item to an offscreen DC
    and then bitblting on to the screen. Is this necessary in customdraw or does
    customdraw already double buffer?

    commenting out the double-buffering portion of the code reduces the slow
    painting a bit, but not by much.

    Other then that, its just simple GDI operations like FillRects and
    DrawTexts.

    Any ideas?







  2. Re: Why is CUSTOMDRAW performance so bad?

    Nobody wrote:

    > I'm trying to use CUSTOMDRAW to draw a tree view control. If I turn on "show
    > windows while dragging" and move a window over my custom control in circles,
    > the repainting is brutal for most of application windows (ie, the main
    > frame, status bar, etc).


    I haven't this problem.
    (eg with sample from KB248496)

  3. Re: Why is CUSTOMDRAW performance so bad?


    "Christian ASTOR" wrote in message
    news:uxP1LiLzFHA.464@TK2MSFTNGP15.phx.gbl...
    > Nobody wrote:
    >
    >> I'm trying to use CUSTOMDRAW to draw a tree view control. If I turn on
    >> "show windows while dragging" and move a window over my custom control in
    >> circles, the repainting is brutal for most of application windows (ie,
    >> the main frame, status bar, etc).

    >
    > I haven't this problem.
    > (eg with sample from KB248496)


    Well, this is a really basic example of custom draw in a really simple UI. I
    see some apps with more complex UIs like Office 2003 don't have this
    problem, but some UI libraries like most of the codejock and bcgsoft samples
    have this repainting problem.



  4. Re: Why is CUSTOMDRAW performance so bad?


    "Nobody" wrote in message
    news:Yr22f.12288$fE5.2927@fed1read06...
    > I'm trying to use CUSTOMDRAW to draw a tree view control. If I turn on

    "show
    > windows while dragging" and move a window over my custom control in

    circles,
    > the repainting is brutal for most of application windows (ie, the main
    > frame, status bar, etc). I have the same issue at work where I am using
    > CUSTOMDRAW to draw a list view control.
    >
    > Maybe I am doing something wrong in both cases...
    >
    > case CDDS_PREPAINT:
    >
    > return CDRF_NOTIFYITEMDRAW;
    >
    > case CDDS_ITEMPREPAINT:
    >
    > {
    >
    > PRGDrawItem(hWnd, lpNMTVCD);
    >
    > return CDRF_SKIPDEFAULT;
    >
    > }
    >
    > default:
    >
    > return CDRF_SKIPDEFAULT;
    >
    > If I comment out most of the PRGDrawItem() function, the painting is much
    > less brutal...
    >
    > this function is double-buffering... painting each item to an offscreen DC
    > and then bitblting on to the screen. Is this necessary in customdraw or

    does
    > customdraw already double buffer?
    >
    > commenting out the double-buffering portion of the code reduces the slow
    > painting a bit, but not by much.
    >
    > Other then that, its just simple GDI operations like FillRects and
    > DrawTexts.
    >
    > Any ideas?
    >


    Is PRGDrawItem() drawing only a single item? Or is it drawing the entire
    control?

    Your custom draw handler will be called for each and every item (and, for a
    list view control, it's called for each and every sub-item too). As a
    consequence, your PRGDrawItem() function should draw only a single item,
    corresponding to the value of lpNMTVCD->nmcd->dwItemSpec. Based on the name
    of your function (i.e., PRGDraw "Item") it sounds like your function is
    doing this correctly. But if PRGDrawItem() is drawing the entire control,
    each and every time it's called, then you might get the bad performance you
    are seeing.

    Mike



  5. Re: Why is CUSTOMDRAW performance so bad?

    "Nobody" wrote in message
    news:dyc2f.12425$fE5.2183@fed1read06...
    >
    > > (eg with sample from KB248496)

    >
    > Well, this is a really basic example of custom draw in a really simple UI.

    I
    > see some apps with more complex UIs like Office 2003 don't have this
    > problem, but some UI libraries like most of the codejock and bcgsoft

    samples
    > have this repainting problem.


    Does the Microsoft sample work fine on your station ?
    If it does, the bug is from your code.



  6. Re: Why is CUSTOMDRAW performance so bad?


    "Steph" wrote in message
    news:uQXK8zPzFHA.4032@TK2MSFTNGP15.phx.gbl...
    > "Nobody" wrote in message
    > news:dyc2f.12425$fE5.2183@fed1read06...
    >>
    >> > (eg with sample from KB248496)

    >>
    >> Well, this is a really basic example of custom draw in a really simple
    >> UI.

    > I
    >> see some apps with more complex UIs like Office 2003 don't have this
    >> problem, but some UI libraries like most of the codejock and bcgsoft

    > samples
    >> have this repainting problem.

    >
    > Does the Microsoft sample work fine on your station ?
    > If it does, the bug is from your code.
    >
    >


    Yes, but as I said, it is a VERY simple sample... it doesn't use themes, its
    a single dialog, all the custom draw does is change the colors and font.



  7. Re: Why is CUSTOMDRAW performance so bad?

    "Nobody" wrote in message
    news:cUd2f.12430$fE5.3233@fed1read06...

    > > Does the Microsoft sample work fine on your station ?
    > > If it does, the bug is from your code.


    > Yes, but as I said, it is a VERY simple sample... it doesn't use themes,

    its
    > a single dialog, all the custom draw does is change the colors and font.


    Then, if the Microsoft sample works, compare your code with MS code to
    correct your bug.



  8. Re: Why is CUSTOMDRAW performance so bad?


    "Michael K. O'Neill" wrote in message
    news:%23%23$X9nPzFHA.2076@TK2MSFTNGP14.phx.gbl...
    >
    > "Nobody" wrote in message
    > news:Yr22f.12288$fE5.2927@fed1read06...
    >> I'm trying to use CUSTOMDRAW to draw a tree view control. If I turn on

    > "show
    >> windows while dragging" and move a window over my custom control in

    > circles,
    >> the repainting is brutal for most of application windows (ie, the main
    >> frame, status bar, etc). I have the same issue at work where I am using
    >> CUSTOMDRAW to draw a list view control.
    >>
    >> Maybe I am doing something wrong in both cases...
    >>
    >> case CDDS_PREPAINT:
    >>
    >> return CDRF_NOTIFYITEMDRAW;
    >>
    >> case CDDS_ITEMPREPAINT:
    >>
    >> {
    >>
    >> PRGDrawItem(hWnd, lpNMTVCD);
    >>
    >> return CDRF_SKIPDEFAULT;
    >>
    >> }
    >>
    >> default:
    >>
    >> return CDRF_SKIPDEFAULT;
    >>
    >> If I comment out most of the PRGDrawItem() function, the painting is much
    >> less brutal...
    >>
    >> this function is double-buffering... painting each item to an offscreen
    >> DC
    >> and then bitblting on to the screen. Is this necessary in customdraw or

    > does
    >> customdraw already double buffer?
    >>
    >> commenting out the double-buffering portion of the code reduces the slow
    >> painting a bit, but not by much.
    >>
    >> Other then that, its just simple GDI operations like FillRects and
    >> DrawTexts.
    >>
    >> Any ideas?
    >>

    >
    > Is PRGDrawItem() drawing only a single item? Or is it drawing the entire
    > control?
    >
    > Your custom draw handler will be called for each and every item (and, for
    > a
    > list view control, it's called for each and every sub-item too). As a
    > consequence, your PRGDrawItem() function should draw only a single item,
    > corresponding to the value of lpNMTVCD->nmcd->dwItemSpec. Based on the
    > name
    > of your function (i.e., PRGDraw "Item") it sounds like your function is
    > doing this correctly. But if PRGDrawItem() is drawing the entire control,
    > each and every time it's called, then you might get the bad performance
    > you
    > are seeing.
    >
    > Mike
    >
    >


    No, I am drawing a single item.

    Interesting observations:

    1) Outlook Express, MSPaint, Winzip, Office, Excel paint with no problem
    2) Visual Studio, Trillian, Soundblaster apps, have the same problem that I
    do, varying in extent from minor to major
    3) Codejock and BCGSoft (two major GUI libraries) have this problem in the
    majority of the samples
    4) This one is the most interesting. If I move windows around that belong to
    MY APPLICATION, I get ZERO redraw issues. But if the window is owned by
    another application, thats when the redraw issues occur. Even if I have my
    custom draw tree view open and move over it with a file dialog that my app
    owns, I have ZERO redraw issues. But if I move over it with a file dialog
    that a different app owns, redraw problems ensue.

    I have a pretty burly machine... 2.6ghz P4 w/ hyperthreading and 1GB DDR400
    ram. I do have a slightly less then burly video card, a matrox g450. But if
    the video card was the issue, this would happen on all applications.

    The CPU is always at low load, and the apps are in release with speed
    optimization turned on, run outside of the debugger.

    Any ideas??



  9. Re: Why is CUSTOMDRAW performance so bad?


    "Nobody" wrote in message
    news:Yr22f.12288$fE5.2927@fed1read06...
    > I'm trying to use CUSTOMDRAW to draw a tree view control. If I turn on
    > "show windows while dragging" and move a window over my custom control in
    > circles, the repainting is brutal for most of application windows (ie, the
    > main frame, status bar, etc). I have the same issue at work where I am
    > using CUSTOMDRAW to draw a list view control.
    >
    > Maybe I am doing something wrong in both cases...
    >
    > case CDDS_PREPAINT:
    >
    > return CDRF_NOTIFYITEMDRAW;
    >
    > case CDDS_ITEMPREPAINT:
    >
    > {
    >
    > PRGDrawItem(hWnd, lpNMTVCD);
    >
    > return CDRF_SKIPDEFAULT;
    >
    > }
    >
    > default:
    >
    > return CDRF_SKIPDEFAULT;
    >
    > If I comment out most of the PRGDrawItem() function, the painting is much
    > less brutal...
    >
    > this function is double-buffering... painting each item to an offscreen DC
    > and then bitblting on to the screen. Is this necessary in customdraw or
    > does customdraw already double buffer?
    >
    > commenting out the double-buffering portion of the code reduces the slow
    > painting a bit, but not by much.
    >
    > Other then that, its just simple GDI operations like FillRects and
    > DrawTexts.
    >
    > Any ideas?
    >
    >
    >
    >
    >
    >


    are you calling LockWindowUpdate at all in your program?
    (because I've noticed problems with this API)

    James

    --
    www.catch22.net
    Free win32 software, sourcecode and tutorials



  10. Re: Why is CUSTOMDRAW performance so bad?

    I've used both CodeJock and BCGSoft and neither has an slow redrawing
    problems that I can tell.

    Tom

    "Nobody" wrote in message
    news:dyc2f.12425$fE5.2183@fed1read06...
    >
    > "Christian ASTOR" wrote in message
    > news:uxP1LiLzFHA.464@TK2MSFTNGP15.phx.gbl...
    >> Nobody wrote:
    >>
    >>> I'm trying to use CUSTOMDRAW to draw a tree view control. If I turn on
    >>> "show windows while dragging" and move a window over my custom control
    >>> in circles, the repainting is brutal for most of application windows
    >>> (ie, the main frame, status bar, etc).

    >>
    >> I haven't this problem.
    >> (eg with sample from KB248496)

    >
    > Well, this is a really basic example of custom draw in a really simple UI.
    > I see some apps with more complex UIs like Office 2003 don't have this
    > problem, but some UI libraries like most of the codejock and bcgsoft
    > samples have this repainting problem.
    >
    >




  11. Re: Why is CUSTOMDRAW performance so bad?

    Probably a dumb suggestion, but I've seen redrawing problems caused by slow
    downs from spyware programs worming their way in. Since you have the
    problem on so many different programs maybe you have something like that
    going on... you might want try searching for Microsoft Antispyware (free)
    and see if that finds anything.

    Tom

    "Nobody" wrote in message
    news:nrf2f.12440$fE5.10610@fed1read06...
    >
    > "Michael K. O'Neill" wrote in message
    > news:%23%23$X9nPzFHA.2076@TK2MSFTNGP14.phx.gbl...
    >>
    >> "Nobody" wrote in message
    >> news:Yr22f.12288$fE5.2927@fed1read06...
    >>> I'm trying to use CUSTOMDRAW to draw a tree view control. If I turn on

    >> "show
    >>> windows while dragging" and move a window over my custom control in

    >> circles,
    >>> the repainting is brutal for most of application windows (ie, the main
    >>> frame, status bar, etc). I have the same issue at work where I am using
    >>> CUSTOMDRAW to draw a list view control.
    >>>
    >>> Maybe I am doing something wrong in both cases...
    >>>
    >>> case CDDS_PREPAINT:
    >>>
    >>> return CDRF_NOTIFYITEMDRAW;
    >>>
    >>> case CDDS_ITEMPREPAINT:
    >>>
    >>> {
    >>>
    >>> PRGDrawItem(hWnd, lpNMTVCD);
    >>>
    >>> return CDRF_SKIPDEFAULT;
    >>>
    >>> }
    >>>
    >>> default:
    >>>
    >>> return CDRF_SKIPDEFAULT;
    >>>
    >>> If I comment out most of the PRGDrawItem() function, the painting is
    >>> much
    >>> less brutal...
    >>>
    >>> this function is double-buffering... painting each item to an offscreen
    >>> DC
    >>> and then bitblting on to the screen. Is this necessary in customdraw or

    >> does
    >>> customdraw already double buffer?
    >>>
    >>> commenting out the double-buffering portion of the code reduces the slow
    >>> painting a bit, but not by much.
    >>>
    >>> Other then that, its just simple GDI operations like FillRects and
    >>> DrawTexts.
    >>>
    >>> Any ideas?
    >>>

    >>
    >> Is PRGDrawItem() drawing only a single item? Or is it drawing the entire
    >> control?
    >>
    >> Your custom draw handler will be called for each and every item (and, for
    >> a
    >> list view control, it's called for each and every sub-item too). As a
    >> consequence, your PRGDrawItem() function should draw only a single item,
    >> corresponding to the value of lpNMTVCD->nmcd->dwItemSpec. Based on the
    >> name
    >> of your function (i.e., PRGDraw "Item") it sounds like your function is
    >> doing this correctly. But if PRGDrawItem() is drawing the entire
    >> control,
    >> each and every time it's called, then you might get the bad performance
    >> you
    >> are seeing.
    >>
    >> Mike
    >>
    >>

    >
    > No, I am drawing a single item.
    >
    > Interesting observations:
    >
    > 1) Outlook Express, MSPaint, Winzip, Office, Excel paint with no problem
    > 2) Visual Studio, Trillian, Soundblaster apps, have the same problem that
    > I do, varying in extent from minor to major
    > 3) Codejock and BCGSoft (two major GUI libraries) have this problem in the
    > majority of the samples
    > 4) This one is the most interesting. If I move windows around that belong
    > to MY APPLICATION, I get ZERO redraw issues. But if the window is owned by
    > another application, thats when the redraw issues occur. Even if I have my
    > custom draw tree view open and move over it with a file dialog that my app
    > owns, I have ZERO redraw issues. But if I move over it with a file dialog
    > that a different app owns, redraw problems ensue.
    >
    > I have a pretty burly machine... 2.6ghz P4 w/ hyperthreading and 1GB
    > DDR400 ram. I do have a slightly less then burly video card, a matrox
    > g450. But if the video card was the issue, this would happen on all
    > applications.
    >
    > The CPU is always at low load, and the apps are in release with speed
    > optimization turned on, run outside of the debugger.
    >
    > Any ideas??
    >
    >




  12. Re: Why is CUSTOMDRAW performance so bad?

    Nobody wrote On 10/08/05 23:06,:
    > I'm trying to use CUSTOMDRAW to draw a tree view control. If I turn on "show
    > windows while dragging" and move a window over my custom control in circles,
    > the repainting is brutal for most of application windows (ie, the main
    > frame, status bar, etc). I have the same issue at work where I am using
    > CUSTOMDRAW to draw a list view control.


    One comment, be very careful what is on your screen while you test this.
    I had an app that seemed to be taking way to much time while doing "real
    time sizing". After showing the process stats, I realized that the window
    UNDER mine was taking all of the time. Even if you are running on a bare
    desktop, just the time to repaint any icons under your window can slow
    you down.

    Ps. Please don't crosspost to every group in creation.


+ Reply to Thread