Support our independent tech coverage. Chrome Unboxed is written by real people, for real people—not search algorithms. Join Chrome Unboxed Plus for just $2 a month to get an ad-free experience, access to our private Discord, and more. Learn more about membership here.
START FREE TRIAL (MONTHLY)START FREE TRIAL (ANNUAL)
It is no secret that one of the big struggles right now for Chrome OS, Chromebooks, detachables, and tablets is overview and split-screen mode. While the majority of the OS can run smooth on various chipsets, we see severely crippled performance across the board when it comes to both the overview mode and split-screen views. We’ve detailed a bit about this issue and the fixes being worked on, but the fixes outlined in that article are really more about the overview mode in both desktop and tablet mode.
In general (and in recap), for the overview portion of the problem, there is noticeable lag and frame drops anytime the user enters overview mode whether in desktop or tablet mode. The problem is exacerbated for high-res displays, but is present with lower-powered processors, too. From the bug reports we can gather that much of the issue revolves around the way the corners of the windows get rounded when overview mode is triggered.
For what we’re talking about today, however, none of that matters.
The other side to this janky UI coin is what happens when tablets, convertibles, and detachables are in split-screen mode. While this mode still exhibits frame drops and lag when utilizing overview mode to switch apps, that isn’t the issue I’m addressing today. Instead, we’re talking about what happens when you resize your split-screen apps.
Because of the nature of Chrome OS, the content that could be in any split screen portion at any time could be any number of options: a web page, a web app, an Android app, or a Linux app. Because of the different content that could fill the screen at any given time, there are different ways that said content resizes when the window size shifts.
Even light websites have certain amounts of jitter and jank when being resized. That’s to say nothing of web apps, Android apps and Linux applications. The differing animations (and, at times, lack thereof) as containers are resized are simply a part of digital life at this point. For most situations, we load in an app or website at a certain size and, as long as it looks good in that window, we don’t really care how it got there.
However, now that we have so many situations where we are leveraging side-by-side UI, the way that apps get to their current size matters quite a bit more. Once we have two apps side-by-side, users are encouraged to drag that middle bar to resize them on the fly and, as they do so, they are met with all sorts of odd animations, jarring transitions, and frame drops.
The whole thing looks gross, honestly, and I think there is an elegant fix that is already in place on another tablet: the iPad.
The problem here isn’t really with the OS, whether it be Windows, iOS or Chrome OS. The issue is with the way that web elements and applications handle resizing. Developers are concerned with their app looking good on multiple display sizes, but as I said above, they aren’t too concerned with how the app transitions to that particular screen size. Because of this, the issue won’t likely get widely addressed anytime soon and OS developers can’t really do anything to fix this on their end.
However, with iOS, Apple has done a simple cover-up that addresses the issue now and well into the future when, perhaps, screen size transitions get some kind of universal animation fix. Take a look at the video below:
You can see the odd-looking transitions on the Pixelbook that, frankly, will never get fixed. And this example is a tame one, really, as many Android apps have all sorts of jarring transitions when the screen size changes. Compare that with what iOS does and the overall feel is night and day. With iOS, the windows simply blur out while those unsightly transitions occur. This allows a few things to happen: the resizing elements can do their thing without the end-user seeing the ugly transitions and the processor doesn’t have to figure out how to render it.
It is an elegant solution that I really hope Chrome OS adopts. In fact, I’m not just sitting here hoping: I’ve actually filed a bug report against this and am hoping our community here at Chrome Unboxed can help get this possible future feature pushed into the spotlight.
I really think Chrome OS tablets/detachables have a bright future, but little UI problems like this can really mar an otherwise great tablet experience. In a landscape where tablet and iPad are basically interchangeable nouns, users expect certain things. Seeing UI jank – even if the fault isn’t on the OS – is something that causes people to feel like the hardware and software are slow and incapable. While we may know this isn’t really the case, when key navigation elements suffer, most users assume the entire package is slow and unusable.
If you want to help get this part of the puzzle fixed in a way that should be relatively doable for the Chrome OS team, please CLICK HERE and then hit the star in the upper-left portion of the screen (Please note that you will need to be logged in with a Google Account to do this). The more stars we get on the issue, the more attention it will draw from the developers. They deal with a lot of stuff on a daily basis, so getting their eyes on a particular issue is tough. I think with our community, we can definitely do this!
Again, head over to the bug report and star this issue (and leave a comment while you are at it if you feel up to it) and we could be on the road to reshaping a portion of Chrome OS for the better as a group. That would be something, wouldn’t it?
