 |
|
 |
Thanks for the code, it really helps.
But.. I notice that all memory bitmaps are deleted when SetDirty is called.
If all that is needed is a redraw, wouldn't it be enough to just clear (fill with background color or pattern) and re-draw onto them?
Maybe it would be better to have two types of 'dirty', one for the occasion when the size or format of the bitmap changes, and another for if only the contents change.
Just my 2c
Lex
|
|
|
|
 |
|
 |
CQTTDemoView:
- Override OnEraseBackground to return TRUE.
- Override OnDraw:
where:
to:
QBufferDC bufferDC ( pDC );
Graphics g ( bufferDC.GetSafeHdc () );
QBufferDC:
- On the constructor class QBufferDC:
where:
// Get the clipping boundary of the mother DC, in logical coordinates
CRect rcClip;
VERIFY ( pDC->GetClipBox ( rcClip ) != ERROR );
// Transform to device coordinates (pixels), and normalize
pDC->LPtoDP ( rcClip);
rcClip.NormalizeRect ();
if ( m_bufferBitmap.ReserveBitmap ( pDC, rcClip.Size () ) )
{
...
...
#ifdef QBUFFER_DEMO
// In demo mode, change the color slightly so we can see which parts are updated
if ( m_bDemoMode )
col ^= RGB ( rand () % 32, rand () % 32, rand () % 32 );
#endif
// Get the mother DC's clipping boundary in logical coordinates and fill it.
VERIFY ( pDC->GetClipBox ( rcClip ) != ERROR );
// Transform to device coordinates (pixels), and normalize
pDC->LPtoDP ( rcClip );
if ( mapmode != MM_TEXT )
{
// Other mapping modes may lead to roundof errors, causing artefacts
// on the screen. To compensate, we inflate the bounding rectangle with two pixels.
CSize szPixels ( 2, 2 );
DPtoLP ( &szPixels );
rcClip.InflateRect ( szPixels.cx, szPixels.cy );
}
// DAKOT removed:
//FillSolidRect ( rcClip, col );
// Initialize accumulation of boundary information
SetBoundsRect ( NULL, DCB_ENABLE | DCB_ACCUMULATE | DCB_RESET );
// DAKOT added here:
FillSolidRect ( rcClip, col );
}
to:
// Get the clipping boundary of the mother DC, in logical coordinates
CRect rcClip, rcBitmap;
VERIFY ( pDC->GetClipBox ( rcClip ) != ERROR );
// Transform to device coordinates (pixels), and normalize
rcBitmap.CopyRect ( &rcClip );
pDC->LPtoDP ( rcBitmap );
rcBitmap.NormalizeRect ();
if ( m_bufferBitmap.ReserveBitmap ( pDC, rcBitmap.Size () ) )
{
...
...
#ifdef QBUFFER_DEMO
// In demo mode, change the color slightly so we can see which parts are updated
if ( m_bDemoMode )
col ^= RGB ( rand () % 32, rand () % 32, rand () % 32 );
#endif
/************ COMMENTED by VMONSTER
// Get the mother DC's clipping boundary in logical coordinates and fill it.
VERIFY ( pDC->GetClipBox ( rcClip ) != ERROR );
// Transform to device coordinates (pixels), and normalize
pDC->LPtoDP ( rcClip );
if ( mapmode != MM_TEXT )
{
// Other mapping modes may lead to roundof errors, causing artefacts
// on the screen. To compensate, we inflate the bounding rectangle with two pixels.
CSize szPixels ( 2, 2 );
DPtoLP ( &szPixels );
rcClip.InflateRect ( szPixels.cx, szPixels.cy );
}
************/
// DAKOT removed:
//FillSolidRect ( rcClip, col );
// Initialize accumulation of boundary information
SetBoundsRect ( NULL, DCB_ENABLE | DCB_ACCUMULATE | DCB_RESET );
// DAKOT added here:
FillSolidRect ( rcClip, col );
}
|
|
|
|
 |
|
 |
CQTTDemoView:
- Override OnEraseBackground to return TRUE.
- Override OnDraw:
where:
Graphics g ( pDC->GetSafeHdc () );
to:
QBufferDC bufferDC ( pDC );
Graphics g ( bufferDC.GetSafeHdc () );
|
|
|
|
 |
|
 |
This code works as advertized it has smooth redraws and flicker free. However the CPU usage is very high. I implemented this in an MFC dialog based application and I have 70% CPU usage when my program runs without causing any redraws and as soon as I do the CPU usage goes to 100%.
It surely maybe the way I am using it. In my Draw function I am doing the following:
I am using GDI+'s drawimage function to draw all my graphics.
I can comment out either the DrawBackGround function or the drawing of my buttons and either cuts the CPU usage to about half of what it was.
I seems that the code spends alot of time in the createoffscreengraphics even if nothing is changing.
Any suggestions?
// Fill background with image
DrawBackGround( pGraphics, nWidth, nHeight );
// Display all buttons loaded from xml file
std::vector<Button*>::iterator it;
Button *pB = NULL;
for (it = vButtons.begin(); it != vButtons.end(); ++it)
{
pB = *it;
if( m_CurrentPanel == pB->PanelName )
pB->Draw( pGraphics, m_ActiveButton );
}
// Display the current Time
if( m_CurrentPanel == "main" ) //&& c_Theme.Status == "ON")
DisplayTime( pGraphics );
|
|
|
|
 |
