|
35 MB is a huge image. Double buffering and using the BitBlt API call is probably the best you can do. The mere size of the image involved is most likely the problem.
You can try overriding OnEraseBkgrnd() but I doubt you will see much improvement. 
Any way you can reduce the size of the image?
Maybe reduce the # of colours?
|
|
|
|
|
No, I can't change the image size or format, because I have to work with medical hi-res raw images.
Can you explain me what may change if I use the OnEraseBkgrnd() instead of the OnDraw() method?
|
|
|
|
|
OnDraw(), it's handler for the WM_ERASEBKGRND message which allow or forbid clearing of the window DC before calling WM_PAINT, usually by drawing a large rect using the default background color.
To use it you insert a handler function for WM_ERASEBKGRND from the class view in VC++ 6 or from the 'Messages' in properties panel in VC++7.
To disable clearing the DC, you should remove the deafult return line and just return true, like this:
BOOL CChildView::OnEraseBkgnd(CDC* pDC)
{
return true;
}
This will disable clearing the DC before painting, and it remove flickering in many cases.
The DC pointer is passed here to allow filling the background with with differnt color or pattern, but not usually used to draw the main image.
|
|
|
|
|
Concerning OnEraseBkgnd() -- See the post by MAAK. That is a good explanation.
I do a lot of programming with medical images - is the image you're working with in DICOM format?
How do you acquire it? Is it CT data? MRI?
4000x1000 pixels is a whopping size...what type of data are you displaying with this image?
|
|
|
|
|
I'm using some HIRES 4096x2700 (24 bit per pixel) from the VHD archive.
|
|
|
|
|
Ah, the Visible Human...
I don't have any timings or performance figures to give you, but you could try StretchBlt'ing the image to a MemDC only once with the idea to cut the image size in, say half. Once you have StretchBlt it to memory, you could then BitBlt the reduced image to the DC. Technically, you should only have to shrink the image once in memory (ie: create a temporary bitmap in memory). The smaller image may scroll smoother. You could also use the OnEraseBkgnd() handler in combination with the reduced image. It depends what you are trying to accomplish with your program. You may also want to consider reducing the colour depth, again, depending on the scope of your application.
Upgrading the video card and/or processor may help as well.
Unfortunately, you won't find a faster way of displaying the image than the BitBlt API call...
Aside from all that....
|
|
|
|
|
Newbie Question:
I have a C/C++ Dialog-based app using Visual Sutdio 6.0.
I begin and intensive background processing task using,
AfxBeginThread with THREAD_PRIORITY_BELOW_NORMAL.
All user actions seem to be suspended until this processing task completes.
I would like user actions, such as repositioning the Dialog and clicking buttons to work immediately.
I have a periodic update on the screen, UpdateData(), to inform the User of progress of the background task and tried placing a Sleep() statement in their but that does not seem to work.
Any help would be very much appreciated.
|
|
|
|
|
If you are doing the intensive background processing in your worker thread, what is your main thread doing during this time? Are you just waiting for the worker thread to complete? If the main thread just exits the current message handler, and continues to execute the main message loop, then it should be able to handle new messages (user input) with no problems.
Post the code for how you are creating the thread - it should make things a bit clearer from this end...
Dave
|
|
|
|
|
Dave,
Thank-you for response. Here is the multi-step approach I use to run a background thread that can update Dialog class variables during it's execution.
=== STEP 1
Use AfxBeginThread to run a function, zdisplay()
CWinThread *pThread = AfxBeginThread( &zdisplay, this->m_hWnd, THREAD_PRIORITY_BELOW_NORMAL );
ASSERT( NULL != pThread );
===STEP 2
Use zdisplay() function to endlessly loop and send a message, WM_APP_UPDATE_DLG.
UINT CCryptoDlg::zdisplay( LPVOID pParam )
{
int xx=1;
do
{
::SendMessage( (HWND)pParam, WM_APP_UPDATE_DLG, (WPARAM)buf, 0 );
if (xx == 1)
{
Sleep(1000);
}
} while(TRUE); /*end do statement*/
return 0;
} /*end zdisplay() function*/
===STEP 3
Define message WM_APP_UPDATE_DLG to run function OnUpdateDialog().
ON_MESSAGE( WM_APP_UPDATE_DLG, OnUpdateDialog )
===STEP 4
The code in OnUpdateDialog () is the intensive background task that seems to be disallowing the main dialog to respond to user I/O.
Much thanks,
Robert
|
|
|
|
|
What's happening is your background thread isn't doing the processing at all. It is sending a message to the main thread, telling it to do the operation. Since the main thread is now busy doing the intensive operation, it obviously cannot respond to user input. In addition, SendMessage() is a blocking call, so your worker thread is suspended during this as well.
Change the intensive processing to happen inside the worker thread, and it should post (not send) a message to the main thread whenever it needs to update the display. This will keep the main thread free to process user input, but still only have one thread modifying the display at a time.
Dave
|
|
|
|
|
Hi Dave,
Thank-you for your response. I think I'm getting it.
zdisplay() is clearly a worker thread since it is so-started by AfxBeginThread().
I assumed (badly) that since OnUpdateDialog() function (the intensive processing) was started from a message sent BY the zdisplay() function that it too was of the 'worker' variety.
Clearly you are correct, but what tells you that OnUpdateDialog() is considered a 'main' thread rather than a 'worker' thread?
Sorry for all the dumb questions.
Thank-you very much,
Robert
|
|
|
|
|
Windows are associated with the thread in which they are created. When you send or post a message to a window handle, it will be processed by the thread that owns that window (which may be the same thread). In addition, since worker threads do not have a message pump, they cannot process any messages.
Take a look through some of the thread articles, particularly the ones talking about worker threads vs. user interface threads if you are interested.
Dave
|
|
|
|
|
Hi Dave,
Thanks again. I wrote a quick little test program to experiment with this and it works just like you indicated - no surprize.
I found PostMessage() in the Win32 SDK and will implement that as well. It looks like it takes the same parameters.
Thanks for helping me through this. I'm an old C warhorse and C++ and MFC are new to me.
|
|
|
|
|
|
who used visual basic knows that it has a holly function :
DoEvents()
it processes events while working !
int i=0;
while(1)
{
i++;
DoEvents();
}
this is the C++ version :
bool DoEvents()
{
MSG msg;
while (PeekMessage(&msg, NULL, 0, 0, PM_NOREMOVE) == TRUE)
{
if (GetMessage(&msg, NULL, 0, 0) )
{
TranslateMessage(&msg);
DispatchMessage(&msg);
}
else
{
return TRUE;
}
}
return 0;
}
//rate me or hate me
I am the mighty keeper of the book on knowledge . Contact me to get your copy .
|
|
|
|
|
Thanks TomKat!
|
|
|
|
|
Ok, it may seem like a stupid question, but i feel like i'm going nutts here.
I bought this book on Java, and i was reading some till i came accross this table with data types and their size in bits. Now, assuming (since Java seems to be derived from C) the main data types are the same as in C, a char would be 8 bits right? 1 byte... It's what i always thought though, cause when i open a file in my HEX editor i get one byte per character in the ASCII table.
But what do i see in my (btw reasonably cheap) book??? A char is 16 bits or 2 bytes in size!!!!!!!?????   
Am i going nutts (which is most probable), is this a printing error in my book, or does the fact that it says UNICODE behind the char in my book have something to do with it (which i doubt)..?
WHAT IS THE SIZE OF A CHAR IN C IN BYTES OR BITS??? I seek redemption from this insanity erghh i'll quit now lol
Kuniva
--------------------------------------------
|
|
|
|
|
An ASCII character is 8 bits or 1 byte long.
Kuphryn
|
|
|
|
|
WOOHO THANK U SOOOO MUCH! ![Rose | [Rose]](https://codeproject.freetls.fastly.net/script/Forums/Images/rose.gif) 
Kuniva
--------------------------------------------
|
|
|
|
|
A char variable in Java is 2 bytes. A char in variable C/C++ is one byte. This is related to the character encodings the languages use. Unicode characters are 2 bytes each.
--Mike--
THERE IS NO THERE IS NO BUT THERE IS
MAGIC PIXIE DUST BUSINESS GENIE CODE PROJECT ![Green Alien | [Alien]](https://codeproject.freetls.fastly.net/script/Forums/Images/alien.gif)
Homepage | RightClick-Encrypt | 1ClickPicGrabber
|
|
|
|
|
A CHAR is 8 bits SIGNED.
If you need to handle binary data, use UNSIGNED CHAR.
|
|
|
|
|
http://www.codeproject.com/string/CPPStringGuide1.asp -Give s an comprehensive overview of strings ,character
|
|
|
|
|
There's no iterator for stack ( as far as MSDN is concerned )
Is there a way to traverse the stack ?
Thanks.
Max.
Maximilien Lincourt
For success one must aquire one's self
|
|
|
|
|
One solution is a while loop and check the status of the stack via empty().
Kuphryn
|
|
|
|
|
Maximilien wrote:
There's no iterator for stack
That's right. Because you're only allowed to look at the top element.
If you *must* use a stack (rather than a list or deque) and *must* traverse it, you can always derive from std::stack and then access the underlying data container (yuk )
You should save yourself and your company years of grief by shooting yourself through the head immediately. Believe me, in the long run it'll turn out better for everyone. - Tyto (at arstechnica)
Awasu 1.0[^]: A free RSS reader with support for Code Project.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
