Hi Benjamin! Thanks for your helpful reply and sorry for my delayed response. In the mean time, i got more findings (please read inline, below).
Benjamin Otte wrote: > The short version is that user input > redraws from user input > > advancing the flash file > redraws from advancing. Unfortunately, if > advancing takes longer than real time, no redraws ever happen. In this context: with "normal low" priority, the player does 50+ frames per seconds (entering swfmoz_player_redraw). So i'm wondering why swfdec never gets into idle for redraw - maybe there is something wrong with the timed signaling for redraw on ARM? Is it possible to reduce the number of calls to swfmoz_player_redraw? > Interesting - I wasn't aware that any masking is going on in the > Youtube player. This is likely gonna cause you problems on non-Youtube > files as you disabled masks, but I guess you know that. Right, in fact, for some videos, you may temporarily see some tearing when masking is disabled. A funny thing is that the masks are all zeros, most of the time, so the appropriate masking operation has *no* effect at all! During my first experiments, i added a simple function in libpixman that checks if a mask is non-zero before applying the operation (and skipping the operation, otherwise) - this got me a few FPS, but because the masking is mostly useless, i disabled it altogether for now. The idea is to have hw-accelerated functions, later on so that even the bogus masking operations could be applied without performance loss. However, i'm wondering if those empty masking operations are a bug in swfdec or if those are truly part of the flash script supplied by youtube (maybe as a result of lax programming). If it's the later one, then i guess the PCs of millions of youtube users are burning more energy than actually necessary for the job. Maybe a couple of nuclear power plant could be saved :-) (more investigation is needed). > You could also try removing all the debugging stuff by exporting > CFLAGS="-DG_DISABLE_CHECKS -DG_DISABLE_ASSERT -DG_DISABLE_CAST_CHECKS > -DSWFDEC_DISABLE_DEBUG" Thanks for the hint - that got me a couple of FPS, but there is still plenty of time spent in libglib and libgobject because of run-time time-checking. I guess i would need to re-compile other libraries with those options to reduce the overhead. > But yeah, the script engine is known to be slow as we never optimized > our code for speed, but correctness and easy debugging and refactoring > whenever we figured out it's not correct. So we're missing all the > cool optimizations from Mozilla or Webkit. The flash player itself takes only 10% of the CPU cycles for me - that's not too bad, i guess. Maybe it would be a good idea to figure out the most over-head causing external functions and replace them by some optimized internal version (like the i420 to rgb conversion) Another finding: In file swfdec_renderer.c the function swfdec_renderer_do_create_for_data(), doesn't directly return the newly created surface, but converts it using swfdec_renderer_create_similar(). I understand this is necessary for some caching. However, the creation of the similar surface burns a lot of CPU cycles, so i decided to just return the pointer to the generated surface, instead: // return swfdec_renderer_create_similar (renderer, surface); return surface; Another side effect of this is that pixman then somehow magically doesn't need to do the rgb888-to-rgb555 color conversion and the rgb555-to-rgb555 strech blit in two steps. Instead, a combined rgb888-to-rgb555 strech blit color conversion is done (that addressed with a hand-optimized version). So these two things also got me a couple of FPS. BTW.: is it possible to disable the caching? I have the impression that this is the root cause for the overhead (but that's pure speculation at this point in time). regards Bernhard _______________________________________________ Swfdec mailing list Swfdec@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/swfdec
