7 个解决方案
#1
贴个代码看看..起线程的
#2
这是很正常，对于线程占CPU时间比较长的，你应该适应地中间采用一下Sleep。即使是创建了线程，如果是一个长任务，而且占CPU比较高，那还是会出现假死情况，所以最好中间Sleep一下。
#3
都起线程了，主界面线程怎么可能假死？跟sleep有何关系？
#4
系统的资源使用不党吧，分配不合理
#5
windows并不是一个实时的OS如果你想搞一个实时性比较强的任务，UNIX。
其次WM_TIMER等是定时消息其意为系统在某段时间内定时向消息槽内压入消息，其响应取决于应用对消息的响应，如果想使用比较准确的时间请使用TimerEvent
其次WM_TIMER等是定时消息其意为系统在某段时间内定时向消息槽内压入消息，其响应取决于应用对消息的响应，如果想使用比较准确的时间请使用TimerEvent
#6
可能你子程序处理量太大了，占CPU时间太长导致主界面假死的现象
#7
简单的说要做出的效果像word，以页为单位，我用滑动条拖动，是要动态的计算出要到达的位置的，同时实时画出来。这个取根据滑动条到的POS相应要显示的页面当然不能是实时的啦，不然会卡死，假如计算量大的话。这时我就想过将要取的页面这操作做成异步的，用线程去取计算，弄好了回调到界面通知刷新，如还是在要显示的页面范围就显示，如果拖太快过了到下面的页面去了就显示白板，等相应的页面返回，这是在Onpain中做的。
现在的PDF阅读器，如Adobe，Foxit Reader等都是这样的原理。但它们除了可以像Word一样用滑动条控制外，还可以用Drag状态，直接在文档界面上拖动，页面相应的移动，但里面的数据是以页为单位实时计算出来的。我就是考虑拖太快时要如何不卡，速度也能跟得上，而且稳定性还要好。
我试过监听鼠标的LBUTTONDOWN，但我在计算好鼠标在屏上的位移后抛消息去取来要显示的页面时，这时CPU占用率较高，我如果鼠标拖动太快就后面几下都没有响应了，就出现了鼠标拖过去了，但界面没有时实的更新。这是在PreTranslateMessage中的响应都跟不上。我做了定时器去定时以一个位移处理，相当于稳定的移动页面，当移动到发消息去取相应的页面时，OnPain的响应都跟不上,同样出现了页面动着动着就卡了一下，然后又正常的速度移动，然后到要取页面时又卡，感觉抛消息去做的事情并未和VIEW这边异步。我怀疑是然VIEW, 当然，VIEW本身也是MFC在SDI下的消息要路由到也是要去抢资源的，不知是否在VIEW类里超的线程属于它的子线程，在一定程序上受限于VIEW，在CPU系统分配时间片资源给VIEW的时间片里去与VIEW共抢资源？
现在的PDF阅读器，如Adobe，Foxit Reader等都是这样的原理。但它们除了可以像Word一样用滑动条控制外，还可以用Drag状态，直接在文档界面上拖动，页面相应的移动，但里面的数据是以页为单位实时计算出来的。我就是考虑拖太快时要如何不卡，速度也能跟得上，而且稳定性还要好。
我试过监听鼠标的LBUTTONDOWN，但我在计算好鼠标在屏上的位移后抛消息去取来要显示的页面时，这时CPU占用率较高，我如果鼠标拖动太快就后面几下都没有响应了，就出现了鼠标拖过去了，但界面没有时实的更新。这是在PreTranslateMessage中的响应都跟不上。我做了定时器去定时以一个位移处理，相当于稳定的移动页面，当移动到发消息去取相应的页面时，OnPain的响应都跟不上,同样出现了页面动着动着就卡了一下，然后又正常的速度移动，然后到要取页面时又卡，感觉抛消息去做的事情并未和VIEW这边异步。我怀疑是然VIEW, 当然，VIEW本身也是MFC在SDI下的消息要路由到也是要去抢资源的，不知是否在VIEW类里超的线程属于它的子线程，在一定程序上受限于VIEW，在CPU系统分配时间片资源给VIEW的时间片里去与VIEW共抢资源？
#1
贴个代码看看..起线程的
#2
这是很正常，对于线程占CPU时间比较长的，你应该适应地中间采用一下Sleep。即使是创建了线程，如果是一个长任务，而且占CPU比较高，那还是会出现假死情况，所以最好中间Sleep一下。
#3
都起线程了，主界面线程怎么可能假死？跟sleep有何关系？
#4
系统的资源使用不党吧，分配不合理
#5
windows并不是一个实时的OS如果你想搞一个实时性比较强的任务，UNIX。
其次WM_TIMER等是定时消息其意为系统在某段时间内定时向消息槽内压入消息，其响应取决于应用对消息的响应，如果想使用比较准确的时间请使用TimerEvent
其次WM_TIMER等是定时消息其意为系统在某段时间内定时向消息槽内压入消息，其响应取决于应用对消息的响应，如果想使用比较准确的时间请使用TimerEvent
#6
可能你子程序处理量太大了，占CPU时间太长导致主界面假死的现象
#7
简单的说要做出的效果像word，以页为单位，我用滑动条拖动，是要动态的计算出要到达的位置的，同时实时画出来。这个取根据滑动条到的POS相应要显示的页面当然不能是实时的啦，不然会卡死，假如计算量大的话。这时我就想过将要取的页面这操作做成异步的，用线程去取计算，弄好了回调到界面通知刷新，如还是在要显示的页面范围就显示，如果拖太快过了到下面的页面去了就显示白板，等相应的页面返回，这是在Onpain中做的。
现在的PDF阅读器，如Adobe，Foxit Reader等都是这样的原理。但它们除了可以像Word一样用滑动条控制外，还可以用Drag状态，直接在文档界面上拖动，页面相应的移动，但里面的数据是以页为单位实时计算出来的。我就是考虑拖太快时要如何不卡，速度也能跟得上，而且稳定性还要好。
我试过监听鼠标的LBUTTONDOWN，但我在计算好鼠标在屏上的位移后抛消息去取来要显示的页面时，这时CPU占用率较高，我如果鼠标拖动太快就后面几下都没有响应了，就出现了鼠标拖过去了，但界面没有时实的更新。这是在PreTranslateMessage中的响应都跟不上。我做了定时器去定时以一个位移处理，相当于稳定的移动页面，当移动到发消息去取相应的页面时，OnPain的响应都跟不上,同样出现了页面动着动着就卡了一下，然后又正常的速度移动，然后到要取页面时又卡，感觉抛消息去做的事情并未和VIEW这边异步。我怀疑是然VIEW, 当然，VIEW本身也是MFC在SDI下的消息要路由到也是要去抢资源的，不知是否在VIEW类里超的线程属于它的子线程，在一定程序上受限于VIEW，在CPU系统分配时间片资源给VIEW的时间片里去与VIEW共抢资源？
现在的PDF阅读器，如Adobe，Foxit Reader等都是这样的原理。但它们除了可以像Word一样用滑动条控制外，还可以用Drag状态，直接在文档界面上拖动，页面相应的移动，但里面的数据是以页为单位实时计算出来的。我就是考虑拖太快时要如何不卡，速度也能跟得上，而且稳定性还要好。
我试过监听鼠标的LBUTTONDOWN，但我在计算好鼠标在屏上的位移后抛消息去取来要显示的页面时，这时CPU占用率较高，我如果鼠标拖动太快就后面几下都没有响应了，就出现了鼠标拖过去了，但界面没有时实的更新。这是在PreTranslateMessage中的响应都跟不上。我做了定时器去定时以一个位移处理，相当于稳定的移动页面，当移动到发消息去取相应的页面时，OnPain的响应都跟不上,同样出现了页面动着动着就卡了一下，然后又正常的速度移动，然后到要取页面时又卡，感觉抛消息去做的事情并未和VIEW这边异步。我怀疑是然VIEW, 当然，VIEW本身也是MFC在SDI下的消息要路由到也是要去抢资源的，不知是否在VIEW类里超的线程属于它的子线程，在一定程序上受限于VIEW，在CPU系统分配时间片资源给VIEW的时间片里去与VIEW共抢资源？