{"id":16303,"date":"2026-10-25T15:15:20","date_gmt":"2026-10-25T15:15:20","guid":{"rendered":"https:\/\/rjoytek.com\/"},"modified":"2026-10-27T07:19:13","modified_gmt":"2026-10-27T07:19:13","slug":"lcd%e3%83%87%e3%82%a3%e3%82%b9%e3%83%97%e3%83%ac%e3%82%a4%e3%81%ab%e3%81%8a%e3%81%91%e3%82%8b%e8%a7%a3%e5%83%8f%e5%ba%a6%e3%82%b9%e3%82%b1%e3%83%bc%e3%83%ab","status":"publish","type":"post","link":"https:\/\/rjoytek.com\/ja\/lcd%e3%83%87%e3%82%a3%e3%82%b9%e3%83%97%e3%83%ac%e3%82%a4%e3%81%ab%e3%81%8a%e3%81%91%e3%82%8b%e8%a7%a3%e5%83%8f%e5%ba%a6%e3%82%b9%e3%82%b1%e3%83%bc%e3%83%ab\/","title":{"rendered":"LCD\u89e3\u50cf\u5ea6\u30ac\u30a4\u30c9\uff1a\u30d4\u30af\u30bb\u30eb\u3001\u30b9\u30b1\u30fc\u30ea\u30f3\u30b0\u3001\u9069\u5207\u306a\u30c7\u30a3\u30b9\u30d7\u30ec\u30a4\u306e\u9078\u3073\u65b9"},"content":{"rendered":"

LCD resolution<\/strong> is the number of physical pixels arranged across and down a display. An 800 \u00d7 480 panel has 800 columns and 480 rows, or 384,000 pixels. Resolution determines the pixel grid available for an image, but it does not by itself determine readability, color, brightness or compatibility.<\/p>\n

For an embedded or industrial product, the right resolution is the one that makes the interface usable at its real size and viewing distance while fitting the processor, memory, display interface and enclosure. This guide explains how to compare those factors, calculate pixel density and estimate system load before choosing an LCD module.<\/p>\n

What does LCD resolution mean?<\/h2>\n

Resolution is normally written as horizontal pixels \u00d7 vertical pixels in the panel’s specified orientation. Multiply the two values to find the total pixel count. A 1920 \u00d7 1080 panel contains 2,073,600 pixels; an 800 \u00d7 480 panel contains 384,000. A pixel in a typical color LCD is made from subpixels, commonly red, green and blue. The stated resolution counts image pixels, not the number of individual color subpixels.<\/p>\n

Resolution is a spatial measurement. Refresh rate is the number of times an image is presented per second; color depth describes the encoding or available levels of color. A specification such as 1280 \u00d7 800 does not establish refresh rate, interface, viewing angle or actual color performance.<\/p>\n

Native resolution and input resolution<\/h3>\n

Native resolution describes the panel’s physical pixel matrix. Software cannot turn an 800 \u00d7 480 glass panel into a 1920 \u00d7 1080 panel. The host or a controller may output or accept a different input resolution, but a suitable scaler must map that image to the fixed matrix. Check which modes the actual board supports.<\/p>\n

A one-to-one mapping between correctly rendered source pixels and panel pixels usually gives a clean result for fine text and lines. Scaling can still be useful, especially for an interface designed for a larger logical canvas, but the result depends on the scaling method, content and aspect ratio. A controller may scale, crop, add borders or reject a mode; do not assume it will do one particular operation.<\/p>\n

Resolution, screen size and pixel density<\/h2>\n
\"Two
Conceptual size comparison; it does not establish either panel\u2019s resolution.<\/figcaption><\/figure>\n

Screen size is usually the diagonal of the active display area in inches. Resolution is the pixel count. Pixel density, commonly expressed as pixels per inch (PPI), relates the two. If two rectangular panels have the same pixel matrix, the smaller diagonal has a higher PPI.<\/p>\n

For a rectangular active area with square pixels, estimate diagonal density as:<\/p>\n

PPI = \u221a(horizontal pixels\u00b2 + vertical pixels\u00b2) \u00f7 diagonal inches<\/strong><\/p>\n

For example, an 800 \u00d7 480 matrix has approximately 933 diagonal pixels. At a 5-inch active diagonal it is about 187 PPI; at 10 inches it is about 93 PPI. These are calculated examples, not specifications for particular RJY products. Confirm the actual active-area dimensions and pixel layout in the datasheet, especially for round, cut or nonstandard panels.<\/p>\n

Higher PPI can make curves and fine text look smoother at a given viewing distance. It does not guarantee that the interface is readable: if a designer keeps the same number of pixels per letter while shrinking the panel, the physical letter becomes smaller. Ambient light, contrast, font design, viewing distance and user needs also matter.<\/p>\n

Common LCD resolutions and aspect ratios<\/h2>\n
Pixel matrix<\/th>Total pixels<\/th>Aspect ratio<\/th>Selection context<\/th><\/tr><\/thead>
480 \u00d7 272<\/td>130,560<\/td>30:17<\/td>Compact graphical interfaces; verify space for text and controls.<\/td><\/tr>
800 \u00d7 480<\/td>384,000<\/td>5:3<\/td>Common embedded format; evaluate UI and host capabilities.<\/td><\/tr>
1024 \u00d7 600<\/td>614,400<\/td>128:75<\/td>Wider layouts with more pixels than 800 \u00d7 480.<\/td><\/tr>
1280 \u00d7 720<\/td>921,600<\/td>16:9<\/td>Widescreen graphics or video when the host supports the mode.<\/td><\/tr>
1280 \u00d7 800<\/td>1,024,000<\/td>16:10<\/td>Widescreen layout with more vertical space than 16:9 at the same width.<\/td><\/tr>
1920 \u00d7 1080<\/td>2,073,600<\/td>16:9<\/td>Higher-detail content, with a larger pixel-processing budget.<\/td><\/tr>
1080 \u00d7 1080<\/td>1,166,400<\/td>1:1<\/td>Square layout; design the interface for the available shape.<\/td><\/tr><\/tbody><\/table>\n

These matrices are examples, not recommended sizes for every application. The same matrix can appear in panels of different physical dimensions and with different interfaces. A round display may use a square pixel matrix while only part of the matrix is visible. Check the actual active-area drawing and mask.<\/p>\n

Why aspect ratio matters<\/h3>\n

Aspect ratio is the relationship between image width and height. If the source and display have different ratios, the system must choose a policy: preserve the image with unused areas, crop part of it, or stretch it. Stretching changes the proportions of text and graphics. For touch products, the visible layout and the touch-coordinate transformation must also agree.<\/p>\n

Rotation changes the presentation of width and height but does not alter the panel’s physical pixel count. Confirm how the operating system, display driver and touch stack handle rotation, especially at startup and in recovery screens.<\/p>\n

How much resolution does an LCD need?<\/h2>\n
\"A
Conceptual viewing evaluation; it does not report a test result.<\/figcaption><\/figure>\n

Start with the content and the person using it. A status panel with a few large values has different requirements from a device with dense tables, camera images or a map. More pixels make more detail possible, but the interface, source content and host must be able to use them.<\/p>\n

Define the smallest important content<\/h3>\n

Identify the smallest text, symbol, line or image detail that must be understood at the intended viewing distance. Build a representative screen, not just a resolution chart. Show alarms, translated labels, a typical data table and touch targets if they are part of the product. Test the result at the actual physical size and under expected lighting.<\/p>\n

A UI that looks adequate on a desktop preview may become difficult to use when displayed on a smaller panel. Increasing pixel count without changing physical text size can improve edge detail, but it does not make the text larger. Use deliberate layout and UI scaling to maintain usable physical dimensions.<\/p>\n

Choose based on the complete product<\/h3>\n

Consider mechanical space, active-area shape, viewing distance, content density, host performance, memory, interface, power and the available module options. Compare at least one representative configuration at the intended resolution and refresh rate. An adequate, validated lower-resolution UI can be a better fit than a high-resolution design the host cannot update reliably.<\/p>\n

Native resolution, image scaling and UI scaling<\/h2>\n

These terms describe different parts of the image path. Image scaling<\/strong> resamples an image from one pixel matrix to another. UI scaling<\/strong> changes how large controls, text and other elements are drawn relative to the output pixels. A system can render a larger UI at the panel’s native output resolution; it does not have to lower the signal resolution to make controls easier to use. Microsoft documents how logical units and scaling factors can map interface elements to physical display pixels.[1]<\/a><\/sup><\/p>\n

A smaller image enlarged to a larger panel may soften fine details. The result depends on the scaler. Integer scaling can preserve hard pixel edges in suitable content, while interpolation can smooth them. Noninteger scaling can introduce uneven lines or blur; inspect real fonts and icons rather than assuming a particular visual outcome.<\/p>\n

If a 16:9 source is displayed on a 5:3 panel, a scaling policy must also handle the different shape. Test video, boot screens and application graphics separately because different components may apply different scaling rules. Changing the resolution of one application does not change the physical LCD matrix.<\/p>\n

How resolution affects framebuffer memory<\/h2>\n

A framebuffer stores pixel data for an image. A useful first estimate for an uncompressed, tightly packed buffer is:<\/p>\n

buffer bytes = width \u00d7 height \u00d7 bytes per pixel<\/strong><\/p>\n

At 800 \u00d7 480, RGB565 uses 2 bytes per pixel, so one tightly packed framebuffer requires 768,000 bytes, or about 0.73 MiB. At 1920 \u00d7 1080 with 4 bytes per pixel, one requires 8,294,400 bytes, or about 7.91 MiB. Two such buffers require twice the storage. These examples exclude row padding, additional layers, working surfaces and other allocations.<\/p>\n

Real framebuffers often use a row stride larger than width \u00d7 bytes per pixel. Use stride \u00d7 height<\/strong> to calculate the allocation for one buffer, then account for the actual number of buffers and layers. The host may also store assets, decoded video and intermediate images elsewhere. ST’s LCD-TFT controller guidance describes the relationship between framebuffer size, color depth, bandwidth and display configuration.[2]<\/a><\/sup><\/p>\n

Storage is not the same as bandwidth<\/h3>\n

Storage is the capacity needed to hold data. Bandwidth is the rate at which the system reads or writes it. A rough active-image scanout estimate is width \u00d7 height \u00d7 bytes per pixel \u00d7 refresh rate. For 800 \u00d7 480, 2 bytes per pixel and 60 frames per second, this is 46.08 MB\/s of active pixel data, using decimal megabytes. It excludes extra reads and writes, other layers, contention, alignment and implementation-specific overhead.<\/p>\n

This estimate is not a controller’s guaranteed memory requirement or a link-rate calculation. Some displays use local graphics memory and partial updates; others stream pixel data continuously. A particular controller may impose a higher peak demand than the simple active-data average. Measure the real design and check the controller and memory documentation.<\/p>\n

For practical framebuffer row-layout and pixel-format issues, see RJY’s framebuffer stride and RGB565 guide<\/a>.<\/p>\n

Resolution, refresh rate and display timing<\/h2>\n

For a conventional raster timing, the visible width and height are only the active area. The complete timing also includes horizontal and vertical blanking intervals. A common timing estimate is:<\/p>\n

pixel clock = horizontal total \u00d7 vertical total \u00d7 refresh rate<\/strong><\/p>\n

Horizontal and vertical totals include the active area and the relevant blanking periods. Use the panel’s actual timing definitions and allowable ranges; not every interface exposes the timing signals in the same way. ST provides this calculation in its LCD-TFT controller application note.[2]<\/a><\/sup><\/p>\n

Two panels can both be 800 \u00d7 480 yet have different required timing, pin assignments, power, initialization or backlight circuits. Equal resolution therefore does not prove interchangeability. For a detailed timing example, see the LCD pixel clock and timing guide<\/a>.<\/p>\n

Does higher resolution require a different interface?<\/h2>\n
\"A
Conceptual components; compatibility depends on the actual project.<\/figcaption><\/figure>\n

Resolution and refresh rate influence the amount of image data, but they do not uniquely select an interface. An LCD module may use SPI, parallel RGB, LVDS, MIPI DSI, eDP or another interface depending on its design. Confirm the particular module’s input, lane or channel configuration, data format, clock limits and initialization requirements.<\/p>\n

An HDMI output on a host does not mean that a bare panel accepts HDMI. A compatible active controller or bridge may be needed. Matching depends on panel model, resolution, interface, pin definition, timing, driver IC when available, power, backlight and touch requirements. Firmware and operating-system support also depend on the project. HDMI-to-MIPI conversion is not a universally compatible passive cable.<\/p>\n

Does resolution determine power consumption?<\/h2>\n

No single resolution value gives the total power of a display system. A different pixel matrix may change display driving, memory traffic and rendering work. The backlight, however, can be a substantial load, and lowering a software rendering resolution does not automatically reduce backlight power. Actual consumption depends on the panel, backlight level, electronics, content and operating mode.<\/p>\n

Measure the complete system at the intended brightness, image, update rate and ambient conditions. Record the host configuration as well as the display module. A published comparison without those conditions is not a reliable basis for choosing a particular product.<\/p>\n

Common mistakes in LCD resolution selection<\/h2>\n