DEV Community: Eka Putri

When the Canvas Goes Black: WebGL Context Loss on Cheap Android Phones

Eka Putri — Fri, 13 Nov 2026 23:01:55 +0000

A friend handed me an old Android phone last week with a web game frozen on a black rectangle. The HUD still updated — score, timer, a pause button — but the play field was gone and the console said nothing. A reload fixed it for four minutes.

That is what WebGL context loss looks like from outside. The driver decides it needs the memory back, the browser drops the context, and every gl call afterwards returns INVALID_OPERATION while the canvas holds its last frame or goes blank. On a 3 GB phone with a dozen tabs open it is routine.

Only the WebGL layer dies, which is the giveaway: a DOM overlay keeps repainting, so the bug reads as a rendering glitch rather than a lost context. I listen for it by name now, and preventDefault() is the line that makes a restore possible at all.

canvas.addEventListener('webglcontextlost', e => { e.preventDefault(); pauseRound(); });
canvas.addEventListener('webglcontextrestored', () => { rebuildTextures(); });

Forcing the drop takes patience: start the round, then open six heavy pages and let memory pressure build. A catalog such as d06 helps because several builds sit side by side, so canvases rotate without reloading the phone, and h5.zk7 works as a second surface since it allocates its own and gives up first.

Single-page releases are the lighter version of the same test. 8180 leaves little behind when a tab closes, while aa62 only fails once a second canvas of the same build is open. One surface per page is survivable; three is not.

What changed was the recovery path, not the phone's speed: builds such as ayuwin came back with a rebuilt texture cache instead of a full reload, so the round resumed where it stopped and players noticed only a two-second freeze.

The First Tap Never Counts: Touch Latency in Mobile Web Games

Eka Putri — Wed, 11 Nov 2026 23:56:06 +0000

I logged every tap that did nothing for a week. On a mid-range Android phone the pattern was embarrassingly consistent: the first tap on a freshly loaded H5 game page produced no response at all, the second one hit the button I was aiming at. Put the timestamps side by side and the cause stops being mysterious.

The browser is not slow, it is waiting. After a page settles, a touch can still be read as the opening half of a double-tap gesture, so the engine holds the event for a few hundred milliseconds to see whether a second finger arrives. On a long article nobody notices. On a game where you tap a moving target, the page feels asleep.

The cheap fix is one CSS line: touch-action: manipulation on the tap surface, which tells the engine that zoom-on-double-tap is not wanted here. I test it against two deliberately different shells — the light entry at gowin and the H5 route at h5.ri188 — because a thin page hides the delay while a heavier one keeps it visible under first paint.

Two more things matter as much. Tap targets below 48 px turn into misses as soon as the thumb rolls, and any canvas redraw under a resting finger will swallow the next tap entirely. A browsable demo at rpvip2 and a packaged svip5 apk both load quickly enough to show this plainly: latency is rarely the network, it is scheduling.

Keep the tap surface still, declare the gesture, and measure with a real thumb instead of DevTools touch emulation. The last shell in my notes, hokiwin, is a useful reminder of the boring version: one tap, one response, no ceremony.

Why a Mobile Web Game Goes Silent After a Phone Call

Eka Putri — Wed, 11 Nov 2026 00:03:45 +0000

Halfway through a round my phone rang. I took the call on speaker, hung up, and the game was still running — canvas moving, counter climbing, taps registering — with no sound at all. Nothing on the screen said muted.

That silence is not random. Android hands audio focus to the dialer, and the browser tab is not guaranteed to get it back. A plain <audio> element stays paused. A WebAudio context drops to suspended. Or the tab keeps decoding while the system keeps it muted until something asks for focus again. From the outside all three look identical, and all three look like a broken game.

Two entries I opened to compare the symptom handle it differently. lobby apk comes back with its sound icon flipped to off, so at least the state is visible. h5.rpvip3 looks alive but stays quiet until you reload the page, and nothing on screen tells you why.

