Announcement

Collapse
No announcement yet.

Graphics Problems

Collapse
X
 
  • Filter
  • Time
  • Show
Clear All
new posts

  • james klutho
    replied
    Thank you all for your thoughts. I think I can try some new
    directions now.

    ------------------

    Leave a comment:


  • Bernard Chapman
    replied
    You don't need to BitBlit except to repaint after a section of the screen becomes invalidated by for example another window overlapping it..

    I have done exactly what you are attempting to do but by XORing the trendline drawn directly to a window as well as to a memory bitmap that is used only for repainting.

    Pull the demo disk off my website and use it to draw a trendline on the chart. You can then drag the ends around smoothly and if you drag it by the middle it will shift bodily about the screen retaining the same slope.

    The whole thing is infinitely smooth and instantaneous.

    Regards,

    Bern

    ------------------
    Bern

    www.insighttrading.com.au

    Leave a comment:


  • Peter Scheutz
    replied
    Originally posted by Aldo Cavini:
    I noticed BitBlt processes a compatible bitmap much faster with respect to a device independent bitmap. If James's program is already written with compatible bitmaps, may be it is better to leave it as is...
    May very well be in the case at hand, but...

    The speed depends very much on the target computer.
    Some cards have very poor 24 bit performance, and are really good at 32 bit
    If you do a fair amount of offscreen to offscreen blitting, benefits from using the screens format, can quickly disappear.

    The 16 bits 5-5-5 format and 5-6-5 format takes time to pack and unpack, so if you're planning on doing any direct bit manipulation, it's a good choice to stick with 32bits.
    Moving and accessing (RGB(A)) 32 bits in PB inline asm, is easier than other formats.

    You have to do real life testing, on a range of computers, to see if your implementation performs as expected.


    ------------------
    Best Regards
    Peter Scheutz

    Leave a comment:


  • Aldo Cavini
    replied
    Peter,
    Blitting the whole screen on every update, may sound like it's going to be to slow...
    I think invalidating rectangles, and painting only the rcPaint rectangle, is a good compromise between speed and simplicity (the rcPaint I mentioned is the member of PAINTSTRUCT, on the BeginPaint API call).
    We use 32bit DibSections for all offscreen canvases...
    I noticed BitBlt processes a compatible bitmap much faster with respect to a device independent bitmap. If James's program is already written with compatible bitmaps, may be it is better to leave it as is...


    ------------------

    Leave a comment:


  • Peter Scheutz
    replied
    A couple of ways:

    Draw a line in xor mode and erase it by drawing it in xor mode again.

    In your offscreen buffer, save the part where the line is, and draw the line.
    Save it by BitBlt'ing the section it will cover to another offscreen canvas.
    Before drawing the line in a new location, restore from buffer.

    Create an offscreen canvas, and on this, BitBlt the whole graph, then the line and handles, then the offscreen canvas to the screen.

    For all methods, try only invalidating the part of the screen that has changed.
    Blitting the whole screen on every update, may sound like it's going to be to slow, but if you keep a dirty rectangles list, it is actually quite fast.
    After lots of testing, thats how we ended up doing it in our GDI sprite engine.
    We use 32bit DibSections for all offscreen canvases, and let Windows handle the conversion when blitting to the screen.



    ------------------
    Best Regards
    Peter Scheutz

    Leave a comment:


  • Aldo Cavini
    replied
    the way you use a compatibleDc to draw and a BitBlt to paint the window is the only one I know to avoid the flicker. Be careful to process the %WM_ERASEBKGND message: since you paint the whole window on the %WM_PAINT messages, you can avoid the internal Windows background erasure. On the %WM_ERASEBKGND you must return a non-zero and avoid the message to be processed by the DefWindowProc (exit function).

    ------------------

    Leave a comment:


  • james klutho
    started a topic Graphics Problems

    Graphics Problems

    I was wondering if someone could help me with a suggestion of
    where to start looking or has a snippet of code to help me with
    a problem. I have a graph (grid with data plotted on it) which
    is drawn in a CompatibleDC and BitBlt'ed to a window. I wish to
    put a best fitting trend line on this data and be able to move
    this trend line around on the graph smoothly and without flicker.
    It would be nice to have handles on the trend line so it could
    be resized etc. Many application demonstrate this but my
    attempts are not pleasing to the eye. Any thoughts would be
    appreciated.

    ------------------
Working...
X