sunnyps

First of all, just extrapolating from someone's side/hobby/demo project to all WebGL pages is naive. The effort put into a demo is orders of magnitude less than a real site.

Second, "GPU-enabled JavaScript" has already taken off. Ever used Google Maps or Google Earth - both use WebGL heavily? Or maybe you read the NYTimes who occasionally produce pages with a heavy WebGL focus[1].

[1] https://www.nytimes.com/interactive/2015/01/09/sports/the-da...

Try the "desynchronized" canvas attribute[1]. It should lead to a noticeable latency improvement on ChromeOS and Windows.

[1] https://developers.google.com/web/updates/2019/05/desynchron...

As a Chromium developer speaking based on my observations, we're also responsive to fixing bugs that affect a small percentage of sites. The difference is prioritization, and whether we'll merge fixes back to stable branches for a respin.

Chromium recently crossed a million bugs. And if you count Chromium and Blink together (they're in one repository for quite some time now), it's probably over a million commits too.

No, because Microsoft does things like this:

"For about eight days, some versions of Windows 10 quietly bundled a password manager that contained a critical vulnerability in its browser plug in, a researcher said Friday. The flaw was almost identical to one the same researcher disclosed in the same manager plugin 16 months ago that allowed websites to steal passwords." [1]

[1] https://arstechnica.com/information-technology/2017/12/micro...

Please use Google's "Password Alert" Chrome extension to protect your Google account. It will notify you if you accidentally enter your Google password on another website.

Chromium will continue using link.exe as the linker even after migrating to clang-cl. See the bottom of the email that's linked.

From what I gather, it's about GLX support in Xwayland. Most general purpose applications won't be affected* but games would be.

* The big exception is Chrome which uses GLX for accelerated rendering. The software fallback path uses a lot more CPU and won't support WebGL AFAIK.

I had a similar discussion with a colleague a few weeks ago. They were double counting latency in different pipeline stages when a delay in one stage causes high latency in the other stage.

My analysis would be something like this (assuming 60 fps): 1. Input latency - variable from hardware 2. Input event queuing - avg 8 ms (input event arrives in frame X but is handled in frame X+1) 3. Animation, game simulation, submitting GPU commands, other CPU work - 16.7 ms 4. GPU work - 16.7 ms 5. Display controller scanning out frame - 16.7 ms 6. Display panel latency - < 10 ms?

Steps 3 (specifically the submitting GPU commands part) and 4 can happen within one frame interval so you can be double buffered in that case. Otherwise you need triple buffering to maintain 60 fps. If you have a window compositor, then you need to account for when that latches and releases the buffer you submitted and if it performs copies or steals your buffer. This is the part that's especially murky. Games have it easy with fullscreen non compositing mode.

You know that post hoc ergo propter hoc is a logical fallacy, right?

Check out the Sublime Text plugin PlainNotes (and PlainTasks).

I work on Chromium and I test every VS Code version to see how it performs with the Chromium source code (except third_party). This is the first time I'm impressed. My observations:

1. Go to file is a little bit slower than Sublime Text but the extra features in VS Code make that tradeoff worthwhile. 2. The C/C++ extension enables go to definition/header without any extra configuration. 3. I like that it runs on top of Electron which is after all a fork of Chromium. 4. I haven't tried the debugger yet but I'm hopeful that will work fine too.

I'll keep playing around with it and maybe even switch from Sublime Text.

In Chrome you can press "Ctrl/Cmd + Shift + D" and bookmark all open tabs into a folder. Then you can right click on the folder later to open all those tabs.

This might be a side-effect of --isolate-extensions (out of process iframes for extensions) being turned on in M55.

https://groups.google.com/a/chromium.org/forum/#!msg/chromiu...

It's missing the Unix Haters Handbook.

http://web.mit.edu/~simsong/www/ugh.pdf

You can use FB messenger even after deactivating your FB account. But there are still things that can cause you to reactivate your account e.g. accessing two factor settings.

There are two modes for X11 under Crouton: GPU accelerated output (called "xorg" mode) and unaccelerated output to a chrome window (called "xiwi" mode). Both seem to work fine based on my limited testing with Gnome on Debian Sid.

Ah, yes the UI was upstreamed only recently. However it was possible to build Chromium on Android either as "content_shell" (minimalistic UI on top of Chromium) or as WebView.

I find the browser complaint funny because they've moved to Chrome which even has an open development model[1] (Android does not). Chrome is also used for the WebView implementation starting in KitKat[2] (made updateable via Play Store in Lollipop). All of this code is open-source and also openly developed (which means code review, bug tracker, mailing lists, design docs are public).

[1] https://news.ycombinator.com/item?id=12578134

[2] https://developer.chrome.com/multidevice/webview/overview

I think something like 3200 x 1800 (HP Chromebook 13) or 2560 x 1700 (Pixel) at 2x scale works better.

Gaming on Linux, maybe? A lot of games in my Steam library are Linux compatible.

Re: video decode acceleration, ChromeOS on Broadwell should support GPU accelerated h264/VP8 decode and hardware assisted h265/VP9 decode. (I might be completely misinformed about this though.) I'm not really concerned about the GPU performance with regard to video decode.

I recently decided not to purchase expensive laptops any more. It's cheaper to buy a good cheap laptop and a workstation than it is to buy a top of the line laptop.

I bought a Dell Chromebook 13 after trying one out for a few days. I'll be upgrading the SSD and installing Crouton (with Ubuntu/Debian) to run along side ChromeOS. The benefit of this over installing a Linux distro by itself is that ChromeOS has the right drivers for the hardware. As a result it can do certain things like hardware video decoding which are poorly supported on Linux.

Pros:

- Cheap (~550 USD with promotions)

- Core i3 + 8GB RAM (powerful enough for me)

- Upgradable SSD

- Excellent glass touchpad and keyboard

- Matte 13.3 inch 1080p IPS display

- 12+ hours battery life

- Good build quality / materials (carbon fiber + magnesium alloy)

- ChromeOS :-)

