A 3D scene tends to arrive with a loop. Keep requesting frames, update the scene, render again. For a game, time passing is often enough reason to do that. A shelf of inventory boxes might have a rather different job.
Suppose the camera is fixed, inventory changes only after a refresh, and clicking a box changes its selection outline. Between those events, the picture may be perfectly entitled to stay still.
The original Korean note was prompted by Kevin Roast's phoria2 introduction, which describes on-demand rendering. I am interested here in the design question, not in claiming a measured performance advantage for that library.
Find the inputs that change the picture
In this hypothetical inventory view, a data update, selection change, resize or camera movement can invalidate the scene. An animation introduces time as another input. A rotating product cannot use the same stopping rule as a fixed product.
The convenient thing about a continuous loop is that an unrecorded dependency may still appear to work: eventually another frame gets drawn. When the loop stops, the application has to know what changed. A stale selection highlight is not a successful optimization.
| Change | Expected response |
|---|---|
| Select a different item | Update the selection and redraw |
| Resize the viewport | Update viewport/projection and redraw |
| Run an animation | Continue frames while time changes the scene |
| No relevant input changed | Keep the existing picture |
This is a proposed behavior table. It is not a benchmark or a complete graphics implementation. Context restoration, resource loading and the application's own state transitions may add further invalidation events.
Fewer calls do not give a battery-life percentage
At sixty calls per second, one minute offers 3,600 render calls. That arithmetic does not tell us how much energy a device would save if some calls were removed. Scene complexity, display behavior, browser scheduling and the device all matter.
A useful comparison would preserve the same scene and interactions, check that necessary updates still appear, and measure the relevant resource on the target device. I would not attach a percentage to an unmeasured change.
There is also a simpler question beside the renderer: should the inventory information require a 3D view at all? A readable list of names and states can let someone finish the task without moving a camera. The interesting optimization might be understanding what the screen is for.
한국어 글: 움직이지 않는 3D 화면도 계속 그려야 할까