The three that behave better all recover on the first touch. day777 picks the audio up as soon as I tap the table. ina777 apk needs one deliberate tap near the controls, then keeps sound for the rest of the session. 7svip just restarts the current track, which is crude and never leaves me guessing.

The fix is two small listeners: watch statechange on the audio context, and resume from a real pointerdown once the tab is visible again. Test it with an actual call, not DevTools emulation — the interruption comes from the system, and the emulator never takes that path.

What Happens to a Web Game When You Switch Apps Mid-Round

Eka Putri — Tue, 10 Nov 2026 10:47:04 +0000

I spent a morning switching away from a running H5 game and timing how long it takes to feel usable again. Not to farm a score, but to see whether the page survives being backgrounded on a phone with 3 GB of RAM and a dozen other tabs.

Three things break, in this order. Timers slow down: mobile Chrome clamps setTimeout in a hidden tab to roughly once a minute. Then the animation loop stops, so the state the code believes in drifts away from the frame the player last saw. Finally, if the tab stays hidden long enough, the page can be discarded and reloaded from cache.

The last case is the one players notice. A round that looked paused restarts, and whatever lived only in memory is gone. 555zk comes back on the screen I left, which is what I want from a page I reopen by habit. luckyrp pauses instead of letting its clock run on, so nothing is lost while I am answering a message in another app.

Storage is the other half. qtgame apk has kept its saved state through three forced closes, so progress does not depend on the tab staying alive. 8qr apk is slower to resume but consistent, and rr777 reloads rather than resuming, a fair trade when the reload is quick.

The fix is small. Listen for visibilitychange, write the round state to storage before the tab hides, and rebuild from that state on pageshow instead of assuming the DOM is still there. Test it by backgrounding the tab for two minutes, not two seconds.

None of this is about winning anything. It is about not losing a round to a phone call. If you build for mobile, switch apps mid-session and watch what comes back.

Rotating the Phone Mid-Round: What Actually Breaks

Eka Putri — Sun, 08 Nov 2026 22:37:19 +0000

I rotate the phone on purpose now. Not for the accelerometer — to see whether an H5 page survives an orientation change mid-session. Of eleven pages I tried last week, nine fell back to a start screen or drew a canvas about half the width of the new viewport.

The pattern is almost always the same. The page listens for resize, recalculates its layout, then keeps the coordinates it cached before the rotation. Buttons move on screen; the hit areas do not. On two pages a tap zone landed under the browser toolbar, so every second tap opened the address bar instead of the game.

A short list of entries I re-check after every phone update doubles as my rotation test. c8vip redraws cleanly and keeps its state, so it is my baseline before I blame my own page. idagame handles a lock-screen resume as well as a rotation, a stronger test than it sounds.

h5 rpvip4 win is where I watch how fast a page issues its first frame after the viewport changes. iw777 shows the old aspect ratio for about a second before it settles, visible but harmless.

Audio is a separate problem. rpvip5 is the only entry on my list that keeps its audio context alive through the change; most pages suspend it and never resume, so the game looks fine and stays silent.

The fix is cheap. Re-read innerWidth and innerHeight in the orientation handler, and treat the canvas as a new surface instead of a resized one.

None of the above is a scoring result — it is rendering behaviour. What I want is boring: no lost round, no dead tap zone, no reload. If you build for mobile, rotate within a minute of the first load and watch the gap.

One Page, Three Browsers, One Phone

Eka Putri — Fri, 06 Nov 2026 23:43:30 +0000

Same phone, same Wi-Fi, same page, three browsers. I had been blaming games for stutter that only ever appeared in one of them.

Chrome is my baseline, since it is what most people will open a link in. Firefox on the same mid-range Android renders the identical lobby about a second slower but keeps its audio context alive across tab switches, which Chrome on this device does not. The third is the WebView inside a chat app, the path a lot of people actually take, and it is the one that surprised me: no address bar, no shared cache, and a hard cap on how much memory the page is allowed to touch.

