簡(jiǎn)介面向C#入門開發(fā)者與WinForm愛好者的一份滾動(dòng)字幕程序源碼包演示了如何借助Timer控件實(shí)現(xiàn)多方向滾動(dòng)字幕和暫停/繼續(xù)控制適合作為理解桌面動(dòng)畫與事件驅(qū)動(dòng)編程的趣味練習(xí)項(xiàng)目。壓縮包共25個(gè)文件體積僅41KB主要包含6個(gè)cs源碼文件、resx/resources資源文件、可直接運(yùn)行的exe可執(zhí)行程序以及pdb調(diào)試符號(hào)等結(jié)構(gòu)簡(jiǎn)潔便于對(duì)照源碼和運(yùn)行效果快速上手。目前已有741人學(xué)習(xí)下載。通過學(xué)習(xí)該程序可以掌握WinForm窗體布局、Timer定時(shí)觸發(fā)機(jī)制、字幕位置更新邏輯、雙緩沖繪制以避免閃爍等核心思路同時(shí)還能擴(kuò)展?jié)L動(dòng)方向、字體顏色和速度調(diào)節(jié)等自定義功能是一份輕量但完整的小型C#桌面應(yīng)用參考。無論是鞏固基礎(chǔ)還是尋找創(chuàng)意靈感都能從中獲得實(shí)際收益。 滾動(dòng)字幕這種需求干過工業(yè)上位機(jī)和門店信息發(fā)布的朋友應(yīng)該都不陌生。車間大屏滾生產(chǎn)計(jì)劃門店門口滾促銷信息會(huì)議室門口滾會(huì)議安排場(chǎng)景一大堆。我之前被分配過一個(gè)需求要在不引第三方控件的前提下做一個(gè)滾動(dòng)字幕的Winform版用C#實(shí)現(xiàn)。當(dāng)時(shí)第一反應(yīng)是找一個(gè)現(xiàn)成的跑馬燈控件結(jié)果試了幾個(gè)要么有廣告版權(quán)問題要么封裝太死沒法自定義字體和速度要么滾動(dòng)時(shí)屏閃得厲害。最后決定完整寫一個(gè)反而是這個(gè)決定讓我把Winform里的幾個(gè)重要機(jī)制徹底搞明白了。這篇內(nèi)容不光是給一個(gè)能跑的代碼更想把滾動(dòng)字幕背后涉及的Timer驅(qū)動(dòng)機(jī)制、GDI重繪、雙緩沖抗閃爍、DPI自適應(yīng)等問題一次講透。很多人在網(wǎng)上找滾動(dòng)字幕的代碼拿下來能跑但換個(gè)環(huán)境就露餡其實(shí)都是栽在這些小細(xì)節(jié)上。這篇文章適合兩類人一是剛學(xué)C#想找一個(gè)練手項(xiàng)目的初學(xué)者二是做上位機(jī)或者信息發(fā)布系統(tǒng)需要把滾動(dòng)字幕真正集成到業(yè)務(wù)里的開發(fā)者。1. 滾動(dòng)字幕這件事業(yè)務(wù)場(chǎng)景與技術(shù)定位滾動(dòng)字幕看起來是個(gè)不起眼的小功能但它的技術(shù)覆蓋面其實(shí)很廣涉及定時(shí)器、圖形繪制、文本測(cè)量、控件生命周期管理等多個(gè)Winform核心知識(shí)點(diǎn)。1.1 滾動(dòng)字幕真正高頻出現(xiàn)的場(chǎng)景我在實(shí)際項(xiàng)目里遇到過的滾動(dòng)字幕需求大概有這么幾類工業(yè)制造現(xiàn)場(chǎng)車間大屏輪播生產(chǎn)計(jì)劃、設(shè)備狀態(tài)、異常告警信息。這類場(chǎng)景通常7x24小時(shí)連續(xù)運(yùn)行對(duì)穩(wěn)定性和流暢度要求最高。商業(yè)門店終端促銷活動(dòng)、到貨通知、排隊(duì)叫號(hào)信息滾動(dòng)展示這類場(chǎng)景更在意外觀和展示效果。辦公會(huì)議場(chǎng)景會(huì)議室門口的門牌屏、前臺(tái)訪客引導(dǎo)屏滾動(dòng)顯示會(huì)議安排和訪客信息。車載和交通場(chǎng)景車內(nèi)信息屏、站臺(tái)到站信息屏這類場(chǎng)景對(duì)透明度和覆蓋層級(jí)有特殊要求。這些場(chǎng)景有一個(gè)共同特點(diǎn)文字內(nèi)容會(huì)動(dòng)態(tài)更新而且往往需要在較遠(yuǎn)距離上讓路過的人一眼掃到關(guān)鍵信息。靜態(tài)文字的信息承載量太低滾動(dòng)字幕正好解決這個(gè)矛盾。如果你只搜滾動(dòng)字幕Winform看到的代碼片段多數(shù)是TextBox或者Label往左挪你拿過去一用就能發(fā)現(xiàn)各種問題閃爍、速度不勻、字體發(fā)虛、縮放后錯(cuò)位。所以這篇我想把背后的機(jī)制講清楚而不是只貼一段代碼讓你復(fù)制。1.2 為什么不直接用第三方滾動(dòng)控件我知道很多人第一反應(yīng)是去NuGet上找跑馬燈控件這很正常我也試過。但踩過坑之后我的判斷是除非時(shí)間極其緊張否則自己寫一個(gè)滾動(dòng)字幕性價(jià)比遠(yuǎn)高于引入第三方控件。第三方控件的典型問題封裝過度難定制想改成從右向左帶漸隱效果想滾動(dòng)到末尾后自動(dòng)切換內(nèi)容很多控件要么沒有現(xiàn)成接口要么你要去讀它的源碼才能動(dòng)。依賴鏈太長(zhǎng)一個(gè)滾動(dòng)控件可能拖一堆依賴庫(kù)進(jìn)來發(fā)布時(shí)體積變大還可能出現(xiàn)版本沖突。閃爍和性能不可控有些控件底層實(shí)現(xiàn)方式落后直接往窗體上疊Label然后改Left高分辨率或者內(nèi)容較長(zhǎng)時(shí)幀率慘不忍睹。歷史包袱和安全隱患NuGet上的第三方控件質(zhì)量參差不齊有些還捆綁了更新檢查或者授權(quán)校驗(yàn)邏輯放到客戶的生產(chǎn)環(huán)境里很不放心。自己實(shí)現(xiàn)的優(yōu)勢(shì)非常直接代碼全部可控一個(gè)類搞定沒有多余的依賴出問題能一行一行查而且可以按業(yè)務(wù)需求隨意加功能。說實(shí)話滾動(dòng)字幕的核心驅(qū)動(dòng)邏輯并不復(fù)雜自己寫一遍你對(duì)Winform的理解會(huì)提升一個(gè)臺(tái)階。1.3 技術(shù)選型LabelTimer 還是 GDI 自繪滾動(dòng)字幕實(shí)現(xiàn)路線有兩條這是最關(guān)鍵的選型決策路線ALabel控件 Timer定時(shí)器每次Tick里將Label的Left屬性減一個(gè)固定值實(shí)現(xiàn)向左移動(dòng)。代碼量最少但是會(huì)有一堆隱藏問題下文詳細(xì)展開。路線BGDI自繪 Timer定時(shí)器觸發(fā)重繪在窗體的OnPaint事件里用Graphics.DrawString自行繪制文本用一個(gè)偏移量變量控制繪制位置每次Tick將偏移量遞減然后觸發(fā)Invalidate重繪。兩條路線我都實(shí)際寫過我的結(jié)論是如果你要做的是一個(gè)能交付的項(xiàng)目直接走路線B。原因在于控件位移方式的滾動(dòng)效果在字號(hào)較大、速度較快、屏幕分辨率較高時(shí)會(huì)明顯出現(xiàn)撕裂感和閃爍而自繪方式配合雙緩沖可以在任何尺寸下都保持平滑視覺。還有一條中間路線是使用Panel容器 內(nèi)部Panel移動(dòng)本質(zhì)上是路線A的變種控制更靈活一些但依然逃不開控件級(jí)重繪的性能天花板。除非你要滾動(dòng)的內(nèi)容里還包含圖片、按鈕等交互控件否則沒必要走這條。2. 滾動(dòng)機(jī)制拆解從Timer到坐標(biāo)位移再到重繪既然定了用自繪方案就得把底層每個(gè)機(jī)制都搞明白。滾動(dòng)字幕的本質(zhì)非常簡(jiǎn)單一個(gè)在水平方向不斷變化的繪制坐標(biāo)。但要做到看起來舒服、跑久了不崩需要理解幾個(gè)關(guān)鍵環(huán)節(jié)。2.1 滾動(dòng)視覺的本質(zhì)每個(gè)時(shí)間片移動(dòng)一小段距離人眼看到的連續(xù)滾動(dòng)其實(shí)是文字在離散時(shí)間片上不斷改變位置的結(jié)果。每一次定時(shí)器觸發(fā)文字的位置就向左挪動(dòng)幾個(gè)像素因?yàn)闀r(shí)間片足夠短、位移足夠小人眼就感知為平滑運(yùn)動(dòng)。這里有一個(gè)公式貫穿整個(gè)實(shí)現(xiàn)// 每次刷新時(shí)文字需要偏移的像素量 float offsetPerTick scrollSpeed * timerInterval / 1000f;其中scrollSpeed是滾動(dòng)速度像素/秒timerInterval是定時(shí)器觸發(fā)間隔毫秒。舉例來說速度設(shè)定為50像素/秒Timer間隔設(shè)為20毫秒每秒觸發(fā)50次那么每次觸發(fā)文字移動(dòng)1像素。如果間隔是40毫秒那每次就要移動(dòng)2像素。這個(gè)換算關(guān)系是整個(gè)滾動(dòng)平滑度的基礎(chǔ)。為什么刻意強(qiáng)調(diào)像素/秒而不是像素/Tick因?yàn)門imer的觸發(fā)間隔在不同機(jī)器上、不同負(fù)載下會(huì)有微小波動(dòng)用時(shí)間作為速度單位即使Timer間隔因?yàn)橄到y(tǒng)繁忙產(chǎn)生波動(dòng)文字移動(dòng)的總距離仍然是穩(wěn)定的。2.2 首版實(shí)現(xiàn)最簡(jiǎn)單的Label移動(dòng)方式先把最直覺的方式寫出來看看問題在哪。新建一個(gè)窗體拖一個(gè)Label設(shè)置其為AutoSize true隨便給個(gè)文字然后掛一個(gè)Timerpublic partial class Form1 : Form { private Timer _timer new Timer(); private int _speed 2; // 每Tick移動(dòng)像素?cái)?shù) public Form1() { InitializeComponent(); _timer.Interval 30; _timer.Tick (s, e) { lblText.Left - _speed; if (lblText.Right 0) { lblText.Left this.ClientSize.Width; } }; _timer.Start(); } }這段代碼的核心邏輯每個(gè)Tick將Label的Left減掉速度值當(dāng)Label完全移出左邊屏幕后重置到右邊屏幕外重新進(jìn)入。邏輯本身沒錯(cuò)跑起來也能看到滾動(dòng)效果但實(shí)際一用問題接踵而至。最明顯的問題是Label在移動(dòng)過程中的閃爍非常嚴(yán)重。原因在于Winform控件每次移動(dòng)位置都會(huì)觸發(fā)整個(gè)Label區(qū)域的重新繪制而默認(rèn)情況下這個(gè)重繪是不帶雙緩沖的系統(tǒng)先擦掉原來的圖像再畫新的中間露出的背景短暫可見肉眼就捕捉到了閃爍。第二個(gè)問題是當(dāng)滾動(dòng)速度調(diào)高時(shí)文字視覺上會(huì)有明顯跳的感覺。因?yàn)槊縏ick移動(dòng)的像素?cái)?shù)大了而Timer的間隔又不完全均勻所以速度看起來時(shí)快時(shí)慢。還有一個(gè)隱藏問題如果窗體上有多個(gè)滾動(dòng)文字左滾一個(gè)右滾一個(gè)會(huì)引入大量控件每個(gè)控件都有自己的句柄和消息循環(huán)整體性能會(huì)明顯下降。2.3 成熟方案GDI自繪方式的完整實(shí)現(xiàn)明白了Label方案的種種痛點(diǎn)我最終的落地實(shí)現(xiàn)是全部用GDI自繪。核心類只維護(hù)一個(gè)偏移量字段每次Timer觸發(fā)修改它然后調(diào)用Invalidate()讓窗體重繪。真正的繪制邏輯全在OnPaint里。先看核心渲染邏輯public class MarqueeControl : Control { private string _displayText ; private float _offsetX 0; private float _scrollSpeed 60f; // 像素/秒 private Timer _timer; private float _textWidth 0; private bool _isPaused false; public MarqueeControl() { SetStyle(ControlStyles.AllPaintingInWmPaint | ControlStyles.OptimizedDoubleBuffer | ControlStyles.ResizeRedraw | ControlStyles.UserPaint, true); _timer new Timer(); _timer.Interval 15; _timer.Tick OnTimerTick; _timer.Start(); this.Font new Font(微軟雅黑, 14f, FontStyle.Bold); this.ForeColor Color.White; this.BackColor Color.FromArgb(30, 30, 30); } public string DisplayText { get _displayText; set { _displayText value ?? ; _offsetX this.ClientSize.Width; // 重新設(shè)置內(nèi)容時(shí)從右側(cè)開始進(jìn)入 _textWidth MeasureTextWidth(); Invalidate(); } } protected override void OnPaint(PaintEventArgs e) { base.OnPaint(e); e.Graphics.SmoothingMode System.Drawing.Drawing2D.SmoothingMode.AntiAlias; e.Graphics.TextRenderingHint System.Drawing.Text.TextRenderingHint.ClearTypeGridFit; var brush new SolidBrush(this.ForeColor); var point new PointF(_offsetX, (this.ClientSize.Height - this.Font.Height) / 2f); e.Graphics.DrawString(_displayText, this.Font, brush, point); brush.Dispose(); } private void OnTimerTick(object sender, EventArgs e) { if (_isPaused) return; float deltaPixels _scrollSpeed * _timer.Interval / 1000f; _offsetX - deltaPixels; // 文字完全移出左側(cè)后重置到右側(cè)外 if (_offsetX _textWidth 0) { _offsetX this.ClientSize.Width; } Invalidate(); } private float MeasureTextWidth() { using (var g this.CreateGraphics()) { return g.MeasureString(_displayText, this.Font).Width; } } }這個(gè)自定義控件放到窗體上設(shè)置一下DisplayText屬性就可以工作。幾個(gè)關(guān)鍵點(diǎn)在代碼里都標(biāo)注了。關(guān)于Font.Height和MeasureString的區(qū)別多說一句Font.Height是字體的行高從基線到基線把它作為垂直居中的基準(zhǔn)視覺效果一般OK。MeasureString返回的是精確的文本繪制寬度在滾動(dòng)邊界判斷時(shí)必須用這個(gè)否則容易出現(xiàn)文字已經(jīng)看不到了但還在繼續(xù)跑或者還沒跑完就重置的錯(cuò)誤。需要注意的是上面的MeasureTextWidth方法里用了this.CreateGraphics()來做臨時(shí)測(cè)量。如果在InitializeComponent階段或者窗體句柄還沒創(chuàng)建時(shí)調(diào)用CreateGraphics可能會(huì)拋出ObjectDisposedException。更穩(wěn)妥的做法是重寫OnHandleCreated在句柄創(chuàng)建之后初始化文本寬度或者采用冪等方式在嘗試測(cè)量時(shí)如果失敗就暫時(shí)返回估算值下次重繪時(shí)再校正。3. 工程化落地窗體布局、速度調(diào)節(jié)與雙緩沖細(xì)節(jié)代碼能跑只是第一步真正做項(xiàng)目時(shí)要考慮的是窗體如何擺放、如何調(diào)速、如何防止閃爍、內(nèi)容從哪來。這一節(jié)我講工程化落地時(shí)反復(fù)確認(rèn)過的細(xì)節(jié)。3.1 字幕窗體的布局與置頂策略滾動(dòng)字幕一般是嵌在其他界面里的但也有很多場(chǎng)景是需要一個(gè)獨(dú)立的全屏/半透明小子窗體貼在屏幕底部。我做過一個(gè)版本窗體本身不顯示邊框只顯示文字滾動(dòng)區(qū)域背景半透明置頂顯示。// 無邊框、置頂、窗口不顯示在任務(wù)欄 this.FormBorderStyle FormBorderStyle.None; this.TopMost true; this.ShowInTaskbar false; // 定位在屏幕底部以主屏為例 Rectangle workingArea Screen.PrimaryScreen.WorkingArea; this.StartPosition FormStartPosition.Manual; this.Location new Point(workingArea.Left, workingArea.Bottom - this.Height); this.Width workingArea.Width;這里有幾個(gè)容易忽略的地方WorkingArea和Bounds的區(qū)別WorkingArea已經(jīng)排除了任務(wù)欄占用的區(qū)域如果用Bounds窗體會(huì)被任務(wù)欄擋住一部分。TopMost和TopMostOwner的區(qū)別TopMost true會(huì)讓窗體一直浮在所有普通窗體的上面這在信息發(fā)布場(chǎng)景里很好用但在某些業(yè)務(wù)系統(tǒng)里會(huì)遮擋操作界面要小心取舍。如果希望只在某個(gè)主窗體上面顯示應(yīng)該設(shè)置Owner而不是用全局TopMost。無邊框窗體怎么拖動(dòng)如果要做成允許用戶拖動(dòng)位置需要在MouseDown事件中實(shí)現(xiàn)手動(dòng)移動(dòng)邏輯或者干脆不做固定位置。3.2 自繪控件的雙緩沖為什么必須開很多初學(xué)者在做滾動(dòng)字幕時(shí)發(fā)現(xiàn)文字有殘影或者閃爍搜了一堆雙緩沖的資料還是不知道怎么在自繪控件里正確配置。這里給出一個(gè)在C# Winform自繪控件中開啟雙緩沖的標(biāo)準(zhǔn)姿勢(shì)SetStyle(ControlStyles.AllPaintingInWmPaint | ControlStyles.OptimizedDoubleBuffer | ControlStyles.UserPaint, true);這三個(gè)標(biāo)志位各管各的AllPaintingInWmPaint告訴系統(tǒng)這個(gè)消息不需要被擦除。沒有它系統(tǒng)會(huì)在繪制前先擦除背景形成先白后畫的閃爍感。OptimizedDoubleBuffer將繪制內(nèi)容先在內(nèi)存中的緩沖區(qū)畫好再一次性地輸出到屏幕避免局部更新帶來的撕裂。UserPaint允許控件用自己的代碼來繪制界面而不是依賴系統(tǒng)默認(rèn)繪制。組合起來的效果是每次重繪都在后臺(tái)緩沖區(qū)完成然后一次性刷到屏幕視覺上徹底解決閃爍。另外注意如果你的滾動(dòng)字幕控件上還有子控件雙緩沖不適用于子控件。所以盡量不要在字幕區(qū)域里再疊控件保持純自繪即可。3.3 調(diào)速與暫停把交互做進(jìn)業(yè)務(wù)系統(tǒng)在工業(yè)現(xiàn)場(chǎng)使用時(shí)操作員往往需要調(diào)節(jié)滾動(dòng)速度或者讓字幕停下來便于仔細(xì)閱讀。所以一個(gè)能交付的滾動(dòng)字幕程序必須提供調(diào)速和暫停接口而不是寫死在代碼里。我最終把速度設(shè)計(jì)成了公開屬性單位是像素/秒由上層業(yè)務(wù)代碼來設(shè)置。調(diào)速的底層實(shí)現(xiàn)很簡(jiǎn)單Timer的Tick頻率不變每次移動(dòng)的像素量由速度屬性換算private float _scrollSpeed 60f; public float ScrollSpeed { get _scrollSpeed; set { _scrollSpeed Math.Max(5f, value); // 避免速度過低產(chǎn)生卡頓感 Invalidate(); } } public bool IsPaused { get _isPaused; set { _isPaused value; if (!_isPaused) { Invalidate(); // 恢復(fù)時(shí)立刻刷一幀避免停頓 } } }為什么最低限制為5像素/秒因?yàn)槿绻俣忍臀淖忠苿?dòng)速度低于視覺感知閾值看起來很別扭。而用戶調(diào)速時(shí)界面上直接放一個(gè)TrackBar取值范圍1到10映射到像素每秒20到200比直接暴露Timer.Interval更友好。暫停功能有個(gè)細(xì)節(jié)容易被忽略暫停后Timer仍然在tick只是Tick函數(shù)里不做坐標(biāo)更新。這樣做的目的是恢復(fù)后仍然保持原有滾動(dòng)位置且不需要重新設(shè)置Timer狀態(tài)。如果通過Timer.Stop()來暫?；謴?fù)時(shí)還要處理一些狀態(tài)銜接問題沒必要。3.4 內(nèi)容來源從硬編碼到支持業(yè)務(wù)數(shù)據(jù)推送能用項(xiàng)目級(jí)的滾動(dòng)字幕程序內(nèi)容不應(yīng)該寫死在代碼里。我做的那一版支持三類內(nèi)容來源本地配置文件程序啟動(dòng)時(shí)讀取一個(gè)JSON或XML文件里面的數(shù)組按順序作為字幕內(nèi)容循環(huán)播放。數(shù)據(jù)庫(kù)輪詢定時(shí)查詢數(shù)據(jù)庫(kù)取最新數(shù)據(jù)追加到滾動(dòng)隊(duì)列。這種方式在門店促銷場(chǎng)景很實(shí)用。網(wǎng)絡(luò)Socket/HTTP接口推流上位機(jī)通過HTTP接口或TCP長(zhǎng)連接把最新消息推給字幕程序。工業(yè)大屏上多采用這種方式。這里需要理解一個(gè)概念滾動(dòng)字幕并不是一個(gè)孤立的小工具在很多系統(tǒng)架構(gòu)里它只是一個(gè)輕量的展示層真正的內(nèi)容管理和推送都在后臺(tái)服務(wù)里。如果你要在項(xiàng)目里集成它最好把它設(shè)計(jì)成一個(gè)接收外部數(shù)據(jù)的控件而不是自帶一堆UI按鈕。下面給出從業(yè)務(wù)系統(tǒng)中接收新消息并追加到隊(duì)列的做法public class MarqueeController { private Queuestring _messages new Queuestring(); private MarqueeControl _marquee; public void PushMessage(string msg) { lock (_messages) { _messages.Enqueue(msg); } } public void Next() { lock (_messages) { if (_messages.Count 0) { _marquee.DisplayText _messages.Dequeue(); } } } }滾動(dòng)隊(duì)列可以用在前面說到的重新設(shè)置內(nèi)容時(shí)從右側(cè)進(jìn)入的邏輯上即當(dāng)前文本完全滾出屏幕后由事件通知控制器切換到下一條消息。我實(shí)際做的時(shí)候給MarqueeControl加了一個(gè)TextScrolledOut事件這樣展示層和業(yè)務(wù)層就完全解耦了。4. 實(shí)戰(zhàn)中的踩坑記錄DPI縮放、字體測(cè)量與貼邊截?cái)嗄軡L動(dòng)只是基礎(chǔ)真正讓人頭疼的是各種環(huán)境下才能復(fù)現(xiàn)的詭異問題。這一節(jié)記錄我在實(shí)際開發(fā)中碰到的幾個(gè)坑以及最終怎么解決的。4.1 DPI縮放導(dǎo)致的自繪錯(cuò)位第一次把程序拿到一臺(tái)Windows縮放設(shè)置為150%的機(jī)器上運(yùn)行時(shí)文字明顯偏移位置不太對(duì)。查了一圈根源在于Windows的DPI虛擬化機(jī)制。默認(rèn)情況下Winform程序如果沒有聲明DPI感知系統(tǒng)會(huì)認(rèn)為它不感知DPI然后進(jìn)行DPI虛擬化縮放。這種縮放對(duì)普通控件基本夠用但對(duì)GDI自繪就有問題我們繪制時(shí)的坐標(biāo)是基于邏輯像素而實(shí)際屏幕物理像素不同導(dǎo)致繪制錯(cuò)位和發(fā)虛。解決方式是兩步走第一步在Program.cs的Main入口處聲明DPI感知[STAThread] static void Main() { Application.SetHighDpiMode(HighDpiMode.PerMonitorV2); Application.EnableVisualStyles(); Application.SetCompatibleTextRenderingDefault(false); Application.Run(new MainForm()); }第二步修改或添加app.manifest文件application xmlnsurn:schemas-microsoft-com:asm.v3 windowsSettings dpiAwareness xmlnshttp://schemas.microsoft.com/SMI/2016/WindowsSettingsPerMonitorV2/dpiAwareness /windowsSettings /application這樣設(shè)置后程序會(huì)跟隨顯示器縮放比例實(shí)時(shí)調(diào)整GDI繪制時(shí)坐標(biāo)就和像素對(duì)齊了。注意這兩步一定要配合只有manifest沒有SetHighDpiMode在某些.NET版本下仍然可能出問題。PerMonitorV2模式下跨屏拖動(dòng)窗口時(shí)會(huì)發(fā)生DPI變化窗體尺寸會(huì)重新調(diào)整自繪控件的重繪邏輯要能容忍尺寸變化。我是在MarqueeControl里重寫了OnResize在尺寸變化時(shí)重置滾動(dòng)起始位置并重新測(cè)量文本寬度。4.2 MeasureString在滾屏模式下不是總準(zhǔn)確這是第二個(gè)坑用Graphics.MeasureString測(cè)量字符串寬度后作為滾動(dòng)邊界判斷依據(jù)。這個(gè)寬度在某些系統(tǒng)字體渲染模式下和實(shí)際DrawString渲染的寬度有微小的差異導(dǎo)致的問題是滾動(dòng)重置時(shí)文字剛出屏幕一點(diǎn)就跳走或者已經(jīng)完全出了屏幕但還在繪制造成屏幕邊緣出現(xiàn)字尾殘留。更準(zhǔn)確的文本寬度測(cè)量方式是使用TextRenderer.MeasureText配合TextFormatFlags.NoPaddingprivate int MeasureTextWidth() { TextFormatFlags flags TextFormatFlags.NoPadding | TextFormatFlags.SingleLine; return TextRenderer.MeasureText(_displayText, this.Font, new Size(int.MaxValue, int.MaxValue), flags).Width; }TextRenderer是Winform里更底層的文本測(cè)量機(jī)制和DrawString所用的GDI文本渲染路徑不完全一致但和常見的Windows界面文本渲染更貼近。在滾動(dòng)字幕這種需要像素級(jí)判斷邊界的場(chǎng)景里TextRenderer通常比DrawString的測(cè)量結(jié)果更可靠。如果整體追求一致性另一個(gè)方案是全部棄用DrawString改用TextRenderer.DrawText來繪制文本。兩者渲染細(xì)節(jié)有差別前者更現(xiàn)代支持ClearType和亞像素平滑后者在文本布局上更接近原生控件。我自己更傾向保留DrawString來獲得更平滑的字體邊緣但測(cè)量統(tǒng)一用TextRenderer來兜底。4.3 滾動(dòng)重置的時(shí)機(jī)別讓文字在屏幕內(nèi)消失一個(gè)常見的滾動(dòng)字幕bug是這個(gè)邏輯寫錯(cuò)// 錯(cuò)誤寫法 if (_offsetX 0) { _offsetX this.ClientSize.Width; }這段代碼在文字剛好從屏幕左側(cè)消失一半時(shí)就重置了位置造成文字剛移動(dòng)一點(diǎn)就重新出現(xiàn)。正確的判斷條件應(yīng)該是文字完全移出屏幕即if (_offsetX _textWidth 0) { _offsetX this.ClientSize.Width; }這里的關(guān)鍵是要加上文本寬度。除了判斷條件重置后的位置也值得推敲。如果直接設(shè)成this.ClientSize.Width文字會(huì)立刻從右側(cè)出現(xiàn)視覺上有點(diǎn)突兀。更好的做法是讓文字有一段時(shí)間保持完全在屏幕外模擬一種從右邊走入的節(jié)奏感。_offsetX this.ClientSize.Width 20; // 額外留出20像素的空氣區(qū)域這個(gè)細(xì)節(jié)對(duì)觀感影響很大。要想想操場(chǎng)上走方隊(duì)入場(chǎng)肯定是從看不見的地方走進(jìn)來的而不是走到屏幕邊緣閃現(xiàn)出來。4.4 性能與幀率別把Timer的Interval壓得太狠初學(xué)者在追求絲滑效果時(shí)容易把Timer的Interval設(shè)成1毫秒甚至0結(jié)果發(fā)現(xiàn)程序占CPU高得離譜效果反而更卡。這里面涉及Windows消息循環(huán)的底層機(jī)制。Winform的Timer實(shí)際上基于Window消息隊(duì)列不是高精度定時(shí)器觸發(fā)頻率有物理上限。即便Interval設(shè)為1實(shí)際觸發(fā)間隔也不會(huì)低于10~15毫秒取決于系統(tǒng)時(shí)鐘分辨率。而快速觸發(fā)意味著更高的重繪頻率CPU占用率直線上升。我自己在180%縮放的高分屏上驗(yàn)證過Interval在15~20毫秒已經(jīng)有很好的連續(xù)感對(duì)應(yīng)的刷新率約為50~66幀/秒。再低就需要用多媒體定時(shí)器或者單獨(dú)線程做精確定時(shí)但在滾動(dòng)字幕這個(gè)場(chǎng)景里完全沒有必要。加上用增量時(shí)間換算速度即使某個(gè)Tick因?yàn)橄到y(tǒng)繁忙延時(shí)了文字移動(dòng)的距離也會(huì)自動(dòng)補(bǔ)償不會(huì)出現(xiàn)加速減速的突變感。這里再補(bǔ)一個(gè)使用感受在低配工控機(jī)上運(yùn)行時(shí)Tick信號(hào)的抖動(dòng)比開發(fā)機(jī)明顯許多?？吭隽繒r(shí)間補(bǔ)償后雖然文字的瞬時(shí)速度還會(huì)有細(xì)微波動(dòng)但總體勻速感是可靠的。前提是不要在Tick里做重活比如創(chuàng)建Graphics對(duì)象、申請(qǐng)大內(nèi)存、實(shí)時(shí)讀取文件這些都會(huì)加劇消息循環(huán)的延遲抖動(dòng)。最好把Tick里的邏輯精簡(jiǎn)到算一個(gè)值、改一個(gè)字段、Invalidate這三件事。5. 擴(kuò)展與實(shí)用玩法透明、置頂與聯(lián)動(dòng)數(shù)據(jù)源滾動(dòng)字幕能做的東西非常多。這一節(jié)講我實(shí)際在客戶現(xiàn)場(chǎng)交付過的幾個(gè)功能點(diǎn)以及設(shè)計(jì)時(shí)的取舍。5.1 半透明無邊框懸浮字幕條在信息發(fā)布場(chǎng)景里最常用的是半透明懸浮字幕條的樣式字幕浮在畫面底部背景半透不影響用戶看其他內(nèi)容。Winform實(shí)現(xiàn)這個(gè)特性非常方便直接設(shè)置Opacity屬性即可。this.Opacity 0.75;在透明背景下為了確保文字清晰可讀需要給文字加上陰影或描邊效果。自繪實(shí)現(xiàn)的一個(gè)簡(jiǎn)單技巧是先繪制一次文字偏移1個(gè)像素并設(shè)為黑色再在原來的位置繪制白色文字看起來就有立體感了。文字多的場(chǎng)景建議做成半透明黑色底條與主畫面形成分區(qū)可讀性更好。如果不希望背景有半透明效果而是做成一個(gè)帶有漸變底色的信息條也不用引入復(fù)雜UI庫(kù)在OnPaint里繪制一個(gè)LinearGradientBrush填充整個(gè)背景即可。這種形式在門店大屏上非常常見。5.2 多屏環(huán)境下指定顯示器輸出很多工業(yè)現(xiàn)場(chǎng)是多屏環(huán)境一邊是操作員工作站另一邊是面向車間的LED表達(dá)屏。字幕程序要能指定在哪塊屏幕上顯示。枚舉屏幕很簡(jiǎn)單foreach (var screen in Screen.AllScreens) { Console.WriteLine($屏幕: {screen.DeviceName}, 尺寸: {screen.Bounds}); }指定第2塊屏幕并全屏置頂?shù)哪Ｊ絭ar target Screen.AllScreens[1]; this.StartPosition FormStartPosition.Manual; this.Bounds target.Bounds; this.WindowState FormWindowState.Maximized;需要注意的是某些工控機(jī)的顯卡驅(qū)動(dòng)在擴(kuò)展屏幕上的刷新率不穩(wěn)定字幕長(zhǎng)時(shí)間運(yùn)行可能出現(xiàn)撕裂。如果遇到這類情況可以在MarqueeControl里把Timer.Interval稍微調(diào)大并在每幀繪制時(shí)都用Graphics.Clear來清理殘留再重新繪制全部?jī)?nèi)容確保畫面干凈。5.3 與業(yè)務(wù)系統(tǒng)聯(lián)動(dòng)從跑馬燈變成信息推送終端我做過最有價(jià)值的一次改造是把滾動(dòng)字幕程序從獨(dú)立小工具變成了車間信息系統(tǒng)的展示終端。通過UDP通信接收消息當(dāng)PLC故障、質(zhì)量告警等事件發(fā)生時(shí)后臺(tái)系統(tǒng)直接推一條消息到字幕上以特殊顏色滾動(dòng)播報(bào)。核心通信邏輯在后臺(tái)線程里private void ReceiveMessages() { UdpClient client new UdpClient(46000); IPEndPoint remoteEP new IPEndPoint(IPAddress.Any, 0); while (true) { byte[] data client.Receive(ref remoteEP); string message Encoding.UTF8.GetString(data); this.Invoke(() { _marquee.SetMessage(message, MessageUrgency.Normal); }); } }這里有一個(gè)必須處理的跨線程問題UDP接收線程不是UI線程不能直接操作控件必須用Invoke或BeginInvoke跳回UI線程更新控件。如果接收頻率高注意用BeginInvoke輕量合并邏輯避免UI線程被消息淹沒。當(dāng)告警信息來臨時(shí)可以改變字體顏色、加粗字體或者讓底色閃爍。這種字幕內(nèi)容動(dòng)態(tài)化樣式動(dòng)態(tài)化的能力正是自繪方案的優(yōu)勢(shì)因?yàn)槟憧梢噪S時(shí)根據(jù)業(yè)務(wù)狀態(tài)重新畫任何畫面而不受限于控件本身的樣式。5.4 我在實(shí)際使用中發(fā)現(xiàn)的一個(gè)實(shí)用細(xì)節(jié)最后分享一個(gè)小細(xì)節(jié)。很多滾動(dòng)字幕為了視覺效果字體會(huì)用得很花哨但真實(shí)場(chǎng)景里高可讀性遠(yuǎn)比美觀重要。我踩過的坑是一開始用了帶投影的標(biāo)題字體在車間遠(yuǎn)處看完全糊成一團(tuán)。后來?yè)Q成加粗的微軟雅黑或者直接上黑體間距拉開效果反而好很多。如果使用環(huán)境是有反光的LED屏深色背景白色文字適當(dāng)加大字號(hào)是最穩(wěn)妥的搭配。滾動(dòng)字幕這個(gè)程序的難點(diǎn)不在讓字動(dòng)起來而在讓字動(dòng)得穩(wěn)定、清晰、可控。把GDI自繪、雙緩沖、計(jì)時(shí)方式、字體測(cè)量這些東西吃透了以后再做LED控制軟件、動(dòng)態(tài)數(shù)據(jù)大屏、信息發(fā)布終端都會(huì)順很多。希望這篇文章能幫你少走一些彎路也歡迎在實(shí)際開發(fā)中把遇到的問題拿來一起討論。本文還有配套的精品資源點(diǎn)擊獲取