We'd like to create a video that shows a screencast of a Virtual Park demo we are putting together for the Firefox 4 launch and that also talks about the Mozilla Parks program. Some background on these can be found at: http://davidwboswell.wordpress.com/2010/09/09/firefox-4-and-a-virtual-park/ http://www.mozilla.org/parks/ I'll take a pass at creating a screencast, but it might also be fun to get me and maybe Daisuke and Chelsea on camera talking about how this effort ties in to Mozilla's mission and how we're raising money to protect parks around the world. BTW, if there is a better place to file video bugs feel free to move this bug.
Adding Cheng to bug. If we want a couple people on camera talking about this, Cheng would be a good choice for someone else in MV. Would still be fun to figure out how to get Daisuke and Chelsea in too :)
I was playing around with some ideas for a script for an intro to the screencast. Feel free to provide comments or suggestions: mozilla is a non profit with a mission to protect the internet. you can't feel or see the internet though, so it can be hard to think of it as a thing that might need to be protected. we've found that it helps to compare the need to protect the internet with the need to protect a special place in nature. that's were the mozilla parks idea came from -- plus it's a great fit with the community's history since parks have been used for the code names of firefox releases. so far mozilla has raised money for parks in madagascar and hawaii and for firefox 4 we're collecting donations on behalf of a huge park in brazil that contains an incredible amount of biodiversity. instead of just talking about this park, we thought it would be fun to let people build a virtual version of it by submitting their own photos, videos and tweets and having plants and animals start growing out of the page. we'll show you how it works.
Any update for this? Virtual park design is now fixed for release and it's time we can start to take screenshots, screencasts and videos I think. # As for screenshots, we'll prepare soon for press persons.
The site is running very slowly for me and is making it difficult to do a screencast. Maybe it's because of the large number of tweets showing for testing? I could try again when we reset things to bring in just the initial batch of tweets.
Unfortunately this demo site is heavy, especially with less than 3.0GHz CPU. What machine are you using and how about with this initial+few tweets case? http://ubu.mozilla.jp/tumucumaque/park/ Of course we can reset tweets but if it's already slow with this, I recommend to ask someone for faster machine temporary to take smoother screencast. Especially if you cannot see smooth transition when you click tweets. # of course we can prepare park with any set of tweets for you Let me share perf note. We cannot make the demo dramatically faster but I hope this can be some help for you: This demo become slow since: [a] whole the page (actually larger area than shown) is transformed Unfortunately CSS transform for large element is heavy. Cannot solve unless we change the basic idea of the demo, that is, to use transform and transitions for whole the contents. [b] there are quite a lot of nodes (tags) to show tweets. Gecko is not good at treating large number of elements. Fewer tweet is faster but we cannot feel largeness of the park with many tweets when we show only a few tweets. [c] need to load really many files both from this site and twitter Cache works until you reload or move to other page. I always preloaded images (zoom in/out and dragging around by hand) before I show this site to other person. Faster network is better of course. [d] just because of Firefox's bug (number of thread will continue increasing) You should restart firefox and open only this site. If we repeat loading the demo again and again, number of your firefox thread continue increasing. # this is happen not only with this site but not exactly sure how to repro tips: You can reduce resolution of the window to get faster.
(In reply to comment #5) > This demo become slow since: > [a] whole the page (actually larger area than shown) is transformed > Unfortunately CSS transform for large element is heavy. > Cannot solve unless we change the basic idea of the demo, that is, to use > transform and transitions for whole the contents. Are you using accelerated layers? See about:support. > [d] just because of Firefox's bug (number of thread will continue increasing) > You should restart firefox and open only this site. If we repeat loading the > demo again and again, number of your firefox thread continue increasing. > # this is happen not only with this site but not exactly sure how to repro If you close the window (without exiting Firefox), do the threads go away?
Re question in comment #5: * I'm using a MacBook Pro with a 2.4 GHz Intel Core 2 Duo processor and 4 GB ram and running 10.6.6 and the latest beta. Re question in comment #6: * In about:support I don't see anything about 'accelerated layers' or 'layers'. I do see something for 'accelerated': GPU Accelerated Windows1/1 OpenGL I'll try the tips mentioned above about making my window smaller and restarting Firefox with just this page showing and report back.
I tried with a smaller window and with restarting Firefox and just loading the park in the only tab and it helped a little, but not enough. Zooming in and out and expanding tweets takes a few seconds and there's a bit of a flicker. Dynamis, could you perhaps take a screencast on your machine and then I could use that for an English video and you could use that for a Japanese video?
Try it on Windows, we have faster graphics there. Also, how do I get access to the demo? http://ubu.mozilla.jp/tumucumaque/park/ needs auth.
(In reply to comment #9) > Also, how do I get access to the demo? http://ubu.mozilla.jp/tumucumaque/park/ > needs auth. Try http://virtualpark.allizom.org/ ?
OK, that feels reasonably fast for me on Windows 7 (on a fast laptop). I recommend making the video on Windows. For Mac, we'll need someone to profile who has GL enabled.
Component: www.mozilla.org → www.mozilla.com
It looks like we're just drawing a lot of transformed elements, no canvas involved. That should be reasonably fast unless we're doing a lot of invalidation and layout-level repainting. I presume the most important action to test for performance is panning around the window. BTW the thing with threads is probably the audio. Are we playing lots of audio elements or just one? And do the threads ever get cleaned up or do we leak permanently?
roc, thanks for looking into this and giving feedback. I don't have easy access to a Windows machine now. If Dynamis doesn't have a chance to make a screencast, I'll see what I can find later this week.
Looks like large amounts of time are being spent within JS, which is triggering reflow/invalidation. Around 30% of the total process time is here (and almost 50% of the time within __CFRunLoopRun). As far as painting goes, around 75% of time within PaintThebesLayers is drawing nsDisplayImage's (though there's only 4 of these). 20% of the total process time is spent within argb32_sample_argb32. Scaling images is killing us here. The remaining painting time is drawing nsDisplayBackgrounds (scaling images again), painting text and copying surfaces to the destination. A quick test of moving all images to have their own layer seems to improve performance a fair bit, still quite laggy scrolling around though.
That's without GL? What about with GL?
Or are we scaling images as we draw them into ThebesLayers? If so, what's causing the scaling? CSS transforms or something else?
Component: www.mozilla.com → www.mozilla.org
The following page might help answer some of the technical questions in recent comments: http://virtualpark.allizom.org/docs/tech/index.php.en
Thanks! That page says "CSS Transitions" in many places where it means "CSS Transforms". I guess the transforms in this case are not active so we won't be layerizing them.
That was with GL layers, yes. The 4 Image display items aren't wrapped within an nsDiplayTransform, so I assume its normal css width/height sizing being applied.
Are we repainting all the images as we pan? If so, why?
We still want to do a video but are putting this into phase 2 for a few weeks from now. It would be nice to optimize things in the meantime, so would it be possible to pull together some recommendations from previous comments about how we could have the Virtual Park run faster? A lot of the discussion was over my head...
It's reasonably fast on Windows 7. I'd like an answer to comment #20, maybe Timothy can help :-).
I didn't profile myself but I see the images Matt is talking about. They are inside a relatively positioned div (called background-canvas) and the top/left of this div are updated by panning. So that would explain why we have to redraw them.
OK. If the demo used CSS transforms instead of relative positioning it would probably be faster...
Parks program has been closed for now. Reopen if this project is started up again.
Status: NEW → RESOLVED
Last Resolved: 6 years ago
Resolution: --- → WORKSFORME
Component: www.mozilla.org → General
Product: Websites → www.mozilla.org
You need to log in before you can comment on or make changes to this bug.