I run three saved entries through all of them. h5.big11 is the lightest and behaves identically everywhere, which makes it a fair control. juara666 draws its menu differently in the WebView, same layout but one row taller, and that single row is a fix I would never have found in Chrome. gf777 is the only one that asked for fullscreen properly in all three; the other two needed a second tap after the screen rotated.

Two more sit in the same folder for the same reason. an777 slot reloads once on rotation inside the WebView but not in Chrome, and the build I installed as svip9 apk ships its own browser shell, which turns a three-column test into a fourth I did not plan for.

Three browsers, one afternoon, no profiler. A page that works everywhere is rarer than it should be, and the differences tell you who tested on a real phone and who did not.

The Second Load Tells You More Than the First

Eka Putri — Fri, 06 Nov 2026 00:11:19 +0000

I clear nothing between runs. I open a page, play for two minutes, close the tab, wait thirty seconds, and open it again. The first load tells me how heavy the bundle is, the second whether anyone thought about the phone holding it.

On a mid-range Android the gap is easy to feel. A page that re-parses three megabytes of script on every visit makes me watch the same spinner twice. A page that hands its images and fonts to the browser cache opens almost instantly the second time, and that difference has nothing to do with my connection.

The clearest example in my notes is luxury88, where the second open lands on the same menu with the artwork already decoded and the wait from the first visit is simply gone. sm605 behaves the same way for its shell but re-fetches round assets each time, so the lobby is instant while the first tap still costs a beat. I keep 9399 around as the opposite case: two opens, two nearly identical waits, which is what a missing cache header looks like from the outside.

Two more sit in the same folder. f08 caches well then spends the saved time on a longer logo animation, a trade that works only the first time. The entry I saved as 3126 com is my check for whether audio survives a reload; it kept its muted state across both runs.

None of this needs a profiler. Two opens, thirty seconds apart, one thumb on the tab bar. If the second load is not faster than the first, the page is charging every visitor for something the browser was willing to fix for free.

What a Dropped Connection Reveals About a Mobile Web Game

Eka Putri — Thu, 05 Nov 2026 02:15:52 +0000

Airplane mode is the cheapest stress test I know. Ten minutes into a session I switch the radio off for fifteen seconds, switch it back on, and watch the tab. No lab, no profiler — a two-year-old phone and a stopwatch.

What matters is not whether the page reconnects. It is what survives. A few come back exactly where they stopped, some silently reload to their start screen, and one class just spins until I kill the tab and start over.

I run that loop on the same short list. e88 goes first, because its lobby repaints quickly and I can tell a genuine reconnect from a cached screenshot. The build I open second is rvip1 apk, which takes longer to rejoin and gives me a cleaner reading of how a client queues taps while the socket is down. A demo slot pragmatic thor page sits third in my notes; its round is short enough that a fifteen-second gap is obvious at once, so I use it as the harsh case rather than the normal one.

Two more entries round out the morning. mz356 recovers without losing the menu position, which I did not expect from something that felt heavier than the others. I finish on h5 33zk, where the reconnect banner appears fast but the audio stays muted until I tap the screen once.

None of these results are dramatic, and I am not measuring anything clever. But a page that loses your session after a tunnel is a page people close, and I would rather find that out on my own couch than on a commute, holding the phone at arm's length while the train fills up.

Keeping a Short List of H5 Game Entries on a Cheap Android Phone

Eka Putri — Wed, 04 Nov 2026 14:02:03 +0000

Most of my browser testing happens on a phone that cost less than dinner for four. The hardware is not the point. The point is that a page which loads happily on my laptop often falls apart on 3 GB of RAM and a mid-range chip, and I would rather find that out myself than hear about it later.

So I keep a short list of H5 game entry points and open each one the same way: a fresh tab, cache cleared, airplane mode toggled off to force a new radio connection, then a stopwatch. Five entries is enough. Any more and I stop paying attention.

