Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
El Sat, 07-08-2010 a las 12:14 -0400, Bernie Innocenti escribió: El Sat, 07-08-2010 a las 11:25 +0200, Tomeu Vizoso escribió: I'd expect well-written code to call cairo_surface_create_similar() whenever possible, but there might be hot-spots in our software stack that assume 32bpp. Have given a look to gtk+ and the xlib backend of cairo and seems to me that we are safe. We just need Maltose to come quickly to XO-1 :) ... or backport the new cairo to Fedora 11. The Cairo ABI is supposed to be 100% backwards compatible, and I've successfully rebuilt 1.8 with no issues. Building cairo-1.9.14 and pixman-0.18 went smooth on Fedora 11. They also seem to work fine on the XO. However, I did not notice any visible improvement. In case someone wants to try it out and run some benchmarks, I've uploaded the rpms here: http://people.sugarlabs.org/bernie/olpc/cairo-1.9/ -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
On Sat, Aug 7, 2010 at 02:20, Bernie Innocenti ber...@codewiz.org wrote: El Tue, 03-08-2010 a las 16:26 +0200, Tomeu Vizoso escribió: This means that graphic operations would be considerably faster on the XO-1 because to date we are rendering to 24bit surfaces that the X server has to convert to 16bit every time. Fantastic news! In order to benefit in Sugar, do you think we'd have to wait until 16bit surface support is propagated to GTK, libsrvg, hippocanvas, etc? I'd expect well-written code to call cairo_surface_create_similar() whenever possible, but there might be hot-spots in our software stack that assume 32bpp. Have given a look to gtk+ and the xlib backend of cairo and seems to me that we are safe. We just need Maltose to come quickly to XO-1 :) Regards, Tomeu -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
El Sat, 07-08-2010 a las 11:25 +0200, Tomeu Vizoso escribió: I'd expect well-written code to call cairo_surface_create_similar() whenever possible, but there might be hot-spots in our software stack that assume 32bpp. Have given a look to gtk+ and the xlib backend of cairo and seems to me that we are safe. We just need Maltose to come quickly to XO-1 :) ... or backport the new cairo to Fedora 11. The Cairo ABI is supposed to be 100% backwards compatible, and I've successfully rebuilt 1.8 with no issues. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
On Sat, Aug 7, 2010 at 18:14, Bernie Innocenti ber...@codewiz.org wrote: El Sat, 07-08-2010 a las 11:25 +0200, Tomeu Vizoso escribió: I'd expect well-written code to call cairo_surface_create_similar() whenever possible, but there might be hot-spots in our software stack that assume 32bpp. Have given a look to gtk+ and the xlib backend of cairo and seems to me that we are safe. We just need Maltose to come quickly to XO-1 :) ... or backport the new cairo to Fedora 11. The Cairo ABI is supposed to be 100% backwards compatible, and I've successfully rebuilt 1.8 with no issues. Sounds good, if that gives problems we can consider backporting just that patch. If the small patch below is really what was needed, I'm going to feel quite stupid: http://cgit.freedesktop.org/cairo/commit/?id=022291be1cbddf4f6722f0bf76ebda6922780276 Regards, Tomeu -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
El Sat, 07-08-2010 a las 18:19 +0200, Tomeu Vizoso escribió: Sounds good, if that gives problems we can consider backporting just that patch. If the small patch below is really what was needed, I'm going to feel quite stupid: http://cgit.freedesktop.org/cairo/commit/?id=022291be1cbddf4f6722f0bf76ebda6922780276 Wait, that can't be everything. Where are all the software operations to work on RGB16_565 surfaces and convert them to/from other formats?!? Wait, I think I know: all the hard code is implemented in pixman. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
On Tue, Aug 3, 2010 at 7:26 AM, Tomeu Vizoso tomeu.viz...@collabora.co.uk wrote: This means that graphic operations would be considerably faster on the XO-1 because to date we are rendering to 24bit surfaces that the X server has to convert to 16bit every time. This Cairo change is in 1.9.8 onwards so isn't in the cairo-1.8.8-1.fc11.i586 in XO release 10.1.2. Also, the separate Mozilla bug to allow use of 16-bit surfaces was fixed in June, https://bugzilla.mozilla.org/show_bug.cgi?id=545632 , so XULRunner will sometimes use 16-bit surfaces or can be coerced to do so. I don't think the Mozilla fix is in any released XULRunner package. An unrelated Cairo performance issue is whether the pixel scaling of Browse on XO means that the browser's efforts to pixel-align its drawing with Cairo is defeated. Supposedly you can figure this out using cairo_trace, which is available in cairo-tools for 1.9.6 onwards. Fedora packages for Cairo 1.9.10 are available, but it's a development release leading up to the often-delayed 1.10 stable release. -- Forwarded message -- From: Soeren Sandmann sandm...@daimi.au.dk Date: Tue, Aug 3, 2010 at 15:22 Subject: Re: rendering-cleanup To: Yasushi SHOJI ya...@atmark-techno.com Cc: gtk-devel-l...@gnome.org ... Note that cairo 1.10 (which GTK+ 3.0 will depend on, as I understand), has a client side 565 buffer: CAIRO_FORMAT_RGB16_565. ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
El Tue, 03-08-2010 a las 16:26 +0200, Tomeu Vizoso escribió: This means that graphic operations would be considerably faster on the XO-1 because to date we are rendering to 24bit surfaces that the X server has to convert to 16bit every time. Fantastic news! In order to benefit in Sugar, do you think we'd have to wait until 16bit surface support is propagated to GTK, libsrvg, hippocanvas, etc? I'd expect well-written code to call cairo_surface_create_similar() whenever possible, but there might be hot-spots in our software stack that assume 32bpp. -- // Bernie Innocenti - http://codewiz.org/ \X/ Sugar Labs - http://sugarlabs.org/ ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
cairo has now 16bit surfaces (was Fwd: rendering-cleanup)
This means that graphic operations would be considerably faster on the XO-1 because to date we are rendering to 24bit surfaces that the X server has to convert to 16bit every time. Regards, Tomeu -- Forwarded message -- From: Soeren Sandmann sandm...@daimi.au.dk Date: Tue, Aug 3, 2010 at 15:22 Subject: Re: rendering-cleanup To: Yasushi SHOJI ya...@atmark-techno.com Cc: gtk-devel-l...@gnome.org Yasushi SHOJI ya...@atmark-techno.com writes: I'm for one wandering how to port my application to gtk+ 3.0. My problem is that the current gdk pixbuf nor cairo does not have a client side pixel buffer other than RGB888 or RGBA. Note that cairo 1.10 (which GTK+ 3.0 will depend on, as I understand), has a client side 565 buffer: CAIRO_FORMAT_RGB16_565. Soren ___ gtk-devel-list mailing list gtk-devel-l...@gnome.org http://mail.gnome.org/mailman/listinfo/gtk-devel-list ___ Devel mailing list Devel@lists.laptop.org http://lists.laptop.org/listinfo/devel
