eugenia_loli
Posts: 6
Joined: Tue Feb 12, 2019 6:11 am

Why is the Raspbian desktop experience so slow?

Wed Feb 13, 2019 8:05 am

I got my 3B+ two days ago, and while the machine in spiffy in background tasks, loading fast etc, the desktop experience is below par, particularly when it comes to accelerated graphics, e.g. video, html that has more javascript than usual, or basically, anything that requires a good graphics driver. I even set the graphics to 128 MB memory, but it's still slow. This is not meant as a jab at Raspberry specifically, since all the other SBCs out there are just as bad in their Linux desktop mode.

However, things are different when you run something like Android, or Libreelec. They seem to work faster, for example, their youtube video doesn't lag etc. Yes, I'm aware of the VLC optimizations on the latest Raspbian, but I don't have local videos, I care about Youtube, playing in-browser. I also care about the browser not lagging when I'm on facebook... normal stuff, that is.

What does it need to happen to fix the desktop experience performance? I'd be happy to see Chromium open without dragging its feet on almost every serious website out there, and having at least 720p full screen on youtube without dropping frames (right now, I can only get it to not drop 720p in window mode -- 1080p is terrible regardless). This is a clean installation btw, and if you watched this video, it is my experience too: https://www.youtube.com/watch?v=U5Y6XwFyU2s

So, what does it need to be done on Raspbian to make things faster? A more optimized driver? A newer kernel? Something else? What is missing from the overall picture that we could do better?

EDIT: Someone added information on that youtube video in the comments, and said that the Nano Pi M4 has just added full hardware acceleration on ffmpeg, browser (both fast web page rendering and video), opengl ES 20 support, and video player acceleration under X11. I checked it out, and indeed, the company's release notes clearly mention full hardware acceleration in that new version! Can we have the same on Raspbian?

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26876
Joined: Sat Jul 30, 2011 7:41 pm

Re: Why is the Raspbian desktop experience so slow?

Wed Feb 13, 2019 8:58 am

Your title is misrepresenting the issue, you are not talking about the desktop, you are talking about specific apps running on the desktop. The desktop itself is fine.

So...

An enormous amount of work has been and is still being done to accelerate Chromium for things like YouTube. Also ffmeg. Not sure how much of it has been released, quite a lot I think.