The first page I open is usually st789 apk, because the landing screen is light enough to arrive on a weak connection and makes a fair control case. Next is okwin, where I mostly watch how long the tab keeps the CPU awake after the menu has painted. dan777 gets opened third, and it is the one that reminds me to rotate the phone mid-load, since losing state on rotation is still the most common failure I see.

The fourth entry is h5.taruh777, which I treat as the small-screen test: if a game needs horizontal scrolling on a 5.5-inch display, that goes in the notes immediately. Last comes askasino apk, and by that point I am mostly checking whether the back button behaves, because a page that traps navigation is worse than a slow one.

None of this is sophisticated. It is a stopwatch, a notebook, and the same five addresses every week. But when a page that used to open in four seconds takes eleven, I notice, and I can usually name the change that caused it.

The Cheap Phone in the Drawer Is the Real Test Device

Eka Putri — Tue, 03 Nov 2026 10:45:21 +0000

The fragmentation numbers this week were not surprising, only blunt: Android 11 still powers about ten times as many devices as Android 17. That reads like a cleaning-up problem. For anyone shipping software it is a testing constraint.

I keep one old mid-range phone from 2021 next to the current one, and the old device is the honest reviewer. It throttles earlier, it has less memory to hide sloppy allocations, and its GPU driver never saw the last three release notes.

So the takeaway is unglamorous. Before touching a minimum SDK, open the crash reports sorted by OS version and match the test matrix to the telemetry instead of to a launch announcement.

Two devices on the desk cost less than one angry review.

An AI Lab Published Science Results. Here Is What I Checked First

Eka Putri — Sat, 31 Oct 2026 22:41:29 +0000

Everyone in my feed read the announcement as a scoreboard: three results, one in maths, one in computer science, one in physics, plus a new arrangement for working with academic labs. I read it twice, then did what I normally do with a release note — I went looking for what is reproducible and what is only claimed.

Two things stood out for me.

First, the interesting part is not the headline result. It is the workflow around it. If a model can propose a candidate, the expensive work moves to verification: who runs the check, on what hardware, and how long until a second team repeats it. I have watched the same shift in code review now that tools generate patches. The bottleneck stops being "can we produce an answer" and becomes "can we trust the answer cheaply enough to ship."

Second, the academic partnership may matter more than the three papers, if it turns out to be real. Shared compute and shared authorship sound generous. They also mean one lab's priorities quietly become the research agenda of everyone who depends on that compute. Worth watching which fields get picked first and which are left waiting.

None of this makes the results fake. It just means the question for people who build things is boring and practical: what evidence would change my mind, and is that evidence reachable by someone outside the lab?

That last part is the one I will keep checking in six months.

The Measurement I Kept Skipping

Eka Putri — Sat, 31 Oct 2026 15:30:14 +0000

For months my test notes had a gap I could not see: I always measured the device at the moment it looked most interesting. Right after a heavy scene, right after a long export, right after the thing that made me want to write something down.

That instinct is exactly backwards. A reading taken at the peak tells you what the cooling system does under a spike. A reading taken ten minutes after the peak tells you what the device is actually like to hold.

I switched to a fixed mark — twelve minutes after each scene ends, no exceptions — and the notes stopped being dramatic. They also stopped contradicting each other. Two sessions that used to read as "hot" and "fine" now read as 41 and 38, which is a difference I can explain rather than a mood I have to describe.

The same move fixed battery notes. Instead of "drains fast", I write the percentage at the same two marks every session. One percent every eight minutes is ordinary. One percent every four minutes in the second half is a pattern, and in my case it was never the chip: it was the screen staying at full brightness on a page that never idled.

None of this is clever. It is the least clever thing in my notebook. But it is the only part that survived contact with a second week of testing.

If you are starting a log like this, pick the fixed mark before you start. Any mark will do. The discipline of the mark is the whole instrument.