摘要:不過,在測試過程中卻發現,在移動端的瀏覽器上,繪制的內容展示十分模糊如下圖,經過分析之后發現是由于移動端高清屏幕引起的。這也是為什么高清屏更加細膩的原因。
由于一些移動端的兼容性原因,我們某個項目需要前端將pdf轉換成在移動端頁面可直接觀看的界面。為了方便解決,我們采用了pdf.js這個插件,該插件可以將pdf轉換成canvas繪制在頁面上。不過,在測試過程中卻發現,在移動端的瀏覽器上,繪制的內容展示十分模糊(如下圖),經過分析之后發現是由于移動端高清屏幕引起的。 在解決問題之后以文字方式記述原因和探究結果
在解釋問題之前,首先需要了解一些移動端顯示和cavans的小知識,方便后面探究。如果想直接看結果的話看可以拉到最后。
關于屏幕的一些基礎知識物理像素(DP)
物理像素也稱設備像素,我們常聽到的手機的分辨率及為物理像素,比如 iPhone 7的物理分辨率為750 * 1334。屏幕是由像素點組成的,也就是說屏幕的水平方向有750的像素點,垂直方向上有1334個像素點
設備獨立像素(DIP)
也稱為邏輯像素,比如Iphone4和Iphone3GS的尺寸都是3.5寸,iphone4的物理分辨率是640 980,而3gs只有320 480,假如我們按照真實布局取繪制一個320px寬度的圖像時,在iphone4上只有一半有內容,剩下的一半則是一片空白,為了避免這種問題,我們引入了邏輯像素,將兩種手機的邏輯像素都設置為320px,方便繪制
設備像素比(DPR)
上面的設備獨立像素說到底是為了方便計算,我們統一了設備的邏輯像素,但是每個邏輯像素所代表的物理像素卻不是確定的,為了確定在未縮放情況下,物理像素和邏輯像素的關系,我們引入了設備像素比(DPR)這個概念
設備像素比 = 設備像素 / 邏輯像素
DPR = DP / DIP
上面說了很多理論,下面附個圖解釋一下
從上面的圖可以看出,在同樣大小的邏輯像素下,高清屏所具有的物理像素更多。普通屏幕下,1個邏輯像素對應1個物理像素,而在dpr = 2的高清屏幕下,1個邏輯像素由4個物理像素組成。這也是為什么高清屏更加細膩的原因。
關于canvas的一些基礎知識canvas繪制的是位圖
這是一個所有了解過canvas的人都應該知道的知識點,也是接下來我們將要分析問題的核心。
關于位圖的解釋我們放在后面,現在我們只要知道canvas繪制的圖像是位圖。
canvas的width和height屬性
canvas的width和height屬性是初學者非常容易搞錯的內容。這兩個屬性經常會與css中的width和height屬性混淆。
比如我們有如下代碼(1):
style中的width和height分別代表canvas這個元素在界面上所占據的寬高,即樣式上的寬高
attribute中的width和height則代表canvas實際像素的寬高
如果還無法理解的話,可以想象成以下的代碼(2):
canvas默認的width和height是300 * 150,對其設置了css之后,canvas會根據設置css寬高進行縮放(注意不是裁剪),這一點和img標簽一樣
上述代碼(1)其實還可以再換一種更通俗的解釋方式,就是1個邏輯像素實際上由2個canvas像素填充。
上面是對所需基礎知識的一些簡介,下面開始正式進行探究。
首先我們提到使用canvas繪制圖像的是位圖,而我們平常用的jpg,png也是位圖。那么什么是位圖?
位圖又叫像素圖或柵格圖,它是通過記錄圖像中每一個點的顏色、深度等信息來存儲和顯示圖像。具象一點講,可以將位圖想象成一個巨大的拼圖,這個拼圖有無數的拼塊,每個拼塊代表了一個純色的像素點。理論上,1個位圖像素對應著1個物理像素。但假如說你使用了高清屏,比如蘋果的retina屏去查看一幅圖畫,又會是什么樣子呢?
假設我們有如下代碼,該代碼將展示在iphone4的retina屏上:
iphone4本身的物理像素為640 980,而設備獨立像素為320 480,這代表著1個css像素實際由4個物理像素構成,canvas的像素為320 150,其css像素為320 150,則代表1個css像素將會由1個canvas元素構成,這樣進行換算,在retina屏幕下,1個canvas像素(或者說是1個位圖像素)將會填充4個物理像素,由于單個位圖像素不可以再進一步分割,所以只能就近取色,從而導致圖片模糊。
如果還有疑惑的話,以下的圖片可以說明位圖在retina屏幕下是如何填充的:
上圖中左側的是在普通屏幕下的顯示規則,可以看出有4個位圖像素點,而右側的高清屏幕下則有16個像素點。由于像素點不可切割的原因,顏色產生了改變。
但是還有一點沒有解釋清楚,就是為什么圖片會就近取色而不是直接取原值,這也是導致模糊的幕后黑手。
幕后黑手---平滑處理技術下面是我的某位大佬同學幫我解釋的,剛才我們說了每個位圖元素實際上一個純色的像素點。現在假設我們需要在一個css大小為4px * 4px,dpr為1普通屏幕上繪制一個數字“0”,那么我們繪制的樣子應該如下圖,其中1代表黑色像素點,0代表白色像素點。
可以看出在dpr比較小的情況下,我們的“0”這個圖案還比較明顯,現在假如我們css大小不變,但是改成在retina屏幕下繪制圖像,效果又會變成什么樣呢?
我們已知在retina屏幕下,一個css像素代表4個物理像素,假如我們不做任何處理,直接按照上面矩陣排列,將矩陣擴大的話,會發現在retina屏幕下,我們的圖案鋸齒感非常明顯,圖像明顯缺乏了一絲順化。
假如我們對圖像稍作改變,改成下圖這樣
圖像感覺瞬間柔和了,但是原本應該4個0充斥的地方變成了3個1加上1個0。這其實就是所謂的圖像平滑處理,為了解決鋸齒感覺,將原本的顏色改變,在充斥著較多顏色的圖片上,為了更自然,圖片的連接處變成了近似的顏色,這也解釋了為什么上面填充顏色的時候不是使用本色而是使用近似色。
原因總結通過了上述的解釋,現在我們來總結以下結論,在移動端盛行,高清屏基本上已經普及的現在,1px的css像素實際上代表了4個甚至更多的物理像素。但是由于我們的代碼問題,我們1px的css像素和1個canvas像素畫上了等號,也就導致了1個canvas像素實際需要填充4個甚至更多物理像素,為了保證圖像平滑處理,在填充剩余的物理像素時采用了原先顏色的近似值,導致了圖像的模糊。
解決思路了解了問題出現的原因,解決問題就很容易,解決該問題最重要的一點是讓1個canvas像素和一個物理像素掛等號
高版本的瀏覽器的window對象下都掛著一個devicePixelRatio屬性,該屬性就是上面所說的dpr,
在canvas元素css寬高確定的情況下,我們可以這么做
let canvas = document.getElementById("canvas"); let ctx = canvas.getContext("2d"); let dpr = window.devicePixelRatio; // 假設dpr為2 // 獲取css的寬高 let { width: cssWidth, height: cssHeight } = canvas.getBoundingClientRect(); // 根據dpr,擴大canvas畫布的像素,使1個canvas像素和1個物理像素相等 canvas.width = dpr * cssWidth; canvas.height = dpr * cssHeight; // 由于畫布擴大,canvas的坐標系也跟著擴大,如果按照原先的坐標系繪圖內容會縮小 // 所以需要將繪制比例放大 ctx.scale(dpr,dpr);經驗總結
很多時候,我們發現了問題,不能只集中于問題的解決,而是應該深入去了解問題發生的原因,這樣才能更好的在這行走下去。
作者:carbrokers
本文首發微信公眾號:qianduanshe 歡迎掃描二維碼關注公眾號,每天都給你推送新鮮的前端技術文章文章版權歸作者所有,未經允許請勿轉載,若此文章存在違規行為,您可以聯系管理員刪除。
轉載請注明本文地址:http://specialneedsforspecialkids.com/yun/103927.html
摘要:不過,在測試過程中卻發現,在移動端的瀏覽器上,繪制的內容展示十分模糊如下圖,經過分析之后發現是由于移動端高清屏幕引起的。這也是為什么高清屏更加細膩的原因。 由于一些移動端的兼容性原因,我們某個項目需要前端將pdf轉換成在移動端頁面可直接觀看的界面。為了方便解決,我們采用了pdf.js這個插件,該插件可以將pdf轉換成canvas繪制在頁面上。不過,在測試過程中卻發現,在移動端的瀏覽器上...
摘要:前陣子七夕的時候搞了一個活動頁,需要做一個本地圖片的裁剪上傳功能,用于生成一些特定的表白圖片。還有就是是配合實現的,因為我是直接在項目中復制過來改改的,就懶得轉換了圖片讀取要裁剪首先肯定就是讀取圖片文件。 前陣子七夕的時候搞了一個h5活動頁,需要做一個本地圖片的裁剪上傳功能,用于生成一些特定的表白圖片。主要是用到了H5的FileApi 和 Canvas。個人感覺圖片裁剪功能還是很實用的...
摘要:常見優化方案模糊問題旋轉效果離屏自定義圖片尺寸實踐離屏旋轉效果實踐旋轉的雪花更新關于模糊問題前幾天研究的時候剛好趕上作者發布新版本,發現新版本截屏出來的效果比我對舊版本處理后畫布尺寸都設為倍的效果更好。 canvas常見優化方案——模糊問題、旋轉效果、離屏、自定義圖片尺寸 實踐demo——canvas離屏、旋轉效果實踐——旋轉的雪花 2017-12-18 16:27:35更新關于模糊問...
閱讀 3766·2021-11-11 11:02
閱讀 3495·2021-10-11 10:57
閱讀 3608·2021-09-22 16:00
閱讀 1843·2021-09-02 15:15
閱讀 1322·2019-08-30 15:56
閱讀 1005·2019-08-30 15:54
閱讀 2731·2019-08-30 12:43
閱讀 3539·2019-08-29 16:06