• <ins id="pjuwb"></ins>
    <blockquote id="pjuwb"><pre id="pjuwb"></pre></blockquote>
    <noscript id="pjuwb"></noscript>
          <sup id="pjuwb"><pre id="pjuwb"></pre></sup>
            <dd id="pjuwb"></dd>
            <abbr id="pjuwb"></abbr>
            萬星星@豌豆莢 歡迎加入我們
            一個(gè)吃軟飯的男人!!!!!我只想寫程序####
            微博:http://weibo.com/wanlianwen
            posts - 172,  comments - 1253,  trackbacks - 0

            最近工作上比較忙,加之編碼任務(wù)較多,沒來得及繼續(xù)之前的講解。抽出時(shí)間把這最重要的一部分東西做個(gè)闡述。行文以基本的編程思維及個(gè)人思考過程為線索。

             

            眾所周知,RichEdir強(qiáng)大在于其圖文混排(在這里不跟Word、HTML比),其中的圖替換為動(dòng)態(tài)圖的核心問題就歸結(jié)于如何高效刷新。我們知道GDI操作是最消耗CPU的,所以刷新整個(gè)RichEdit窗口是不可取的,其副作用會(huì)導(dǎo)致更嚴(yán)重的閃爍問題。解決問題的思路很簡(jiǎn)單:類似于拖拽時(shí)候在屏幕繪制異或線,我們的動(dòng)畫重繪時(shí)不請(qǐng)求RichEdit,而直接在其窗口的DC上繪制當(dāng)前動(dòng)畫幀,此時(shí)缺少是如何確定該OLE的位置,這個(gè)是所有問題的關(guān)鍵。先看下面這幅圖:

             

            假定1-5全部都是GIF圖片,非GIF可以暫時(shí)無視,這個(gè)后面大家會(huì)非常清楚如何處理。在這個(gè)過程中,2不見了,而4是新出現(xiàn)的。對(duì)于4新出現(xiàn)時(shí),RichEdit自身肯定會(huì)觸發(fā)其:

            Draw(
                DWORD dwDrawAspect, LONG lindex, void* pvAspect,
                DVTARGETDEVICE* ptd, HDC hicTargetDev, HDC hdcDraw,
                LPCRECTL prcBounds, LPCRECTL prcWBounds,
                BOOL (__stdcall *pfnContinue)(DWORD_PTR dwContinue),
                DWORD_PTR dwContinue)

             

            這個(gè)時(shí)候,我們知道新的GIF圖片進(jìn)入可視區(qū),可以把它添加到集合中。對(duì)于2的動(dòng)畫觸發(fā)時(shí)間到來時(shí),我們可以確定其位置且與可視區(qū)比對(duì),發(fā)現(xiàn)其不再可視區(qū),則從集合中移除。這樣就可以得到一個(gè)接近于(略大于)當(dāng)前視口中的動(dòng)畫控件集合,當(dāng)有新的動(dòng)畫觸發(fā)時(shí)間到來時(shí),我們可以先檢查其是否在可視區(qū),如果不在則不用GDI操作,僅僅更新其當(dāng)前幀。當(dāng)然這些工作你也可以不做,但是在動(dòng)畫控件數(shù)量大的時(shí)候效率可能略有下降,主要是查找的過程(索引、位置)比較耗時(shí)。

             

            如何確定一個(gè)OLE的位置呢?由于我們插入OLE都使用了REO_BELOWBASELINE標(biāo)志,也就是跟當(dāng)前行的底部對(duì)齊,所以O(shè)LE左下角位置的精確度對(duì)我們來說很重要。看下圖:

            假設(shè)圖中黑框是一個(gè)OLE對(duì)象,其字符索引為CPN,假定第N+1行的第一個(gè)字符索引為CPN1,那么OLE左下角坐標(biāo)={PosFromChar(CPN).x, PosFromChar(CPN1).y },PosFromChar這個(gè)是RichEdit提供的。問題的關(guān)鍵是最后一行怎么計(jì)算?此時(shí)沒有第N+1行。對(duì)于這種特殊情況,主要是Y坐標(biāo)的計(jì)算,可以這樣考慮:Y=RichEdit內(nèi)容高度-滾動(dòng)條位置。猜測(cè): 計(jì)算內(nèi)容高度可能比較耗時(shí),故QQ的聊天消息顯示部分強(qiáng)制在底部加了一行,以避免這種情況出現(xiàn)。

             

            得到左下角位置以后,可能你會(huì)覺得就萬事大吉了。錯(cuò)!還有一個(gè)關(guān)鍵點(diǎn)!我們可以通過OLE的接口GetExtent得到其大小,然而這個(gè)大小沒有考慮縮放比例,所以你需要根據(jù)當(dāng)前縮放比例進(jìn)行計(jì)算,而這個(gè)計(jì)算牽扯到浮點(diǎn)數(shù)運(yùn)算,過程中的來回不僅麻煩而且不精確,所以O(shè)LE的可視大小要想非常精確是不能通過計(jì)算來的。我們前面知道OLE繪制的時(shí)候會(huì)傳入可視范圍,假如我們保存下來是不是就可以解決問題了呢?當(dāng)然,顯然,你可以試試!

            這些問題主要原因是RichEdit的很多接口方法沒有暴露,而Win8的SDK會(huì)做重大升級(jí),很多之前的問題都會(huì)變成不是問題,或許還會(huì)引起更多的新特性,但是動(dòng)畫本身的邏輯還是需要自己實(shí)現(xiàn),或者會(huì)簡(jiǎn)單許多,至于多少我還尚不清楚,但是目前來看這種方案效率足夠! 

             

            到了這里,核心技術(shù)應(yīng)該大白天下,整個(gè)過程,我追求了位置的精準(zhǔn)度,并據(jù)此獲得最小可視集合進(jìn)行刷新優(yōu)化。

             

            最新SDK&Demo,參見:http://code.google.com/p/im-solution/。希望你會(huì)喜歡!

            posted on 2012-09-08 18:10 萬連文 閱讀(4831) 評(píng)論(16)  編輯 收藏 引用 所屬分類: 小作品richedit

            FeedBack:
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2012-09-08 19:09 | iunkown
            問一下,GIF對(duì)應(yīng)的IOleInPlaceSite::GetWindowContext 取到的位置是否準(zhǔn)確?為什么要用GetExtent呢?

            我的一個(gè)實(shí)驗(yàn)DEMO的SOURCE CODE如下,
            http://www.shnenglu.com/Files/mcs51a/GifDisplayCtrl.rar

            DEMO中代碼比較偷懶,可能有不準(zhǔn)確的地方  回復(fù)  更多評(píng)論
              
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2012-09-08 19:39 | 萬連文
            @iunkown
            這個(gè)我沒有測(cè)試過,也沒有考慮過,不過確實(shí)是一種思路,你可以自己確認(rèn)。但是我的方法未嘗不是好方法,不是么?


            后來我看了你的東西,覺得就是前面說的毫無章法,無頭蒼蠅。你的那個(gè)鏈接我看了,連運(yùn)行一下的心情都木有。  回復(fù)  更多評(píng)論
              
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2012-09-08 20:04 | 路障
            呵呵,萬大俠,我之前以為你用了OLE接口的其它方法刷新的,原來也是直接在DC上面繪制的。

            我還想問個(gè)問題,當(dāng)你在DC上面繪制GIF幀的時(shí)候,你如何獲取RichEdit的背景顏色或者背景圖片?因?yàn)樽约褐苯釉贒C上面繪制時(shí),是不會(huì)像在OLE接口的Draw()函數(shù)里面那樣,已經(jīng)由系統(tǒng)先繪制了背景的。  回復(fù)  更多評(píng)論
              
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2012-09-08 20:06 | 萬連文
            @路障
            看我的Demo,看我的接口,你就會(huì)發(fā)現(xiàn)我是怎么做的!!給我點(diǎn)面子唄。  回復(fù)  更多評(píng)論
              
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2012-09-09 11:30 | Loaf
            一直RSS,博主非常高產(chǎn)啊……  回復(fù)  更多評(píng)論
              
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2012-09-09 12:32 | 萬連文
            @Loaf
            其實(shí)我非常少做項(xiàng)目,很多工作時(shí)間用來搞這些興趣。

            我個(gè)人表示對(duì)RSS不太了解,有點(diǎn)土鱉。  回復(fù)  更多評(píng)論
              
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2012-09-09 15:50 | 路障
            @萬連文

            萬大俠,之前的評(píng)論絕對(duì)沒有取笑的意思。還是多虧了萬大俠,提供了這么多篇網(wǎng)上幾乎沒有詳細(xì)講的教程,使我們受益良多。否則還要走更多的彎路呢。繼續(xù)膜拜萬大俠。
              回復(fù)  更多評(píng)論
              
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2012-09-12 14:07 | M77
            @Loaf

            google Reader的RSS鏈接出現(xiàn)錯(cuò)誤了
              回復(fù)  更多評(píng)論
              
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2012-09-12 14:09 | M77
            @萬連文
            樓主這SDK頭文件寫得很有Google的范  回復(fù)  更多評(píng)論
              
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2012-09-12 14:28 | 萬連文
            @M77
            過獎(jiǎng),回頭一看又發(fā)現(xiàn)幾個(gè)不標(biāo)準(zhǔn)的地方,努力遵守Google規(guī)范。  回復(fù)  更多評(píng)論
              
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2013-01-05 03:28 | 程旭
            慨嘆天下文章一大抄,天下程序也是一大抄,就看你怎么抄,抄的有沒有思想,呵呵。老萬研究很透徹,盡管描述不適合初學(xué)者,但是非常不錯(cuò)了。  回復(fù)  更多評(píng)論
              
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2013-01-05 20:36 | 程旭
            全部重建感覺放棄ATL太浪費(fèi),盡管Ctrl鍵按的次數(shù)不多,呵呵。重建了Create其他可以沿用ATL也可以,這方面效率沒影響。繪制方法對(duì)效率可差萬倍。所以重點(diǎn)還是對(duì)richedit的擴(kuò)展,STL使用必不可少,不嫌費(fèi)事當(dāng)然可以自己寫鏈表之類的。不知 萬老師 現(xiàn)在又開始研究什么新東西了?  回復(fù)  更多評(píng)論
              
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2013-01-05 22:54 | 萬連文
            @程旭
            最近這幾個(gè)月從研究webkit,轉(zhuǎn)向虛擬機(jī)字節(jié)碼,然后有轉(zhuǎn)向IDA OD學(xué)習(xí),比較閑散自由無目的,但是沒有偷懶就好。  回復(fù)  更多評(píng)論
              
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2013-01-07 01:16 | 程旭
            @萬連文
            IDA對(duì)沒加密的很好用,OD對(duì)付加密的絕佳。  回復(fù)  更多評(píng)論
              
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2013-01-11 07:14 | 程旭
            600動(dòng)態(tài)表情同時(shí)顯示,CPU占用1%也許0%。  回復(fù)  更多評(píng)論
              
            # re: richedit研究06 – 高效動(dòng)畫刷新
            2013-05-21 16:25 | 楊瀟
            我來這里是為了感謝博主@萬連文 的。博主提供了從動(dòng)畫OLE類要實(shí)現(xiàn)的接口,到如何精確地找出需重繪的動(dòng)畫這一整套信息,在思路上的參考價(jià)值再怎么高估也不過分。

            同時(shí),通過對(duì)微軟WindowlessRE項(xiàng)目的參考,我終于成功地將無窗口模式的RichEdit、RichEdit動(dòng)畫控件集成到了我們內(nèi)部自己實(shí)現(xiàn)的DirectUI界面之中。

            萬大俠提供的思路讓我節(jié)省了大量時(shí)間,少走了N多彎路。

            再次謝謝萬大俠的分享!
              回復(fù)  更多評(píng)論
              
            簡(jiǎn)歷下載
            聯(lián)系我

            <2006年4月>
            2627282930311
            2345678
            9101112131415
            16171819202122
            23242526272829
            30123456

            常用鏈接

            留言簿(66)

            隨筆分類

            隨筆檔案

            相冊(cè)

            搜索

            •  

            最新評(píng)論

            閱讀排行榜

            評(píng)論排行榜

            久久免费99精品国产自在现线| 国产精品久久久久乳精品爆| 国产成人无码精品久久久性色| 久久久精品人妻一区二区三区蜜桃| 亚洲中文字幕无码久久综合网| 狠狠88综合久久久久综合网| 99热都是精品久久久久久| 亚洲AⅤ优女AV综合久久久| 无码人妻精品一区二区三区久久久 | 无码专区久久综合久中文字幕 | 久久亚洲AV无码西西人体| 久久久久免费精品国产| 国产高潮国产高潮久久久91| 亚洲另类欧美综合久久图片区| 久久久久亚洲av无码专区导航| 久久久精品国产Sm最大网站| 久久99国产综合精品| 久久人妻少妇嫩草AV蜜桃| 国内精品久久久久久不卡影院 | 婷婷久久综合九色综合九七| 国产∨亚洲V天堂无码久久久| 无码八A片人妻少妇久久| 99久久国产综合精品五月天喷水| 久久一日本道色综合久久| 久久精品免费全国观看国产| 色天使久久综合网天天| 国产精品青草久久久久福利99| 亚洲精品高清国产一久久| 99久久久精品免费观看国产| 亚洲级αV无码毛片久久精品| 亚洲午夜无码久久久久小说| 亚洲国产精品无码久久久久久曰| 国产激情久久久久影院| 99久久国产亚洲高清观看2024| 69久久夜色精品国产69| 精品久久久久久亚洲| 日本道色综合久久影院| 精品国产青草久久久久福利| 久久久久人妻精品一区三寸蜜桃| 久久久久久国产a免费观看不卡| 久久国产高清一区二区三区|