Cons:

- Max display brightness is under 300 nits (somewhat countered by matte display)

- Default resolution of 1080p is too high for such a small screen, a smaller scaled resolution (~720p) works better

- Lower spec integrated graphics (HD 5500 not Iris Pro)

- Lack of HiDPI screen

- Proprietary charger

- No USB-C, no display port (HDMI only), single USB 3.0 port (other port is USB 2.0 only)

I think you're underselling Google Contributor by not mentioning its killer feature: replacing banner ads with cat photos.

You don't really need a Google Apps account for this if you're using Google Domains as your registrar. You can choose to forward whatever email address you want directly via Google Domains.

https://support.google.com/domains/answer/3251241?hl=en

Of course it might involve manually fiddling with MX records if you're using a different registrar for your domain and forwarding (e.g. with Google Apps) might also be required.

I have this setup. Your login remains the same i.e. gmail. For receiving emails it acts more or less like a forwarding service without an extra inbox. When you reply to an email sent to the alias, it will choose that alias to send from so you won't accidentally send from your gmail address. Also in email headers you'll see a gmail message id but it won't reveal your gmail address AFAICT.

Both sync[1] and cast[2] are present in Chromium. If you're referring to the recent fiasco about cast not working in Chromium, that was a bug in M54. And guess what, it wasn't working in Chrome either!

I'd encourage you to read this document[3] detailing the differences between Chrome and Chromium instead of speculating.

[1] https://www.chromium.org/developers/design-documents/sync [2] https://codereview.chromium.org/2347503002 [3] https://chromium.googlesource.com/chromium/src/+/master/docs...

IMO Google is in a better position to deal with ffmpeg security updates than Debian is. Google is spending a lot of effort into fuzz testing ffmpeg[1] and other components of Chrome and also rolls out updates very quickly.

I'd expect the distro ffmpeg to not need as much updating if you're only using it for local media that you trust. But Chrome's ffmpeg has to decode media from untrusted sources so it's important that security bugs get fixed ASAP.

[1] https://security.googleblog.com/2014/01/ffmpeg-and-thousand-...

Ha! This is one of the reasons* Chrome ships with its own copy of ffmpeg which this fork decided was a bad thing.

* the other being security updates for ffmpeg

That's because it's not a Chromium bug. You should file feedback with the product you're using, most (all?) Google products have a way of doing this.

Why do you say that it's not easy to contribute to Chromium? Also the "last truly open-source" browser is hyperbolic given that Chromium is both open-source and is also developed in the open[1][2][3]. If anything over the past few years it has become more open-source as many components have been upstreamed (e.g. pdfium, android/ios stuff, etc.)

[1] Chromium bug tracker: https://bugs.chromium.org/p/chromium/issues/list [2] Chromium code reviews: https://codereview.chromium.org/ [3] Chromium development mailing lists: https://www.chromium.org/developers/technical-discussion-gro...