There are a number of things that my control must do.
ps: Look at outlook's day view and that is the look I am after.
There are a number of areas which get drawn on each repaint.
1) The top of the control, this has the Name of the person who's schedule you are
looking for
2) Below the persons name, you have the days which are visible for that person,
1...X
3) Any number of 1 & 2
4) The left side (say 50 pixels) contains the time of the appointments, say from
12:00am to 12:00am (24 hours using a number of predefined increments, 60 mins, 30
mins, 20 mins, 15 mins, 10 mins, 6 mins, and 5 mins)
5) The actual appointment rows, one for each time increment, for 60 mins = 24
rows, 30 mins = 48 rows etc... Not all visible on screen at one time unless they all
fit.
6) the actual appoinemnts which sit over the rows, the appointments can conflict
with each other so you have potentially multiple appointments per day per column. Add
a few into outlook that conflict and you will get the idea.
So from what you are saying..
I must:
1) Create a region for say #1 above, and draw that.
2) Create a region below #1 and draw that.
3) Draw the time incrments etc..?
4) How do I draw the rows, and the appointments?, since the rows must be drawn
before the appointment.
Do you have any simple examples of using these regions? I do use a region when drawing
the actual appointments so that when the control is scrolled only the visible part of
the appointments become visible on screen.
Chris
Christopher Crowe (Software Developer)
Microsoft MVP, MCP
Adrock Software
Byte Computer & Software LTD
P.O Box 13-155
Christchurch
New Zealand
Phone/Fax (NZ) 03-3651-112
> -----Original Message-----
> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On
> Behalf Of Max Nilson
> Sent: Thursday, 27 May 1999 09:38
> To: Multiple recipients of list Delphi
> Subject: RE: [DUG]: Drawing Speed
>
>
> Chris Crowe asked:
>
> > Is there a faster way of drawing to the screen?, I have to draw
> > to the bitmap becuase if I do not the screen flickers rather badly.
>
> The primary difference between drawing to an offscreen bitmap and directly
> to the screen is in the device drivers involved.
>
> When you draw to an off screen bitmap you are utilising the the memory
> device driver to translate the GDI calls into altered pixels.
> Obviously this
> is all done by the CPU turning the GDI primitives into altered memory
> states, and requires hitting the L1 and L2 caches, the main memory bus and
> your DRAM.
>
> When you draw to the screen you are utilising the video device driver for
> the card(s) in your machine. If these cards drivers provide hardware
> acceleration (and what cards don't these days?) your GDI
> primitives will be
> performed using the hardware accelerated line, font and filling directly
> into the fancy video RAM used by the card.
>
> So with any modern video card drawing directly to the screen is cheaper on
> CPU time, and takes advantage of hardware to perform most common drawing
> operations. That's why all my drawing code goes directly to the
> screen, and
> off screen bitmaps are not used.
>
> But what about the flicker? The flicker is caused by erasing a
> drawing area
> to the background color before refilling with the foreground stuff. This
> causes unchanged areas that are being redrawn to vanish and
> repaint, and if
> the monitor repaints during this period then you see the alteration taking
> place.
>
> The solution I use it NOT erase the background before drawing into it (and
> tell windows not to erase it either! [see the WM_ERASEBACKGROUND
> message]),
> rather I create a region representing the area requiring painting, and as
> each of the foreground text objects is draw, I substract this from the
> region. At the end of the foreground drawing process anything left in the
> region is erased to the background color.
>
> The cost in doing this is that there is acertain amount of complex region
> manipulation that needs to be done by the CPU, but the using hardware
> acceleration appears to gain more than that lost by the region
> arithemetic.
> The only other issue is that some times in a busy machine invalid areas of
> you program may not be painted for a second or two as the WM_PAINT message
> has a much lower priority than other messages, and the unerased
> portions of
> the invalid area tend to sit about for a while.
>
> Cheers, Max.
>
>
> ------------------------------------------------------------------
> ---------
> New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
> Website: http://www.delphi.org.nz
>
---------------------------------------------------------------------------
New Zealand Delphi Users group - Delphi List - [EMAIL PROTECTED]
Website: http://www.delphi.org.nz
