[Trac #741] Activity startup is slow

[Zarro Boogs per Child]

#741: Activity startup is slow
--------------------+-------------------------------------------------------
 Reporter:  tomeu   |        Owner:  dcbw   
     Type:  defect  |       Status:  new    
 Priority:  high    |    Milestone:  BTest-2
Component:  sugar   |   Resolution:         
 Keywords:          |  
--------------------+-------------------------------------------------------
Comment (by marco):

 Interesting comment in the cairo code:

 {{{

 /* For xlib fallbacks, we use image surfaces with formats that match
  * the visual of the X server. There are a couple of common X server
  * visuals for which we do not have corresponding public
  * cairo_format_t values, since we do not plan on always guaranteeing
  * that cairo will be able to draw to these formats.
  *
  * So, currently pixman does provide support for these formats. It's
  * possible that in the future we will change the implementation to
  * instead convert to a supported format. This would allow us to be
  * able to simplify pixman to handle fewer formats.
  *
  * The RGB16_565 case could probably have been handled this same way,
  * (and in fact we could still change it to do so, and maybe just
  * leave the value in the enum but deprecate it entirely). We can't
  * drop the value since it did appear in cairo 1.2.0 so it might
  * appear in code, (particularly bindings which are thorough about
  * things like that). But we did neglect to update CAIRO_FORMAT_VALID
  * for 1.2 so we know that no functional code is out there relying on
  * being able to create an image surface with a 565 format, (which is
  * good since things like write_to_png are missing support for the 565
  * format.
  *
  * NOTE: The implementation of CAIRO_FORMAT_VALID *must* *not*
  * consider these internal formats as valid. */

 /* For xlib fallbacks, we use image surfaces with formats that match
  * the visual of the X server. There are a couple of common X server
  * visuals for which we do not have corresponding public
  * cairo_format_t values, since we do not plan on always guaranteeing
  * that cairo will be able to draw to these formats.
  *
  * So, currently pixman does provide support for these formats. It's
  * possible that in the future we will change the implementation to
  * instead convert to a supported format. This would allow us to be
  * able to simplify pixman to handle fewer formats.
  *
  * The RGB16_565 case could probably have been handled this same way,
  * (and in fact we could still change it to do so, and maybe just
  * leave the value in the enum but deprecate it entirely). We can't
  * drop the value since it did appear in cairo 1.2.0 so it might
  * appear in code, (particularly bindings which are thorough about
  * things like that). But we did neglect to update CAIRO_FORMAT_VALID
  * for 1.2 so we know that no functional code is out there relying on
  * being able to create an image surface with a 565 format, (which is
  * good since things like write_to_png are missing support for the 565
  * format.
  *
  * NOTE: The implementation of CAIRO_FORMAT_VALID *must* *not*
  * consider these internal formats as valid. */

 }}}

-- 
Ticket URL: <http://dev.laptop.org/ticket/741#comment:8>
One Laptop Per Child <http://laptop.org/>