Page change in presentation takes a few seconds

92 kali dilihat
Langsung ke pesan pertama yang belum dibaca

Daniel Schröter

belum dibaca,
6 Jul 2019, 09.08.2406/07/19
kepadaBigBlueButton-dev
Hello,

thanks for providing bbb! :-D

We upgraded to 2.2. With html5 presentation a page change takes (on pages with a lot of text) a few (~2) seconds. During change a white page appears.

I tried it also on
and it's the same problem. If I take a look to the Devtools of chrome it shows 2.47s for a page change. 1.98s for content download (on a 50 MBit/s internet link).

zeit-fuer-neue-seite.png



I've noticed that if I change the same page a second time it's faster. It seems to be cached.

Does it help to prefetch the next page? Maybe via rel="preload"? (I'm not an html expert)

Thanks in advanced!

Bye

Chad Pilkey

belum dibaca,
7 Jul 2019, 00.21.2707/07/19
kepadaBigBlueButton-dev
In the Flash client we preloaded 5 slides, but the way we did it isn't possible in the HTML5 client. It's something we want to do again if we have a good way to do it. Two seconds to download the slide is very long time though. How big is the slide that it's downloading?

Once the browser has downloaded the slide once it will be cached by the browser and the next requests just return the local version.

Daniel Schröter

belum dibaca,
7 Jul 2019, 05.52.5307/07/19
kepadaBigBlueButton-dev
Am Sonntag, 7. Juli 2019 06:21:27 UTC+2 schrieb Chad Pilkey:
In the Flash client we preloaded 5 slides, but the way we did it isn't possible in the HTML5 client.

Thanks for this information. That explains the difference.


Two seconds to download the slide is very long time though. How big is the slide that it's downloading?

IMHO it doesn't depend on the size of the slide. It depends more on the amount of content.
I used
Page 3 with the ToC is great for a test.

I hope you are going to solve this in the future.
Should it not be enough to add a
<link rel="preload" href=$next-slide>
in every slide?

Bye


Chad Pilkey

belum dibaca,
8 Jul 2019, 15.07.5208/07/19
kepadaBigBlueButton-dev
The issue is the size of the slide, but it's the size of the converted slide so it's hard to see. The source PDF gave a very good indication of why this is happening. I've never compared the two clients like this before, but it turns out the difference is quite large when there's a slide with a lot of text. The SWF for the Flash client is on the left and the SVG for the HTML5 client is on the right. There's a very large difference between the two. Another interesting thing is that whole source PDF is only 285 kB. Page 3 converts into an SVG that is complex due to the way that the converter is drawing the fonts. I wouldn't be surprised if your browser is having difficulties rendering the slide and that's why the download takes so long. That slide has more than 11K SVG nodes which is a lot.


Also, the preloading like that likely wouldn't work. That works for static links, but the slides aren't links. There are complicating factors with how the code is structured and how the data is processed in the client.

Daniel Schröter

belum dibaca,
14 Jul 2019, 14.23.4314/07/19
kepadaBigBlueButton-dev
Thanks for the comparison.
My browser has no difficult to render the page. Just the downloadtime is the problem.

Hopefully someone can optimize this in the future.

Bye

jossef

belum dibaca,
15 Jul 2019, 03.33.1015/07/19
kepadaBigBlueButton-dev
Hi Chad.
Can I configure the width, and complexity, of the converted SVG slide ?
Such as for PNG or SWF in  bigbluebutton.properties  ( png Slide Width = 1200   )   
I would reduce slide width to 800 so that a smaller file will be created when images are uploaded, or when there are images within the vector information.

Regards
Jossef.




בתאריך יום שבת, 6 ביולי 2019 בשעה 16:08:24 UTC+3, מאת Daniel Schröter:

Chad Pilkey

belum dibaca,
15 Jul 2019, 11.46.1715/07/19
kepadaBigBlueButton-dev
Jossef,

The size of images on the slide shouldn't factor in. The image will be the same between the source and the SVG. The file size issues come in from the text on slides because often the text spacing or fonts can't be translated to SVG and we're left with each character individual wrapped in XML-like tags. Sometimes as in Daniel's case, the characters are split into parts and each part is wrapped. The extra tags are what causes the large file size.

I think the fix would be to convert to SVG and then check the file size and if it's outside a certain threshold then we convert to PNG and use that instead.

jossef

belum dibaca,
15 Jul 2019, 15.28.5015/07/19
kepadaBigBlueButton-dev
keeping minimum slide size was Always important.
i think this same fix was implemented for SWF , 
and the Configuration in  bigbluebutton.properties :
placementsThreshold=800
imageTagThreshold=800
defineTextThreshold=2000






בתאריך יום שבת, 6 ביולי 2019 בשעה 16:08:24 UTC+3, מאת Daniel Schröter:
Hello,
Balas ke semua
Balas ke penulis
Teruskan
0 pesan baru