অ্যানিমেশন পরিমাপ, অ্যানিমেশন ফ্রেম সম্পর্কে কীভাবে ভাবতে হয় এবং সামগ্রিক পৃষ্ঠার মসৃণতা সম্পর্কে জানুন।
আপনি সম্ভবত স্ক্রলিং বা অ্যানিমেশনের সময় "তোতলা" বা "ফ্রিজ" পৃষ্ঠাগুলি অনুভব করেছেন৷ আমরা বলতে চাই যে এই অভিজ্ঞতাগুলি মসৃণ নয়। এই ধরনের সমস্যাগুলির সমাধান করার জন্য, Chrome টিম অ্যানিমেশন সনাক্তকরণের জন্য আমাদের ল্যাব টুলিং-এ আরও সমর্থন যোগ করার পাশাপাশি Chromium-এর মধ্যে রেন্ডারিং পাইপলাইন ডায়াগনস্টিকগুলিতে স্থির উন্নতি করার জন্য কাজ করছে৷
আমরা কিছু সাম্প্রতিক অগ্রগতি শেয়ার করতে চাই, কংক্রিট টুলিং নির্দেশিকা অফার করতে চাই এবং ভবিষ্যতের অ্যানিমেশন স্মুথনেস মেট্রিক্সের জন্য ধারনা নিয়ে আলোচনা করতে চাই। বরাবরের মতো, আমরা আপনার প্রতিক্রিয়া শুনতে চাই।
এই পোস্টটি তিনটি প্রধান বিষয় কভার করবে:
- অ্যানিমেশন এবং অ্যানিমেশন ফ্রেম একটি দ্রুত চেহারা.
- সামগ্রিক অ্যানিমেশন মসৃণতা পরিমাপ আমাদের বর্তমান চিন্তা.
- আজ ল্যাব টুলিং-এ আপনার জন্য কিছু ব্যবহারিক পরামর্শ।
অ্যানিমেশন কি?
অ্যানিমেশন কন্টেন্ট জীবন আনতে! বিষয়বস্তু সরানোর মাধ্যমে, বিশেষ করে ব্যবহারকারীর ইন্টারঅ্যাকশনের প্রতিক্রিয়ায়, অ্যানিমেশনগুলি একটি অভিজ্ঞতাকে আরও স্বাভাবিক, বোধগম্য এবং মজাদার করে তুলতে পারে।
কিন্তু খারাপভাবে বাস্তবায়িত অ্যানিমেশন, বা শুধুমাত্র অনেক অ্যানিমেশন যোগ করা, অভিজ্ঞতার অবনতি ঘটাতে পারে এবং এটিকে মোটেও মজাদার করে তোলে না। আমরা সবাই সম্ভবত একটি ইন্টারফেসের সাথে ইন্টারফেস করেছি যা কেবলমাত্র অনেকগুলি "সহায়ক" রূপান্তর প্রভাব যুক্ত করেছে, যেগুলি খারাপভাবে কাজ করলে অভিজ্ঞতার পক্ষে প্রতিকূল হয়ে ওঠে। তাই কিছু ব্যবহারকারী আসলে হ্রাস গতি পছন্দ করতে পারে, একটি ব্যবহারকারীর পছন্দ যা আপনার সম্মান করা উচিত।
অ্যানিমেশন কিভাবে কাজ করে?
দ্রুত রিক্যাপ হিসাবে, রেন্ডারিং পাইপলাইনে কয়েকটি, অনুক্রমিক ধাপ রয়েছে:
- শৈলী: উপাদানগুলিতে প্রযোজ্য শৈলীগুলি গণনা করুন।
- লেআউট: প্রতিটি উপাদানের জন্য জ্যামিতি এবং অবস্থান তৈরি করুন।
- পেইন্ট: স্তরগুলিতে প্রতিটি উপাদানের জন্য পিক্সেল পূরণ করুন।
- কম্পোজিট: স্ক্রিনে স্তরগুলি আঁকুন।
যদিও অ্যানিমেশনগুলিকে সংজ্ঞায়িত করার অনেক উপায় আছে, সেগুলি মৌলিকভাবে নিম্নলিখিতগুলির মধ্যে একটির মাধ্যমে কাজ করে:
- লেআউট বৈশিষ্ট্য সমন্বয়.
- পেইন্ট বৈশিষ্ট্য সমন্বয়.
- যৌগিক বৈশিষ্ট্য সামঞ্জস্য করা।
যেহেতু এই পর্যায়গুলি অনুক্রমিক, তাই অ্যানিমেশনগুলিকে বৈশিষ্ট্যগুলির পরিপ্রেক্ষিতে সংজ্ঞায়িত করা গুরুত্বপূর্ণ যা পাইপলাইনের নীচে রয়েছে৷ প্রক্রিয়ায় যত তাড়াতাড়ি আপডেট হবে, তত বেশি খরচ হবে এবং এটি মসৃণ হওয়ার সম্ভাবনা কম। (আরো বিস্তারিত জানার জন্য রেন্ডারিং কর্মক্ষমতা দেখুন।)
যদিও লেআউট বৈশিষ্ট্যগুলি অ্যানিমেট করা সুবিধাজনক হতে পারে, তবে এটি করার জন্য খরচ আছে, এমনকি যদি সেই খরচগুলি অবিলম্বে স্পষ্ট না হয়। অ্যানিমেশনগুলি যেখানেই সম্ভব যৌগিক সম্পত্তি পরিবর্তনের পরিপ্রেক্ষিতে সংজ্ঞায়িত করা উচিত।
ঘোষণামূলক CSS অ্যানিমেশন বা ওয়েব অ্যানিমেশন ব্যবহার করে সংজ্ঞায়িত করা, এবং আপনি যৌগিক বৈশিষ্ট্যগুলিকে অ্যানিমেট করতে পারেন তা নিশ্চিত করা, মসৃণ এবং দক্ষ অ্যানিমেশনগুলি নিশ্চিত করার জন্য একটি দুর্দান্ত প্রথম পদক্ষেপ। কিন্তু তবুও, এটি একাই মসৃণতার গ্যারান্টি দেয় না কারণ এমনকি দক্ষ ওয়েব অ্যানিমেশনের কর্মক্ষমতা সীমা থাকে। তাই এটা পরিমাপ করা সবসময় গুরুত্বপূর্ণ!
অ্যানিমেশন ফ্রেম কি?
একটি পৃষ্ঠার ভিজ্যুয়াল উপস্থাপনার আপডেটগুলি উপস্থিত হতে সময় নেয়। একটি ভিজ্যুয়াল পরিবর্তন একটি নতুন অ্যানিমেশন ফ্রেমের দিকে নিয়ে যাবে, যা অবশেষে ব্যবহারকারীর ডিসপ্লেতে রেন্ডার করা হয়।
কিছু ব্যবধানে আপডেট প্রদর্শন করে, তাই ভিজ্যুয়াল আপডেটগুলি ব্যাচ করা হয়। অনেক ডিসপ্লে একটি নির্দিষ্ট সময়ের ব্যবধানে আপডেট করে, যেমন সেকেন্ডে 60 বার (অর্থাৎ 60 Hz)। আরও কিছু আধুনিক ডিসপ্লে উচ্চতর রিফ্রেশ হার অফার করতে পারে (90-120 Hz সাধারণ হয়ে উঠছে)। প্রায়শই এই ডিসপ্লেগুলি প্রয়োজন অনুযায়ী রিফ্রেশ রেটগুলির মধ্যে সক্রিয়ভাবে মানিয়ে নিতে পারে, বা এমনকি সম্পূর্ণ পরিবর্তনশীল ফ্রেম রেট অফার করতে পারে।
যেকোন অ্যাপ্লিকেশনের লক্ষ্য, যেমন একটি গেম বা একটি ব্রাউজার, এই সমস্ত ব্যাচ করা ভিজ্যুয়াল আপডেটগুলি প্রক্রিয়া করা এবং প্রতিবার সময়সীমার মধ্যে একটি দৃশ্যত সম্পূর্ণ অ্যানিমেশন ফ্রেম তৈরি করা। নোট করুন যে এই লক্ষ্যটি অন্যান্য গুরুত্বপূর্ণ ব্রাউজার কাজগুলির থেকে সম্পূর্ণ আলাদা যেমন নেটওয়ার্ক থেকে সামগ্রী দ্রুত লোড করা বা JavaScript কার্যগুলি দক্ষতার সাথে সম্পাদন করা।
কিছু সময়ে, ডিসপ্লে দ্বারা নির্ধারিত সময়সীমার মধ্যে সমস্ত ভিজ্যুয়াল আপডেটগুলি সম্পূর্ণ করা খুব কঠিন হয়ে উঠতে পারে। যখন এটি ঘটে, ব্রাউজার একটি ফ্রেম ড্রপ করে । আপনার স্ক্রিন কালো হয় না, এটি কেবল নিজেকে পুনরাবৃত্তি করে। আপনি একটু বেশি সময়ের জন্য একই ভিজ্যুয়াল আপডেট দেখতে পাচ্ছেন—একই অ্যানিমেশন ফ্রেম যা আগের ফ্রেমের সুযোগে উপস্থাপিত হয়েছিল।
এটা আসলে প্রায়ই ঘটে! এটি অগত্যা এমনকি উপলব্ধিযোগ্য নয়, বিশেষত স্ট্যাটিক বা নথির মতো বিষয়বস্তুর জন্য, যা বিশেষ করে ওয়েব প্ল্যাটফর্মে সাধারণ। ড্রপ করা ফ্রেমগুলি তখনই স্পষ্ট হয়ে ওঠে যখন গুরুত্বপূর্ণ ভিজ্যুয়াল আপডেট থাকে, যেমন অ্যানিমেশন, যার জন্য আমাদের মসৃণ গতি দেখানোর জন্য অ্যানিমেশন আপডেটগুলির একটি স্থির স্ট্রিম প্রয়োজন।
অ্যানিমেশন ফ্রেমগুলিকে কী প্রভাবিত করে?
ওয়েব ডেভেলপাররা দ্রুত এবং দক্ষতার সাথে ভিজ্যুয়াল আপডেট রেন্ডার এবং উপস্থাপন করার জন্য ব্রাউজারের ক্ষমতাকে ব্যাপকভাবে প্রভাবিত করতে পারে!
কিছু উদাহরণ:
- টার্গেট ডিভাইসে দ্রুত ডিকোড করার জন্য খুব বড় বা সম্পদ-নিবিড় বিষয়বস্তু ব্যবহার করা।
- অত্যধিক GPU মেমরি প্রয়োজন অনেক স্তর ব্যবহার .
- অত্যধিক জটিল CSS শৈলী বা ওয়েব অ্যানিমেশন সংজ্ঞায়িত করা।
- নকশা বিরোধী প্যাটার্ন ব্যবহার করে যা দ্রুত রেন্ডারিং অপ্টিমাইজেশান অক্ষম করে।
- প্রধান থ্রেডে অত্যধিক JS কাজ করে, যা দীর্ঘ টাস্কের দিকে পরিচালিত করে যা ভিজ্যুয়াল আপডেটগুলিকে ব্লক করে।
কিন্তু আপনি কিভাবে জানতে পারবেন যখন একটি অ্যানিমেশন ফ্রেম তার সময়সীমা মিস করেছে এবং একটি ড্রপ ফ্রেম সৃষ্টি করেছে?
একটি সম্ভাব্য পদ্ধতি হল requestAnimationFrame() পোলিং ব্যবহার করা, তবে এর বেশ কিছু খারাপ দিক রয়েছে। requestAnimationFrame() , বা "rAF", ব্রাউজারকে বলে যে আপনি একটি অ্যানিমেশন করতে চান এবং রেন্ডারিং পাইপলাইনের পরবর্তী পেইন্ট পর্যায়ের আগে এটি করার সুযোগ চান৷ যদি আপনার কলব্যাক ফাংশনটি আপনার প্রত্যাশার সময়ে কল না করা হয়, তার মানে একটি পেইন্ট কার্যকর করা হয়নি এবং এক বা একাধিক ফ্রেম এড়িয়ে গেছে। কত ঘন ঘন আরএএফ কল করা হয়েছে তা গণনা এবং গণনা করে, আপনি এক ধরণের "ফ্রেম পার সেকেন্ড" (এফপিএস) মেট্রিক গণনা করতে পারেন।
let frameTimes = [];
function pollFramesPerSecond(now) {
frameTimes = [...frameTimes.filter(t => t > now - 1000), now];
requestAnimationFrame(pollFramesPerSecond);
console.log('Frames per second:', frameTimes.length);
}
requestAnimationFrame(pollFramesPerSecond);
requestAnimationFrame() পোলিং ব্যবহার করা বিভিন্ন কারণে একটি ভাল ধারণা নয়:
- প্রতিটি স্ক্রিপ্টের নিজস্ব পোলিং লুপ সেট আপ করতে হবে।
- এটি সমালোচনামূলক পথ অবরুদ্ধ করতে পারে।
- এমনকি যদি আরএএফ পোলিং দ্রুত হয়, তবে এটি
requestIdleCallback()দীর্ঘ নিষ্ক্রিয় ব্লকগুলিকে ক্রমাগত ব্যবহার করার সময় নির্ধারণ করতে সক্ষম হতে বাধা দিতে পারে (একটি ফ্রেমের বেশি ব্লক)। - একইভাবে, দীর্ঘ নিষ্ক্রিয় ব্লকের অভাব ব্রাউজারকে অন্যান্য দীর্ঘ-চলমান কাজগুলি (যেমন দীর্ঘতর আবর্জনা সংগ্রহ এবং অন্যান্য পটভূমি বা অনুমানমূলক কাজ) নির্ধারণ করতে বাধা দেয়।
- যদি পোলিং চালু এবং বন্ধ করা হয়, তাহলে আপনি ফ্রেম বাজেট অতিক্রম করার ক্ষেত্রে মিস করবেন।
- যে ক্ষেত্রে ব্রাউজার পরিবর্তনশীল আপডেট ফ্রিকোয়েন্সি ব্যবহার করছে (উদাহরণস্বরূপ, পাওয়ার বা দৃশ্যমানতার কারণে) পোলিং মিথ্যা-ইতিবাচক রিপোর্ট করবে।
- এবং সবচেয়ে গুরুত্বপূর্ণ, এটি আসলে সব ধরনের অ্যানিমেশন আপডেট ক্যাপচার করে না!
মূল থ্রেডে খুব বেশি কাজ অ্যানিমেশন ফ্রেম দেখার ক্ষমতাকে প্রভাবিত করতে পারে। মূল থ্রেডে (যেমন লেআউট) খুব বেশি কাজ হয়ে গেলে কীভাবে একটি rAF-চালিত অ্যানিমেশন, ড্রপ ফ্রেম এবং কম rAF কলব্যাক এবং নিম্ন FPS-এর দিকে পরিচালিত করবে তা দেখতে জ্যাঙ্ক স্যাম্পলটি দেখুন।
যখন মূল থ্রেডটি আটকে যায়, তখন ভিজ্যুয়াল আপডেটগুলি তোতলাতে শুরু করে। যে জ্যাঙ্ক!
অনেক পরিমাপ সরঞ্জাম একটি সময়মত পদ্ধতিতে মূল থ্রেডের ফলন এবং অ্যানিমেশন ফ্রেমগুলিকে মসৃণভাবে চালানোর ক্ষমতার উপর ব্যাপকভাবে ফোকাস করেছে। কিন্তু এই পুরো গল্প নয়! নিম্নলিখিত উদাহরণ বিবেচনা করুন:
উপরের ভিডিওটি এমন একটি পৃষ্ঠা দেখায় যা পর্যায়ক্রমে মূল থ্রেডে দীর্ঘ কাজগুলিকে ইনজেক্ট করে। এই দীর্ঘ কাজগুলি নির্দিষ্ট ধরণের ভিজ্যুয়াল আপডেটগুলি প্রদান করার জন্য পৃষ্ঠাটির ক্ষমতা সম্পূর্ণরূপে নষ্ট করে দেয় এবং আপনি উপরের-বাম কোণে একটি অনুরূপ ড্রপ requestAnimationFrame() 0-এ রিপোর্ট করা FPS দেখতে পারেন৷
এবং তবুও, এই দীর্ঘ কাজগুলি সত্ত্বেও, পৃষ্ঠাটি মসৃণভাবে স্ক্রোল করতে থাকে। এর কারণ হল আধুনিক ব্রাউজারে, স্ক্রোলিং প্রায়শই থ্রেডেড হয় , সম্পূর্ণরূপে কম্পোজিটর দ্বারা চালিত হয়।
এটি একটি উদাহরণ যা একই সাথে প্রধান থ্রেডে অনেকগুলি ড্রপ করা ফ্রেম ধারণ করে, তবুও কম্পোজিটর থ্রেডে স্ক্রলিং করার অনেকগুলি সফলভাবে বিতরণ করা ফ্রেম রয়েছে৷ একবার দীর্ঘ টাস্ক সম্পূর্ণ হলে, মূল থ্রেড পেইন্ট আপডেটে যাইহোক অফার করার জন্য কোন চাক্ষুষ পরিবর্তন নেই। rAF পোলিং 0 এ ফ্রেম ড্রপ করার পরামর্শ দিয়েছে, কিন্তু দৃশ্যত , একজন ব্যবহারকারী একটি পার্থক্য লক্ষ্য করতে সক্ষম হবেন না!
অ্যানিমেশন ফ্রেমের জন্য, গল্পটি এত সহজ নয়।
অ্যানিমেশন ফ্রেম: আপডেট যে ব্যাপার
উপরের উদাহরণটি দেখায় যে শুধুমাত্র requestAnimationFrame() চেয়ে গল্পে আরও অনেক কিছু রয়েছে।
তাহলে অ্যানিমেশন আপডেট এবং অ্যানিমেশন ফ্রেমগুলি কখন গুরুত্বপূর্ণ? এখানে কিছু মানদণ্ড রয়েছে যা আমরা চিন্তা করছি এবং প্রতিক্রিয়া পেতে চাই:
- প্রধান এবং কম্পোজিটর থ্রেড আপডেট
- পেইন্ট আপডেট অনুপস্থিত
- অ্যানিমেশন সনাক্ত করা হচ্ছে
- গুণমান বনাম পরিমাণ
প্রধান এবং কম্পোজিটর থ্রেড আপডেট
অ্যানিমেশন ফ্রেম আপডেট বুলিয়ান নয়। এটি এমন নয় যে ফ্রেমগুলি শুধুমাত্র সম্পূর্ণরূপে বাদ দেওয়া বা সম্পূর্ণরূপে উপস্থাপিত হতে পারে। একটি অ্যানিমেশন ফ্রেম আংশিকভাবে উপস্থাপন করার অনেক কারণ রয়েছে। অন্য কথায়, এটিতে একই সাথে কিছু পুরানো বিষয়বস্তু থাকতে পারে এবং কিছু নতুন ভিজ্যুয়াল আপডেটও থাকতে পারে যা উপস্থাপিত হয়।
এর সবচেয়ে সাধারণ উদাহরণ হল যখন ব্রাউজার ফ্রেমের সময়সীমার মধ্যে একটি নতুন প্রধান থ্রেড আপডেট তৈরি করতে অক্ষম হয় কিন্তু একটি নতুন কম্পোজিটর থ্রেড আপডেট থাকে (যেমন আগের থেকে থ্রেডেড স্ক্রোলিং উদাহরণ)।
যৌগিক বৈশিষ্ট্যগুলিকে অ্যানিমেট করার জন্য ঘোষণামূলক অ্যানিমেশন ব্যবহার করার একটি গুরুত্বপূর্ণ কারণ হল যে এটি করা একটি অ্যানিমেশনকে সম্পূর্ণরূপে কম্পোজিটর থ্রেড দ্বারা চালিত করতে সক্ষম করে এমনকি যখন মূল থ্রেডটি ব্যস্ত থাকে। এই ধরণের অ্যানিমেশনগুলি দক্ষতার সাথে এবং সমান্তরালভাবে ভিজ্যুয়াল আপডেটগুলি তৈরি করা চালিয়ে যেতে পারে।
অন্যদিকে, এমন কিছু ঘটনা থাকতে পারে যেখানে একটি প্রধান থ্রেড আপডেট অবশেষে উপস্থাপনার জন্য উপলব্ধ হয়, কিন্তু শুধুমাত্র বেশ কয়েকটি ফ্রেমের সময়সীমা মিস করার পরে। এখানে ব্রাউজারে কিছু নতুন আপডেট থাকবে, তবে এটি একেবারে সর্বশেষ নাও হতে পারে।
বিস্তৃতভাবে বলতে গেলে, আমরা এমন ফ্রেমগুলিকে আংশিক ফ্রেম হিসাবে বিবেচনা করি যেখানে কিছু নতুন ভিজ্যুয়াল আপডেট রয়েছে, সমস্ত নতুন ভিজ্যুয়াল আপডেট ছাড়াই। আংশিক ফ্রেম মোটামুটি সাধারণ. আদর্শভাবে, আংশিক আপডেট অন্তত অ্যানিমেশনের মতো সবচেয়ে গুরুত্বপূর্ণ ভিজ্যুয়াল আপডেটগুলিকে অন্তর্ভুক্ত করবে, তবে এটি শুধুমাত্র তখনই ঘটতে পারে যখন অ্যানিমেশনগুলি কম্পোজিটর থ্রেড দ্বারা চালিত হয়।
পেইন্ট আপডেট অনুপস্থিত
আরেকটি প্রকারের আংশিক আপডেট হল যখন ইমেজের মতো মিডিয়াগুলি ফ্রেম প্রেজেন্টেশনের জন্য সময়মতো ডিকোডিং এবং রাস্টারাইজিং শেষ করে না।
অথবা, এমনকি যদি একটি পৃষ্ঠা পুরোপুরি স্থির থাকে, ব্রাউজারগুলি এখনও দ্রুত স্ক্রোলিং করার সময় ভিজ্যুয়াল আপডেটগুলি রেন্ডার করার পিছনে পড়ে যেতে পারে। এর কারণ হল দৃশ্যমান ভিউপোর্টের বাইরে সামগ্রীর পিক্সেল উপস্থাপনাগুলি GPU মেমরি সংরক্ষণ করতে বাতিল করা হতে পারে৷ পিক্সেল রেন্ডার করতে সময় লাগে এবং আঙুল ছুঁড়ে ফেলার মতো বড় স্ক্রলের পরে সবকিছু রেন্ডার করতে একক ফ্রেমের চেয়ে বেশি সময় লাগতে পারে। এটি সাধারণত চেকারবোর্ডিং নামে পরিচিত।
প্রতিটি ফ্রেম রেন্ডারিং সুযোগের সাথে, স্ক্রিনে আসলে কতটা সর্বশেষ ভিজ্যুয়াল আপডেট এসেছে তা ট্র্যাক করা সম্ভব। অনেক ফ্রেমের (বা সময়) উপর এটি করার ক্ষমতা পরিমাপ করা ব্যাপকভাবে ফ্রেম থ্রুপুট হিসাবে পরিচিত।
যদি GPU সত্যিই আটকে থাকে, তাহলে ব্রাউজার (বা প্ল্যাটফর্ম) এমনকি ভিজ্যুয়াল আপডেটের চেষ্টা করার হারকে থ্রোটল করতে শুরু করতে পারে এবং এর ফলে কার্যকর ফ্রেম রেট কমে যায়। যদিও প্রযুক্তিগতভাবে এটি ড্রপ করা ফ্রেম আপডেটের সংখ্যা কমাতে পারে, দৃশ্যত এটি এখনও একটি নিম্ন ফ্রেম থ্রুপুট হিসাবে প্রদর্শিত হবে।
তবুও, সব ধরনের কম ফ্রেম থ্রুপুট খারাপ নয়। যদি পৃষ্ঠাটি বেশিরভাগ নিষ্ক্রিয় থাকে এবং কোনও সক্রিয় অ্যানিমেশন না থাকে, তাহলে কম ফ্রেম রেট একটি উচ্চ ফ্রেম রেট (এবং, এটি ব্যাটারি বাঁচাতে পারে!) এর মতোই দৃষ্টিকটু।
তাই কখন ফ্রেম থ্রুপুট ব্যাপার?
অ্যানিমেশন সনাক্ত করা হচ্ছে
বিশেষ করে গুরুত্বপূর্ণ অ্যানিমেশন সহ পিরিয়ডের সময় উচ্চ ফ্রেম থ্রুপুট গুরুত্বপূর্ণ। বিভিন্ন অ্যানিমেশনের ধরন একটি নির্দিষ্ট থ্রেড (প্রধান, কম্পোজিটর বা একজন কর্মী) থেকে ভিজ্যুয়াল আপডেটের উপর নির্ভর করবে, তাই এর ভিজ্যুয়াল আপডেট সেই থ্রেডের উপর নির্ভর করে যা নির্দিষ্ট সময়সীমার মধ্যে আপডেট প্রদান করে। আমরা বলি যে একটি প্রদত্ত থ্রেড মসৃণতা প্রভাবিত করে যখনই একটি সক্রিয় অ্যানিমেশন থাকে যা সেই থ্রেড আপডেটের উপর নির্ভর করে।
কিছু ধরণের অ্যানিমেশন অন্যদের তুলনায় সংজ্ঞায়িত করা এবং সনাক্ত করা সহজ। ঘোষণামূলক অ্যানিমেশন, বা ব্যবহারকারী-ইনপুট-চালিত অ্যানিমেশনগুলি, জাভাস্ক্রিপ্ট-চালিত অ্যানিমেশনগুলিকে অ্যানিমেটেবল শৈলী বৈশিষ্ট্যগুলিতে পর্যায়ক্রমিক আপডেট হিসাবে প্রয়োগ করা থেকে সংজ্ঞায়িত করা আরও পরিষ্কার।
এমনকি requestAnimationFrame() দিয়েও আপনি সবসময় অনুমান করতে পারবেন না যে প্রতিটি RAF কল অগত্যা একটি ভিজ্যুয়াল আপডেট বা অ্যানিমেশন তৈরি করছে। উদাহরণস্বরূপ, শুধুমাত্র ফ্রেম রেট ট্র্যাক করার জন্য আরএএফ পোলিং ব্যবহার করা (উপরে দেখানো হয়েছে) মসৃণতা পরিমাপকে প্রভাবিত করবে না যেহেতু কোনও ভিজ্যুয়াল আপডেট নেই৷
গুণমান বনাম পরিমাণ
অবশেষে, অ্যানিমেশন এবং অ্যানিমেশন ফ্রেম আপডেটগুলি সনাক্ত করা এখনও গল্পের শুধুমাত্র অংশ কারণ এটি শুধুমাত্র অ্যানিমেশন আপডেটের পরিমাণ ক্যাপচার করে, গুণমান নয়।
উদাহরণস্বরূপ, আপনি একটি ভিডিও দেখার সময় 60 fps এর একটি স্থির ফ্রেমরেট দেখতে পারেন৷ টেকনিক্যালি, এটি পুরোপুরি মসৃণ, কিন্তু ভিডিওর নিজেই কম বিট রেট থাকতে পারে বা নেটওয়ার্ক বাফারিংয়ের সমস্যা থাকতে পারে। এটি সরাসরি অ্যানিমেশন মসৃণতা মেট্রিক্স দ্বারা ক্যাপচার করা হয় না, তবুও ব্যবহারকারীর কাছে বিরক্তিকর হতে পারে।
অথবা, একটি গেম যা <canvas> (সম্ভবত একটি স্থির ফ্রেম রেট নিশ্চিত করতে অফস্ক্রিন ক্যানভাসের মতো কৌশলগুলি ব্যবহার করে) ব্যবহার করে অ্যানিমেশন ফ্রেমের পরিপ্রেক্ষিতে প্রযুক্তিগতভাবে পুরোপুরি মসৃণ হতে পারে, যখন দৃশ্যে উচ্চ মানের গেম সম্পদ লোড করতে ব্যর্থ হয় বা রেন্ডারিং প্রদর্শন করে শিল্পকর্ম
এবং অবশ্যই, একটি সাইটে কিছু সত্যিই খারাপ অ্যানিমেশন থাকতে পারে 🙂
আমি বলতে চাচ্ছি, আমি অনুমান করি যে তারা তাদের সময়ের জন্য বেশ দুর্দান্ত ছিল!
একটি একক অ্যানিমেশন ফ্রেমের অবস্থা
যেহেতু ফ্রেমগুলি আংশিকভাবে উপস্থাপিত হতে পারে, বা বাদ দেওয়া ফ্রেমগুলি এমনভাবে ঘটতে পারে যা মসৃণতাকে প্রভাবিত করে না, আমরা প্রতিটি ফ্রেমের একটি সম্পূর্ণতা বা মসৃণতা স্কোর হিসাবে ভাবতে শুরু করেছি৷
এখানে আমরা একটি একক অ্যানিমেশন ফ্রেমের অবস্থা ব্যাখ্যা করার উপায়গুলির বর্ণালী, সেরা থেকে খারাপ ক্ষেত্রে অর্ডার করা হয়েছে:
| কোন আপডেট কাঙ্ক্ষিত | নিষ্ক্রিয় সময়, আগের ফ্রেমের পুনরাবৃত্তি। |
| সম্পূর্ণরূপে উপস্থাপিত | প্রধান থ্রেড আপডেট হয় সময়সীমার মধ্যে প্রতিশ্রুতিবদ্ধ ছিল, বা কোন প্রধান থ্রেড আপডেট পছন্দসই ছিল না। |
| আংশিকভাবে উপস্থাপন করা হয়েছে | শুধুমাত্র কম্পোজিটর; বিলম্বিত প্রধান থ্রেড আপডেটের কোন চাক্ষুষ পরিবর্তন ছিল না। |
| আংশিকভাবে উপস্থাপন করা হয়েছে | শুধুমাত্র কম্পোজিটর; মূল থ্রেডটিতে একটি ভিজ্যুয়াল আপডেট ছিল, কিন্তু সেই আপডেটে এমন একটি অ্যানিমেশন অন্তর্ভুক্ত ছিল না যা মসৃণতাকে প্রভাবিত করে। |
| আংশিকভাবে উপস্থাপন করা হয়েছে | শুধুমাত্র কম্পোজিটর; মূল থ্রেডটিতে একটি ভিজ্যুয়াল আপডেট ছিল যা মসৃণতাকে প্রভাবিত করে, তবে একটি পূর্বে বাসি ফ্রেম এসেছে এবং পরিবর্তে ব্যবহার করা হয়েছিল। |
| আংশিকভাবে উপস্থাপন করা হয়েছে | শুধুমাত্র কম্পোজিটর; পছন্দসই প্রধান আপডেট ছাড়াই, এবং কম্পোজিটর আপডেটে একটি অ্যানিমেশন রয়েছে যা মসৃণতাকে প্রভাবিত করে। |
| আংশিকভাবে উপস্থাপন করা হয়েছে | শুধুমাত্র কম্পোজিটর কিন্তু কম্পোজিটর আপডেটে এমন কোনো অ্যানিমেশন নেই যা মসৃণতাকে প্রভাবিত করে। |
| বাদ দেওয়া ফ্রেম | কোন আপডেট নেই। কোন কম্পোজিটর আপডেট কাঙ্খিত ছিল না, এবং প্রধান বিলম্বিত হয়েছে. |
| বাদ দেওয়া ফ্রেম | একটি কম্পোজিটর আপডেট আকাঙ্ক্ষিত ছিল, কিন্তু এটি বিলম্বিত হয়েছে৷ |
| বাসি ফ্রেম | একটি আপডেট আকাঙ্ক্ষিত ছিল, এটি রেন্ডারার দ্বারা উত্পাদিত হয়েছিল, কিন্তু GPU এখনও vsync সময়সীমার আগে এটি উপস্থাপন করেনি৷ |
এই রাজ্যগুলিকে কিছুটা স্কোরে পরিণত করা সম্ভব। এবং সম্ভবত এই স্কোরটি ব্যাখ্যা করার একটি উপায় হল এটি ব্যবহারকারীর দ্বারা পর্যবেক্ষণযোগ্য হওয়ার সম্ভাবনা বিবেচনা করা। একটি একক ড্রপ ফ্রেম খুব পর্যবেক্ষণযোগ্য নাও হতে পারে, কিন্তু একটি সারিতে মসৃণতা প্রভাবিত অনেক ড্রপ ফ্রেম একটি ক্রম নিশ্চিত!
এটি সব একসাথে রাখা: একটি শতাংশ ড্রপড ফ্রেম মেট্রিক
যদিও কখনও কখনও প্রতিটি অ্যানিমেশন ফ্রেমের অবস্থার গভীরে ডুব দেওয়া প্রয়োজন হতে পারে, তবে অভিজ্ঞতার জন্য শুধুমাত্র একটি দ্রুত "এক নজরে" স্কোর বরাদ্দ করাও দরকারী।
যেহেতু ফ্রেমগুলি আংশিকভাবে উপস্থাপিত হতে পারে, এবং এমনকি সম্পূর্ণরূপে এড়িয়ে যাওয়া ফ্রেম আপডেটগুলি আসলে মসৃণতাকে প্রভাবিত করতে পারে না, তাই আমরা শুধুমাত্র ফ্রেম গণনা করার উপর কম ফোকাস করতে চাই এবং ব্রাউজারটি যখন গুরুত্বপূর্ণ তখন দৃশ্যত সম্পূর্ণ আপডেটগুলি প্রদান করতে অক্ষম।
মানসিক মডেল থেকে সরানো উচিত:
- ফ্রেম প্রতি সেকেন্ড , থেকে
- অনুপস্থিত এবং গুরুত্বপূর্ণ অ্যানিমেশন আপডেট সনাক্ত করা, থেকে
- একটি নির্দিষ্ট সময়ের মধ্যে শতাংশ কমে গেছে ।
কী গুরুত্বপূর্ণ: গুরুত্বপূর্ণ আপডেটের জন্য অপেক্ষা করা সময়ের অনুপাত । আমরা মনে করি এটি ব্যবহারকারীদের অনুশীলনে ওয়েব সামগ্রীর মসৃণতা অনুভব করার প্রাকৃতিক উপায়ের সাথে মেলে। এখনও অবধি, আমরা মেট্রিক্সের প্রাথমিক সেট হিসাবে নিম্নলিখিতগুলি ব্যবহার করছি:
- গড় শতাংশ ড্রপড: পুরো টাইমলাইন জুড়ে সমস্ত নন-অলস অ্যানিমেশন ফ্রেমের জন্য
- পার্সেন্ট ড্রপড ফ্রেমের সবচেয়ে খারাপ কেস: সময়ের 1 সেকেন্ডের স্লাইডিং উইন্ডোতে পরিমাপ করা হয়েছে।
- শতকরা ড্রপড ফ্রেমের 95 তম পার্সেন্টাইল: সময়ের 1 সেকেন্ডের স্লাইডিং উইন্ডোতে পরিমাপ করা হয়েছে।
আপনি আজ কিছু Chrome বিকাশকারী সরঞ্জামগুলিতে এই স্কোরগুলি খুঁজে পেতে পারেন৷ যদিও এই মেট্রিক্সগুলি শুধুমাত্র সামগ্রিক ফ্রেম থ্রুপুটের উপর ফোকাস করে, আমরা ফ্রেম লেটেন্সির মতো অন্যান্য কারণগুলিও মূল্যায়ন করছি।
ডেভেলপার টুলিংয়ে নিজে চেষ্টা করে দেখুন!
কর্মক্ষমতা HUD
ক্রোমিয়ামের একটি পতাকার পিছনে লুকানো একটি ঝরঝরে পারফরম্যান্স HUD রয়েছে ( chrome://flags/#show-performance-metrics-hud )। এটিতে, আপনি কোর ওয়েব ভাইটালগুলির মতো জিনিসগুলির জন্য লাইভ স্কোর এবং সময়ের সাথে শতাংশ ড্রপড ফ্রেমের উপর ভিত্তি করে অ্যানিমেশন মসৃণতার জন্য কয়েকটি পরীক্ষামূলক সংজ্ঞা খুঁজে পেতে পারেন।
ফ্রেম রেন্ডারিং পরিসংখ্যান
নতুন অ্যানিমেশন ফ্রেমের একটি লাইভ ভিউ দেখতে রেন্ডারিং সেটিংসের মাধ্যমে DevTools-এ "ফ্রেম রেন্ডারিং পরিসংখ্যান" সক্ষম করুন , যেগুলি সম্পূর্ণ-ড্রপ করা ফ্রেম আপডেটগুলি থেকে আংশিক আপডেটগুলিকে আলাদা করতে রঙ-কোড করা হয়েছে৷ রিপোর্ট করা fps শুধুমাত্র সম্পূর্ণরূপে উপস্থাপিত ফ্রেমের জন্য।
DevTools পারফরম্যান্স প্রোফাইল রেকর্ডিং-এ ফ্রেম ভিউয়ার
DevTools পারফরম্যান্স প্যানেলে দীর্ঘদিন ধরে ফ্রেম ভিউয়ার রয়েছে। যাইহোক, আধুনিক রেন্ডারিং পাইপলাইন আসলে কীভাবে কাজ করে তার সাথে এটি সিঙ্কের বাইরে কিছুটা বেড়েছে। সাম্প্রতিক অনেক উন্নতি হয়েছে, এমনকি সাম্প্রতিক ক্রোম ক্যানারিতেও, যা আমরা মনে করি অ্যানিমেশন সমস্যাগুলি ডিবাগিংকে অনেক সহজ করবে৷
আজ আপনি দেখতে পাবেন যে ফ্রেম ভিউয়ারের ফ্রেমগুলি vsync সীমানার সাথে আরও ভালভাবে সারিবদ্ধ, এবং স্থিতির উপর ভিত্তি করে রঙ-কোডেড। উপরে বর্ণিত সমস্ত সূক্ষ্মতার জন্য এখনও সম্পূর্ণ ভিজ্যুয়ালাইজেশন নেই, তবে আমরা অদূর ভবিষ্যতে আরও যোগ করার পরিকল্পনা করছি।
ক্রোম ট্রেসিং
অবশেষে, ক্রোম ট্রেসিং-এর সাথে, বিশদ বিবরণের গভীরে যাওয়ার জন্য পছন্দের টুল, আপনি নতুন পারফেটো UI (বা about:tracing ) এর মাধ্যমে একটি "ওয়েব সামগ্রী রেন্ডারিং" ট্রেস রেকর্ড করতে পারেন এবং Chrome এর গ্রাফিক্স পাইপলাইনের গভীরে খনন করতে পারেন৷ এটি একটি কঠিন কাজ হতে পারে, তবে এটি সহজ করার জন্য সম্প্রতি Chromium-এ কিছু জিনিস যোগ করা হয়েছে৷ লাইফ অফ এ ফ্রেম ডকুমেন্টে কী পাওয়া যায় তার একটি ওভারভিউ আপনি পেতে পারেন।
ট্রেস ইভেন্টগুলির মাধ্যমে আপনি নিশ্চিতভাবে নির্ধারণ করতে পারেন:
- কোন অ্যানিমেশনগুলি চলছে (
TrackerValidationনামে ইভেন্ট ব্যবহার করে)। - অ্যানিমেশন ফ্রেমের সঠিক টাইমলাইন পাওয়া (
PipelineReporterনামে ইভেন্ট ব্যবহার করে)। - জ্যাঙ্কি অ্যানিমেশন আপডেটের জন্য, ঠিক কী আপনার অ্যানিমেশনকে দ্রুত চলতে বাধা দিচ্ছে তা খুঁজে বের করুন (
PipelineReporterইভেন্টের মধ্যে ইভেন্ট ব্রেকডাউন ব্যবহার করে)। - ইনপুট-চালিত অ্যানিমেশনের জন্য, দেখুন একটি ভিজ্যুয়াল আপডেট পেতে কতক্ষণ লাগে (
EventLatencyনামে ইভেন্ট ব্যবহার করে)।
এরপর কি
ওয়েব ভাইটালস উদ্যোগের লক্ষ্য ওয়েবে দুর্দান্ত ব্যবহারকারীর অভিজ্ঞতা তৈরির জন্য মেট্রিক এবং নির্দেশিকা প্রদান করা। টোটাল ব্লকিং টাইম (TBT) এর মতো ল্যাব-ভিত্তিক মেট্রিকগুলি সম্ভাব্য ইন্টারঅ্যাক্টিভিটি সমস্যাগুলি ধরা এবং নির্ণয়ের জন্য গুরুত্বপূর্ণ। আমরা অ্যানিমেশন মসৃণতার জন্য অনুরূপ ল্যাব-ভিত্তিক মেট্রিক ডিজাইন করার পরিকল্পনা করছি।
পৃথক অ্যানিমেশন ফ্রেম ডেটার উপর ভিত্তি করে একটি বিস্তৃত মেট্রিক ডিজাইন করার জন্য ধারণাগুলির মাধ্যমে কাজ চালিয়ে যাওয়ার সাথে সাথে আমরা আপনাকে পোস্ট করব৷
ভবিষ্যতে, আমরা এমন API গুলি ডিজাইন করতে চাই যা ক্ষেত্রের পাশাপাশি ল্যাবে প্রকৃত ব্যবহারকারীদের জন্য অ্যানিমেশন মসৃণতা পরিমাপ করা সম্ভব করে। সেখানে আপডেটের জন্যও সাথে থাকুন!
প্রতিক্রিয়া
অ্যানিমেশন মসৃণতা পরিমাপ করার জন্য Chrome-এ পাঠানো সাম্প্রতিক উন্নতি এবং বিকাশকারী সরঞ্জামগুলির জন্য আমরা উত্তেজিত৷ অনুগ্রহ করে এই টুলগুলি ব্যবহার করে দেখুন, আপনার অ্যানিমেশনগুলিকে বেঞ্চমার্ক করুন এবং আমাদের জানান যে এটি কোথায় নিয়ে যায়!
আপনি বিষয় লাইনে "[মসৃণতা মেট্রিক্স]" সহ ওয়েব-ভিটালস-ফিডব্যাক Google গ্রুপে আপনার মন্তব্য পাঠাতে পারেন। আমরা সত্যিই আপনি কি মনে করেন শোনার জন্য উন্মুখ!