|
 |
Unfortunately there is nothing you can do. If you want low CPU usage (in fact any acceptable performace) ditch GDI+ in favor of GDI. Currently, GDI+ it is absolutely useless for performance critical applications. GDI+ 1.0 has no hardware acceleration, hence the cpu usage is colossal. You'll have to wait for GDI+ 2.0... :(
|
|
|
|
 |
|
 |
Thanks for the reply.
Any idea when there might be a GDI+ 2.0?
Maybe in Windows Longhorn?
|
|
|
|
 |
|
 |
Not a clue, sorry.
At the very least it should be part of Longhorn (if thats anything like XP, I dont know much about it).
|
|
|
|
 |
|
 |
hi
can anybody help me to implement this class in an already existing MFC 6.0 project? i'm not really familiar with ATL/WTL but i don't want to copy all methods and members in every view.
just by including the header into the project, i get this error message:
"syntax error : missing ';' before identifier 'MESSAGE_HANDLER'"
i think this is due to the missing ATL support (which i don't really want)
i'd appriciate any hints...
|
|
|
|
 |
|
 |
Yes, I meet the same problem with, I don't know how to solve it, who can give an answer?
thanks
Best regards
|
|
|
|
 |
|
 |
I have a class that provides double-buffering support with a single line that only requires a CDC pointer.
I use it for existing MFC 6.0 projects and can provide it if you like.
Craig.
Craig Muller
Z Systems
cmuller@zsystems.ca
www.zsystems.ca
|
|
|
|
 |
|
 |
#include "atlwin.h" first as it defines the micro MESSAGE_HANDLER.
Regards,
-Levi
|
|
|
|
 |
|
 |
I still get flicker when I resize the window. Is this by design? Or is something wrong?
thanks!
r.S.
|
|
|
|
 |
|
 |
actually what I'm doing is displaying the view in a splitter window... that is to say that I'm deriving my View class from CWindowImpl and not CFrameWindowImpl...
I verifed that the flickering does not happen with a CFrameWindowImpl derived class...
weird...
r.S.
|
|
|
|
 |
|
 |
Probably doesn't override WM_ERASEBKGRND, You need to override that and prevent the default background paint. Don't know about this WTL stuff. Also, I don't use the cached buffering. Here is some code I changed for another project I found on this or another site: in ::OnDraw or OnPaint CRect rect; GetClientRect(&rect); Rect rc(rect.left, rect.top, rect.Width(), rect.Height()); Bitmap bmp(rect.Width(), rect.Height()); Color cw; // Block for Graphics Graphics g(pDC->GetSafeHdc()); g.SetSmoothingMode(SmoothingModeHighQuality); g.SetInterpolationMode(InterpolationModeHighQualityBicubic); g.SetPixelOffsetMode(PixelOffsetModeHighQuality); if (m_bDoubleBuffer) { Graphics* memgraph = Graphics::FromImage(&bmp); memgraph ->SetSmoothingMode(SmoothingModeHighQuality); memgraph ->SetInterpolationMode(InterpolationModeHighQualityBicubic); memgraph ->SetPixelOffsetMode(PixelOffsetModeHighQuality); memgraph->FillRectangle(m_pBrushes[6], rect.left, rect.top, rect.Width(), rect.Height()); for (int i = 0; i < 6; i++) { memgraph->FillPath(m_pBrushes[i], & m_Paths[i]); memgraph->DrawPath(m_pPens[i], & m_Paths[i]); } g.DrawImage(&bmp, rect.left, rect.top, rect.right, rect.bottom); delete memgraph; } else { for (int i = 0; i < 6; i++) { g.FillPath(m_pBrushes[i], & m_Paths[i]); g.DrawPath(m_pPens[i], & m_Paths[i]); } }; Also need something similiar to this: BOOL CQTTDemoView::OnEraseBkgnd(CDC* pDC) { // TODO: Add your message handler code here and/or call default if (m_bDoubleBuffer) return TRUE; else return CScrollView::OnEraseBkgnd(pDC); } Marty
|
|
|
|
 |
|
 |
"windows picture and fax viewer" can preview almost every kinds of images.
i was wondering about how they did it
Thanks.
|
|
|
|
 |
|
 |
Um, thanks, but I'm not sure what your question has to do with my article.....?
----------------------------------------
----I said my name wasn't important
---------------------------SlartiBartFast
|
|
|
|
 |
|
 |
Just the copyright alone is worth a '5'
cheers,
Chris Maunder
|
|
|
|
 |
|
 |
You said it all. Less restriction naturally wins my points
Best regards,
Paul.
Paul Selormey, Bsc (Elect Eng), MSc (Mobile Communication) is currently Windows open source developer in Japan.
|
|
|
|
 |