Trouble is, this stuff takes a long time, because amongst others things, Chromium is horrible to work with, and in many cases the HW acceleration provided by the SOC (it's over ten years old technically) doesn't match very well to the API required by the current software that wants it, this is especially true of Android. Its also not easy finding engineers with the right skills set to do this stuff. We have Eric Anholt working on the Mesa stuff, for multiple years now, which should help in some ways, and have other engineers working on things like Chromium and FFMEG.

It's a slow process. unfortunately.

And of course, with web browsers, memory can be an issue. They all appears to be memory hogs, so if you run out of memory they slow right down. Not much we can do about other people inefficient SW. Trying to limit the number of tabs used can help.

And also, don't forget, your Pi cost $35. It's not going to perform as well as a $500 desktop or laptop.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

feelslikeautumn
Posts: 315
Joined: Wed Aug 09, 2017 9:51 pm

Re: Why is the Raspbian desktop experience so slow?

Wed Feb 13, 2019 9:11 am

I was going to post a question about chromium. This is a good a place as any.

What communication has gone on between pi towers and the chromium Devs with regard to v4l2 media codec acceleration? Is there a mailing list thread I can read? Is there a bug report? I couldn't find either.

I posted a bug with chromium patches on Ubuntu's launchpad https://bugs.launchpad.net/ubuntu/+sour ... ug/1799686 . I need an upstream bug to link to.

feelslikeautumn
Posts: 315
Joined: Wed Aug 09, 2017 9:51 pm

Re: Why is the Raspbian desktop experience so slow?

Thu Feb 14, 2019 8:21 pm

No response. Do I take it then that no work has been done on chromium itself with regards to v4l2 codecs?

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26876
Joined: Sat Jul 30, 2011 7:41 pm

Re: Why is the Raspbian desktop experience so slow?

Thu Feb 14, 2019 9:39 pm

feelslikeautumn wrote:
Thu Feb 14, 2019 8:21 pm
No response. Do I take it then that no work has been done on chromium itself with regards to v4l2 codecs?
No response != no work. Hadn't even seen your post.

We have a contractor who has been working on Chromium multimedia acceleration for about a year, including software H265 decode, he is currently working on ffMPEG acceleration IIRC. We also have a full time engineer who has been working on V4L2 improvement for over a year who has been working with the contractor. You can follow the github repo comits to find out what work has been done.

I have no idea whether they talk to the Chromium devs or not.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

eugenia_loli
Posts: 6
Joined: Tue Feb 12, 2019 6:11 am

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 12:57 am

Hmm, a full year of work and this contractor hasn't delivered anything yet? Honestly, this is something your Foundation should look into. :-/
As time goes by, web pages become more and more heavier with all that javascript. This is a project that can't wait at this point, I'm afraid.

fruitoftheloom
Posts: 23911
Joined: Tue Mar 25, 2014 12:40 pm
Location: Delightful Dorset

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 2:37 am

eugenia_loli wrote:
Fri Feb 15, 2019 12:57 am
Hmm, a full year of work and this contractor hasn't delivered anything yet? Honestly, this is something your Foundation should look into. :-/
As time goes by, web pages become more and more heavier with all that javascript. This is a project that can't wait at this point, I'm afraid.

Try a different variant of Chromium Browser such as:

https://vivaldi.com/download/
Rather than negativity think outside the box !
RPi 4B 4GB (SSD Boot) RaspiOS64 ARM64
Asus ChromeBox 3 Celeron is my other computer...

User avatar
Greg Erskine
Posts: 153
Joined: Sat Sep 15, 2012 4:20 am

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 4:55 am

eugenia_loli wrote:
Fri Feb 15, 2019 12:57 am
Hmm, a full year of work and this contractor hasn't delivered anything yet? Honestly, this is something your Foundation should look into. :-/
As time goes by, web pages become more and more heavier with all that javascript. This is a project that can't wait at this point, I'm afraid.
Sounds like you picked the wrong hardware for your project. :o

With this experience you should be able to find the right hardware very quickly. :mrgreen:
* Raspberry Pi is a trademark of the Raspberry Pi Foundation

eugenia_loli
Posts: 6
Joined: Tue Feb 12, 2019 6:11 am

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 9:03 am

I'm talking about the Raspberry project, not any of my projects. The web gets more demanding with each passing day, so for the Pi to be relevant outside of purely embedded system solutions, then the hardware acceleration issue must be addressed. It should have been addressed years ago, actually.

feelslikeautumn
Posts: 315
Joined: Wed Aug 09, 2017 9:51 pm

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 9:11 am

Where is the GitHub repo for chromium? It's not here https://github.com/raspberrypi-ui/chromium_patches

6by9 says the intention is to upstream patches (https://github.com/raspberrypi/linux/pull/2755 ). This is great, but surely a bit of a shout-out on a mailing list or bug report would of been a good idea first to guide the direction of development? If nothing else to ask if somebody has already done patches to stop duplication of work?

Which of course they have. There are youtube videos of chromium using v4l2 decode under Linux on arm. I've already linked some patches on my ubuntu bug report. Endless OS use v4l2 decode on their chromium https://github.com/endlessm/chromium-browser

I'm not sure a lot can be done about the javascript bloat. It's down to individual websites to cut this down. The worst offenders are the big tech companies. Facebook, YouTube, Outlook. Having said that, my android tablet handles these websites fine and it is certainly not top of the line hardware.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26876
Joined: Sat Jul 30, 2011 7:41 pm

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 9:25 am

eugenia_loli wrote:
Fri Feb 15, 2019 12:57 am
Hmm, a full year of work and this contractor hasn't delivered anything yet? Honestly, this is something your Foundation should look into. :-/
As time goes by, web pages become more and more heavier with all that javascript. This is a project that can't wait at this point, I'm afraid.
Well, not sure he works full time, but in that time he has produced HW acceleration for Chromium, optimised the ARM NEON code for H265 decode, to get 720p in software, implemented FFMPEG HW acceleration, and some other stuff.

None of which you did, and yet you had access to all that open source code. So, rather than slagging off our development process, on this EXTREMELY DIFFICULT work, why not put some effort in and instead of complaining, contribute?
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26876
Joined: Sat Jul 30, 2011 7:41 pm

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 9:31 am

eugenia_loli wrote:
Fri Feb 15, 2019 9:03 am
I'm talking about the Raspberry project, not any of my projects. The web gets more demanding with each passing day, so for the Pi to be relevant outside of purely embedded system solutions, then the hardware acceleration issue must be addressed. It should have been addressed years ago, actually.
Not everyone needs fast browers - stop conflating your demands with the rest of the market. I do hark on about it, but you don't sell 25M devices unless the market likes them.

As for addressing the issue of HW acceleration, we've been working on speeding things up for YEARS. The main problem with browsers nowadays isn't the graphics acceleration, but the profligate use of memory by the browsers, which makes use on a limited memory system like the Pi a major bottleneck. And fixing that, in my opinion, is down to the Chromium devs for making their software such a greedy pile of excrement.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26876
Joined: Sat Jul 30, 2011 7:41 pm

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 9:37 am

feelslikeautumn wrote:
Fri Feb 15, 2019 9:11 am
Where is the GitHub repo for chromium? It's not here https://github.com/raspberrypi-ui/chromium_patches

6by9 says the intention is to upstream patches (https://github.com/raspberrypi/linux/pull/2755 ). This is great, but surely a bit of a shout-out on a mailing list or bug report would of been a good idea first to guide the direction of development? If nothing else to ask if somebody has already done patches to stop duplication of work?

Which of course they have. There are youtube videos of chromium using v4l2 decode under Linux on arm. I've already linked some patches on my ubuntu bug report. Endless OS use v4l2 decode on their chromium https://github.com/endlessm/chromium-browser

I'm not sure a lot can be done about the javascript bloat. It's down to individual websites to cut this down. The worst offenders are the big tech companies. Facebook, YouTube, Outlook. Having said that, my android tablet handles these websites fine and it is certainly not top of the line hardware.
How much memory does your tablet have?

With regard to github stuff, have asked 6by9 to comment on current progress.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

feelslikeautumn
Posts: 315
Joined: Wed Aug 09, 2017 9:51 pm

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 9:46 am

jamesh wrote:
Fri Feb 15, 2019 9:25 am
rather than slagging off our development process, on this EXTREMELY DIFFICULT work
in my opinion, is down to the Chromium devs for making their software such a greedy pile of excrement
?

Tablet has 2GB. Yep twice as much, but it is not maxed out.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9325
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 10:46 am

V4L2 M2M codec drivers are merged in our rpi-4.19.y tree - https://github.com/raspberrypi/linux/tr ... 2835-codec. Upstreaming them is ongoing. They work fine with ffmpeg and GStreamer 1.14 (and I think.
No, I'm not backporting to 4.14.
What would the point of a shout on the linux-media mailing list be prior to work being undertaken? The API for codecs is fairly well defined with documentation being finalised, several other implementations to use as examples, and both FFmpeg and GStreamer supporting them.

Please note that VAAPI is a totally different API, originally from Intel - https://01.org/vaapi. I know there is a V4L2 stateless codec API wrapper for VAAPI, but I'm not aware of one for the stateful codec API. I haven't come across one for the V4L2 stateful API (which is what we implement).

Chromium does have support for V4L2 M2M codecs - https://github.com/chromium/chromium/tr ... a/gpu/v4l2.
The big issue discovered is that it is behind a BIG config switch in Chromium to enable their Ozone abstraction layer. Whilst this claims to support ChromeOS, embedded, and Linux desktop (X11 or Wayland), our experience is that the X11 code paths are fairly badly broken, failing to even get the browser up, let alone starting to try out video codecs.
The V4L2 drivers also require some tweaks as they don't build against standard mainline kernel headers. That may be sorted now that the V4L2 stateless codec API support has been merged into mainline (I think it made Linux 5.0).
Basically if we were to use this path of Ozone on X11 I suspect we'd be on our own, which is a huge overhead.

Your link to the endlessm fork of Chromium is interesting. It appears to have fixed up some of the issues I'd hit. I'd need to investigate whether they have actually enabled V4L2 codecs without Ozone. If they have, then it'd be interesting to know what path they use for rendering it.

The main problem is that X11 sucks, and it's mainly about getting the pixels around in memory.
You can't use hardware overlays because (a) X11 doesn't support it, and (b) if you then drag a window over the top of your video it becomes a mess as to how to compose that. It therefore has the choice of either using EGL or software for composition.
- EGL is coming with Eric's drivers, but even then the 3D hardware is not designed to work on YUV data, and generally requires the input data to be in a tiled format so that's another conversion. A further issue is that of updating Mesa (the userspace side of the KMS and 3D driver) - the number of dependencies is pretty large. Raspbian is based on Debian and stability is the key. Bumping all dependencies to get a later Mesa to build is just too large a change to swallow comfortably. The bump to Buster updates all of these packages, and will hopefully make a lot more of Eric's work available.
- Resizing in software is painfully expensive. Our current Chromium patches use hardware blocks to resize the image to exactly the size that X wants it, and format convert to RGBA32. The ARM then only has to do a blit of the image into the frame buffer. Even that operation is fairly memory bandwidth intensive at 1080P60 (~4Gbit/s of data for that final blit alone).

So we know that there are some areas that need attention, and they are getting it as resource allows. If you were wishing to contribute then feel free - download the source from the Raspbian repos and hack away.

Note: your tablet runs Android, so no X11 in sight, and therefore it can use hardware overlays to display the video. The Pi hardware can do that very easily (see omxplayer), but it is getting X to play nicely that is the issue in Linux. On your tablet you don't have the issue of being able to drag another tab/window partially over the top of your video overlay, and actually SurfaceFlinger is fairly efficient for displaying stuff.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26876
Joined: Sat Jul 30, 2011 7:41 pm

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 10:53 am

feelslikeautumn wrote:
Fri Feb 15, 2019 9:46 am
jamesh wrote:
Fri Feb 15, 2019 9:25 am
rather than slagging off our development process, on this EXTREMELY DIFFICULT work
in my opinion, is down to the Chromium devs for making their software such a greedy pile of excrement
?

Tablet has 2GB. Yep twice as much, but it is not maxed out.
Point? Our development process, and Chromium's memory consumption appear to be different things. We are spending time and money trying to improve things (see previous post), whilst fighting Chromiums ever expanding memory requirements. I've never understood why it takes 400MB of RAM to open a single webpage, but then I grew up when 32KB was a lot of memory.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

feelslikeautumn
Posts: 315
Joined: Wed Aug 09, 2017 9:51 pm

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 1:51 pm

The point is you've always been oversensitive to criticism, often lashing out at people who challenge something. Yet you are happy to criticise other peoples work, often in language which is far worse than is expressed against the pi/Raspbian. Chromium uses a lot of memory, but so does firefox and every other browser. I have no idea how a browser renders a javascript heavy web page, but since every browser has a similar memory consumption, it seems high memory use is necessary or hard to avoid and is not due to 'excrement' chromium code.

Anyway we digress, and I don't want this thread locked....

This thread seems to be mixing up javascript and video acceleration. My comments about my android tablet referred to javascript heavy webpages, which for me is a bigger problem than video acceleration. The slowness on the pi doesn't 'feel' like it is due to excessive memory swapping, but I have nothing to back that up and I'm probably wrong. It is presumably not due to the use of X11.

Back to video acceleration. As I said in my first post on here I need an upstream chromium bug to link to so that it can be tracked on launchpad. Since I'm not working on this I'm reluctant to create a bug report since it is just going to sit there with nothing happening. That is why I asked if one had been created as I couldn't find it or a mailing list thread. If groups interested in accelerating video decode on arm want this to progress, then creating a bug report seems a pretty basic step to me so this can be worked on together. It also means upstream are aware of patches and hopefully future changes will take account of patches people are applying even if they are not formally merged. Can somebody working on this please create a chromium bug so progress can be shared?

Btw I'd be happy to run chromium under wayland. I've used kwin with wayland quite a lot on the pi.

A way around old versions of mesa is to package things like chromium using flatpack or snaps instead of debs. This would allow them to be easily installed outside of Raspbian.

jahboater
Posts: 5958
Joined: Wed Feb 04, 2015 6:38 pm
Location: West Dorset

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 3:10 pm

feelslikeautumn wrote:
Fri Feb 15, 2019 1:51 pm
The slowness on the pi doesn't 'feel' like it is due to excessive memory swapping, but I have nothing to back that up and I'm probably wrong.
Perhaps run "vmstat 10" while doing some web browsing. Also "free -h" may help.

By default Raspbian only has 100MB of swap space.

6by9
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 9325
Joined: Wed Dec 04, 2013 11:27 am
Location: ZZ9 Plural Z Alpha, aka just outside Cambridge.

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 3:10 pm

feelslikeautumn wrote:
Fri Feb 15, 2019 1:51 pm
Back to video acceleration. As I said in my first post on here I need an upstream chromium bug to link to so that it can be tracked on launchpad. Since I'm not working on this I'm reluctant to create a bug report since it is just going to sit there with nothing happening. That is why I asked if one had been created as I couldn't find it or a mailing list thread.
No. I had looked at the ozone-devel mailing list at https://groups.google.com/a/chromium.or ... /ozone-dev, and based on the lack of useful activity concluded that generally it wasn't being supported (ChromeOS aside, which is likely to all be internal to Google).
Now if others are using the V4L2 stuff outside of Ozone then that is a different kettle of fish, and I'm very curious as to the render path.

I've just done a search on the main chromium bugtracker and hit https://bugs.chromium.org/p/chromium/is ... ?id=849585
That dump from ui::InputMethodAuraLinux::InputMethodAuraLinux() looks to be exactly the one I hit. I'll try out the linked commit.
edit: I'd missed that the review had been abandoned with the comment "As we discussed on the CL, we need the implementation for LinuxInputMethodContextFactory instead of adding short-term hacks.". Back to square one.

The search also showed up https://bugs.chromium.org/p/chromium/is ... ?id=789065 - that seems to sum up the priority assigned to X11 and Ozone.
feelslikeautumn wrote: If groups interested in accelerating video decode on arm want this to progress, then creating a bug report seems a pretty basic step to me so this can be worked on together. It also means upstream are aware of patches and hopefully future changes will take account of patches people are applying even if they are not formally merged. Can somebody working on this please create a chromium bug so progress can be shared?
Why raise it on launchpad for Ubuntu and then complain about Raspbian? :?

From sitting at the other side of issue trackers, triaging issues with insufficient details is a right pain and expends resources that can be better used elsewhere. I therefore won't create an issue unless I actually understand it to at least a basic level and can provide full details to reproduce. As I couldn't get to the stage of running Ozone on X11 I can't therefore make comment on the V4L2 support within it. From that position there is no point in creating a bug for the video decode path, and we were looking at alternate solutions instead.

On the Pi the actual decode is a relatively small part of the issue of getting the data onto the screen. If you're not doing the whole pipe with zero copy dmabuf support then there is little point in doing any of it.
feelslikeautumn wrote:Btw I'd be happy to run chromium under wayland. I've used kwin with wayland quite a lot on the pi.
We're not supporting Wayland these days, but feel free to go and build it for youself. Be aware that a cross compiled build using our build server (lots of RAM and cores) takes about 6 hours to build Chromium.
feelslikeautumn wrote:A way around old versions of mesa is to package things like chromium using flatpack or snaps instead of debs. This would allow them to be easily installed outside of Raspbian.
If you want cutting edge then don't use Debian or derivatives. Sorry, I'm not the one to discuss alternative packaging schemes with.
Software Engineer at Raspberry Pi Trading. Views expressed are still personal views.
I'm not interested in doing contracts for bespoke functionality - please don't ask.

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26876
Joined: Sat Jul 30, 2011 7:41 pm

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 3:19 pm

feelslikeautumn wrote:
Fri Feb 15, 2019 1:51 pm
The point is you've always been oversensitive to criticism, often lashing out at people who challenge something. Yet you are happy to criticise other peoples work, often in language which is far worse than is expressed against the pi/Raspbian. Chromium uses a lot of memory, but so does firefox and every other browser. I have no idea how a browser renders a javascript heavy web page, but since every browser has a similar memory consumption, it seems high memory use is necessary or hard to avoid and is not due to 'excrement' chromium code.

Anyway we digress, and I don't want this thread locked....

This thread seems to be mixing up javascript and video acceleration. My comments about my android tablet referred to javascript heavy webpages, which for me is a bigger problem than video acceleration. The slowness on the pi doesn't 'feel' like it is due to excessive memory swapping, but I have nothing to back that up and I'm probably wrong. It is presumably not due to the use of X11.

Back to video acceleration. As I said in my first post on here I need an upstream chromium bug to link to so that it can be tracked on launchpad. Since I'm not working on this I'm reluctant to create a bug report since it is just going to sit there with nothing happening. That is why I asked if one had been created as I couldn't find it or a mailing list thread. If groups interested in accelerating video decode on arm want this to progress, then creating a bug report seems a pretty basic step to me so this can be worked on together. It also means upstream are aware of patches and hopefully future changes will take account of patches people are applying even if they are not formally merged. Can somebody working on this please create a chromium bug so progress can be shared?

Btw I'd be happy to run chromium under wayland. I've used kwin with wayland quite a lot on the pi.

A way around old versions of mesa is to package things like chromium using flatpack or snaps instead of debs. This would allow them to be easily installed outside of Raspbian.
Critisism of Pi development process from people who don't know what we've been doing or what we have achieved. Not OK. Critism of Chromium's outrageous memory requirements, OK.

Simple. One is a critism from no knowlege, one is a critisism from knowledge. Because, let's be honest, Chromioum's memory requriements are huge.

With regard to slowness, please read 6by9's post above. That is quite a good explanation of where problems lie.

And what actually is the bug you want tracked? Its unclear from anything I've read above. Is it just using V4L2 to accelerate Chromium? If so, it's already being looked in to. Again, see the 6by9 post above.

Many many browser slowness reports are simply down to memory. Open more than two or three tabs and the memory requirements shoot through the roof. Even a single tab can be very heavy on memory.

I have no idea whether the engineers working on this would be willing to cavort with devs outside the office. We do this in some areas, not others. On the whole, our development process is opaque as we need to stop any new product information leaking out. Whether that is relevent here I don't know. Probably not. We tend to keep a close eye on mainstream development, for obvious reasons, but third parties making alterations would be impossible to track, so I suspect people would need to approach us to tell us what they are doing, rather than us trawling around seeing what others are doing. That would be horribly time consuming.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

eugenia_loli
Posts: 6
Joined: Tue Feb 12, 2019 6:11 am

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 9:33 pm

>Critisism of Pi development process from people who don't know what we've been doing or what we have achieved.
As a customer of the Pi I don't need to know the ins and outs of what you've done (although I do appreciate your work). What I do see though is the result. The result is that the Pi as a browsing experience is very under par (and your benchmark for that should be Youtube's 720p full screen, in-browser, playing back smoothly -- if not 1080p).

I do agree with you though, X11 does suck. Maybe you should look at Wayland. If its architecture does what you need better than X11 can, then use that. Sure, that would mean more RAM (which is way overdue in Raspberry's product lineup btw), and more engineers to deal with the various driver/library ports to Wayland. Sure, that means more money are needed to get more engineers. I personally wouldn't mind an additional tax to buy a Pi going forward, as long as the software works as you would expect in this day and age. I'm totally fine with paying more.

You could even charge $10 to buy the .deb package that contains all the optimizations, since it would cost you good money to develop these. I mean, look at Panasonic. They charge $100 to buy their VLOG 10bit format for some of their cameras. Many people do pay up for it, because it has value for them. For those who it doesn't have any value (e.g. the people who mostly care about photography and not video), they don't buy it, they stay with 8-bit non-logarithmic video. Not as ideal, but it still works ok-enough for them.

My point is, the Pi has outgrew its original "embedded systems/tinkering-only" outlook. It's now out there, embraced by normal users who can't write a single line of code. Because of that, more care is needed on the software side of things by Raspberry itself. Basically, the burden falls on the Foundation now, kind of like being a victim of its own success. It's both a good and a bad thing, depending on how you see it. I see it as a good thing, an evolution and a precursor of things to come. :-)

jamesh
Raspberry Pi Engineer & Forum Moderator
Raspberry Pi Engineer & Forum Moderator
Posts: 26876
Joined: Sat Jul 30, 2011 7:41 pm

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 10:18 pm

eugenia_loli wrote:
Fri Feb 15, 2019 9:33 pm
>Critisism of Pi development process from people who don't know what we've been doing or what we have achieved.
As a customer of the Pi I don't need to know the ins and outs of what you've done (although I do appreciate your work). What I do see though is the result. The result is that the Pi as a browsing experience is very under par (and your benchmark for that should be Youtube's 720p full screen, in-browser, playing back smoothly -- if not 1080p).

I do agree with you though, X11 does suck. Maybe you should look at Wayland. If its architecture does what you need better than X11 can, then use that. Sure, that would mean more RAM (which is way overdue in Raspberry's product lineup btw), and more engineers to deal with the various driver/library ports to Wayland. Sure, that means more money are needed to get more engineers. I personally wouldn't mind an additional tax to buy a Pi going forward, as long as the software works as you would expect in this day and age. I'm totally fine with paying more.

You could even charge $10 to buy the .deb package that contains all the optimizations, since it would cost you good money to develop these. I mean, look at Panasonic. They charge $100 to buy their VLOG 10bit format for some of their cameras. Many people do pay up for it, because it has value for them. For those who it doesn't have any value (e.g. the people who mostly care about photography and not video), they don't buy it, they stay with 8-bit non-logarithmic video. Not as ideal, but it still works ok-enough for them.

My point is, the Pi has outgrew its original "embedded systems/tinkering-only" outlook. It's now out there, embraced by normal users who can't write a single line of code. Because of that, more care is needed on the software side of things by Raspberry itself. Basically, the burden falls on the Foundation now, kind of like being a victim of its own success. It's both a good and a bad thing, depending on how you see it. I see it as a good thing, an evolution and a precursor of things to come. :-)
Actually, the burden is on Trading, not the Foundation. However, we have limited resource with only 8 or so full time SW engineers, and TBH most of use have more important things to work on. Yes, MORE IMPORTANT. So work gets done where it can be done, as outlined in the previous posts.

Buying in the 'work' doesn't work, because we are the people with the expertise. We contract in experts (as stated above) for specifics where we don't have the knowledge.

We looked at Wayland a few years ago, and threw some money at it. Didn't work out. About £100k or so IIRC. Probably more.

The Pi outgrew embedded tinkering about 20M devices ago. We sells millions of devices a year, to people who don't need browsers.

As for "more care", that's just insulting.
Principal Software Engineer at Raspberry Pi (Trading) Ltd.
Contrary to popular belief, humorous signatures are allowed.
I've been saying "Mucho" to my Spanish friend a lot more lately. It means a lot to him.

ejolson
Posts: 5629
Joined: Tue Mar 18, 2014 11:47 am

Re: Why is the Raspbian desktop experience so slow?

Fri Feb 15, 2019 11:17 pm

eugenia_loli wrote:
Fri Feb 15, 2019 9:33 pm
>Critisism of Pi development process from people who don't know what we've been doing or what we have achieved.
As a customer of the Pi I don't need to know the ins and outs of what you've done (although I do appreciate your work). What I do see though is the result. The result is that the Pi as a browsing experience is very under par (and your benchmark for that should be Youtube's 720p full screen, in-browser, playing back smoothly -- if not 1080p).
Welcome to the forum. I remember your posts from the HV20 community. It is good to see how your health has returned. Fantastic!

In regards to buying software, I believe there is a hardware accelerated MPEG2 codec for the Pi. Other than that, most everything is provided under a free software license.

Even though the software is free, I don't think that has significantly impacted how much time and money was and continues to be spent optimising the compilers, libraries and Linux kernel for the ARM architecture. Although the return on investment is mostly enjoyed by owners of Android phones, GNU/Linux on Raspberry Pi would not have been possible without corporate support of free software.

Many open source projects will gladly accept small financial donations; however, it is legally difficult to create a $10 patch set that makes GNU-licensed software run faster on Pi hardware without also providing the same patch set for free. Therefore, it is up to each individual whether they want to send any particular developer their spare change or not.

It is surprising but well-known how poorly web browsers function on the Raspberry Pi. Most of this can be attributed to having only 1GB RAM. At the same time, playback of YouTube through a web browser should be possible. I'm surprised Google hasn't created a YouTube player specifically for Raspberry Pi users as an easy way to deliver advertising.

My solution has been to avoid web browsers on Raspberry Pi. This saves time and watching YouTube is more comfortable on my phone anyway. Another approach is to use youtube-dl to retrieve a compatible format and then watch the video in an optimised stand-alone player.

In some sense the Raspberry Pi is too powerful. The reason I say this is because people keep trying to use them to replace desktop computers. However, if your goal is to learn enough Python scripting to blink an LED light on and off and then measure the wind and humidity, the Pi is just right.

code_exec
Posts: 273
Joined: Sun Sep 30, 2018 12:25 pm

Re: Why is the Raspbian desktop experience so slow?

Sat Feb 16, 2019 10:59 am

It doesn't matter if your desktop environment takes up 1MB of RAM or 700MB. Resource-heavy apps such as Chromium and Firefox are still going to slow down/freeze the Pi if you do too much in them.
Ubuntu 18.04 LTS desktop images for the Raspberry Pi 3.

https://github.com/CodeExecution/Ubuntu-ARM64-RPi

LTolledo
Posts: 3813
Joined: Sat Mar 17, 2018 7:29 am
Location: Anime Heartland

Re: Why is the Raspbian desktop experience so slow?

Sat Feb 16, 2019 1:57 pm

Hmmm... quiet demanding from somebody using free software.... from somebody not heavily investing financially in the development of the software. and hardware.....

There are other system/boards that might suite your requirements... better have a look at those.....
"Don't come to me with 'issues' for I don't know how to deal with those
Come to me with 'problems' and I'll help you find solutions"

Some people be like:
"Help me! Am drowning! But dont you dare touch me nor come near me!"

Return to “Raspberry Pi OS”