Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)

2010-08-09 Thread Tomeu Vizoso
On Mon, Aug 9, 2010 at 15:48, Bernie Innocenti  wrote:
> 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/

Simplest may be modifying the shell to repeat in a loop some drawing
(sliding the frame in and out, cycling through the zoom levels, etc)
then using a system-wide profiler such as sysprof to see where time is
being spent.

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)

2010-08-09 Thread Bernie Innocenti
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)

2010-08-07 Thread Bernie Innocenti
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)

2010-08-07 Thread Tomeu Vizoso
On Sat, Aug 7, 2010 at 18:14, Bernie Innocenti  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)

2010-08-07 Thread Bernie Innocenti
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)

2010-08-07 Thread Tomeu Vizoso
On Sat, Aug 7, 2010 at 02:20, Bernie Innocenti  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)

2010-08-06 Thread Bernie Innocenti
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


Re: cairo has now 16bit surfaces (was Fwd: rendering-cleanup)

2010-08-06 Thread S Page
On Tue, Aug 3, 2010 at 7:26 AM, Tomeu Vizoso
 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 
> Date: Tue, Aug 3, 2010 at 15:22
> Subject: Re: rendering-cleanup
> To: Yasushi SHOJI 
> 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


cairo has now 16bit surfaces (was Fwd: rendering-cleanup)

2010-08-03 Thread Tomeu Vizoso
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 
Date: Tue, Aug 3, 2010 at 15:22
Subject: Re: rendering-cleanup
To: Yasushi SHOJI 
Cc: gtk-devel-l...@gnome.org


Yasushi SHOJI  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