It seems to be a fair amount of MFC
来源:互联网 发布:优化网站的文件和资源 编辑:程序博客网 时间:2024/04/26 15:35
If one is dealing with an application that performs a lot of painting or drawing, the OnDraw function can spend a lot of time each time it is called by the framework. In this situation, if the user hides the application main window and brings it back again, he will be punished with a long waiting period to recover the original aspect of the view.
This boring waiting time can be saved if the application recovers the last drawn CDC bitmap whenever no redrawing is necessary. And that works fine if one is able to find out what is the clipping region that has to be saved (normally using BitBlt) and lately recovered.
It seems to be a fair amount of MFC and API functions that deal with this problem but no one seems to be able to provide the actual clipping region for a CDC and the visible region seems to be out of reach. We comment here some of them.
CWnd::GetUpdateRgn( CRgn* pRgn, BOOL bErase = FALSE ); Will give us the window update region, if it is invoked before beginpaint or before CDC is created. This region has to be intersected with the visible region of the window to obtain the really updated region.
APIs GetClipRgn(HDC hdc, HRGN hrgn ) and GetMetaRgn(HDC hdc, HRGN hrgn ); Those functions seem to be designed to fit our purposes but they are not given us the expected result.. In fact they are returning cero and they do not provide any useful info. After carefully reading, one can notice that Microsoft documentation states that
An application-defined clipping region is a clipping region identified by the SelectClipRgn function. It is not a clipping region created when the application calls the BeginPaint function.
If the user does not define a clipping region by means of SelectClipRgn the function simply indicates that there is none. This seems to be our case.
After several working days spent on this item, we do not have any good idea to get the visible region for a window and we are about to give up and let our users bored watching long unneeded redraws.
Does anyone have any suggestion to deal with this subject.
:
: This boring waiting time can be saved if the application recovers the last drawn CDC bitmap whenever no redrawing is necessary. And that works fine if one is able to find out what is the clipping region that has to be saved (normally using BitBlt) and lately recovered.
:
: It seems to be a fair amount of MFC and API functions that deal with this problem but no one seems to be able to provide the actual clipping region for a CDC and the visible region seems to be out of reach. We comment here some of them.
:
: CWnd::GetUpdateRgn( CRgn* pRgn, BOOL bErase = FALSE ); Will give us the window update region, if it is invoked before beginpaint or before CDC is created. This region has to be intersected with the visible region of the window to obtain the really updated region.
:
: APIs GetClipRgn(HDC hdc, HRGN hrgn ) and GetMetaRgn(HDC hdc, HRGN hrgn ); Those functions seem to be designed to fit our purposes but they are not given us the expected result.. In fact they are returning cero and they do not provide any useful info. After carefully reading, one can notice that Microsoft documentation states that
:
: An application-defined clipping region is a clipping region identified by the SelectClipRgn function. It is not a clipping region created when the application calls the BeginPaint function.
:
: If the user does not define a clipping region by means of SelectClipRgn the function simply indicates that there is none. This seems to be our case.
:
: After several working days spent on this item, we do not have any good idea to get the visible region for a window and we are about to give up and let our users bored watching long unneeded redraws.
:
: Does anyone have any suggestion to deal with this subject.
:
:
:
Good topic!
How many objects do you have on your document?
Also, what is a nature of your application?
I have a couple of things to say for improving drawing performance.
1. If you have complex little things you draw - try to compose them with a set of bitmaps from RC file. Do not draw pixels or polygons if it can be avoided. In most cases it can be done easy.
2. When the application comes from minimized state to a normal state - there is no clipping region - the whole client area will be painted.
3. Use CDC::RectVisible to detect areas which needs to be painted. Every object - whatever the real object form is - can be surrounded by a RECT, so you can detect with that function - does it really needs to be painted or not.
4. Use resource caching: if you have a 1000 lines drawn by a RED pen or whatever color it is, but it is the same color - do you do it every object:
HPEN hPen = CreatePen (...);
DrawObject (...);
DeleteObject (hPen);
do not do it 1000 times - do it once at the beginning of OnDraw() and use it 1000 times. Same goes for every GDI resource - BRUSH, FONT, etc. - all same things can be cached.
5. If you use a lot of bitmaps - cache them too - there is a lot involved in drawing a bitmap:
- create a memory DC,
- select bitmap into it,
- draw something,
- deselect bitmap,
- destroy memory DC.
Make a class for such memory DC - you will save 2 first steps and 2 last steps!
- It seems to be a fair amount of MFC
- the limit to the amount of thread from a process
- 无法启动Hbase hbase-default.xml file seems to be for and old version of HBase
- Interview tips----seems to be very useful
- This link seems to be broken
- Use MFC in a Static Library,This may be due to a corruption of the heap....
- hbase启动报错hbase-default.xml file seems to be for and old version of HBase
- hbase-default.xml file seems to be for an older version of HBase ,this version is 1.2.0
- How to be a friend of yourself
- 关于libtool: link: warning: libmemcached.la seems to be moved
- Intellij 14 the supplied javaHome seems to be invalid
- 'tools.jar'seems to be not in Android Studio
- tools.jar seems to be not in Android Studio
- Elton John ------Sorry seems to be the hardest
- Another git process seems to be running in this repository
- This may be due to a corruption of the heap, which indicates a bug in *.exe or any of the DLLs it has loaded.
- this may be due to a corruption of the heap, which indicates a bug in ... or any of the DLLs it has
- A man speaks truth 3 out of 4 times. He throws a die and reports it to be a 6. What is the probabili
- 菜鸟练习PAT(四)
- 0、0和数值“零”在指针上下文中不是一回事
- 创建和删除快捷方式以及判断是否有快捷方式
- C# 消除游戏
- 油田(Oil Deposits)
- It seems to be a fair amount of MFC
- 高斯模糊及实现
- Jquery----简单的选择
- 【NOIP2012】开车旅行
- 3518e运行HiIspTool.sh提示Isp init failed!
- 指针用操作符’*’和’->’,引用使用操作符’.’
- Android studio 下 配置AndroidAnnotation 环境
- 4.非必要不提供default constructor
- INT_MAX 定义在 LIMITS.H 中的无穷值