On 4 April 2013 17:11, John Kåre Alsaker <john.kare.alsa...@gmail.com> wrote:
> You should remove the destroy and user_data fields from weston_color_profile.

Fixed.

> weston_cms_create_profile and weston_cms_load_profile should just
> return a pointer to weston_color_profile.

Fixed.

> Plugins should just exit if compositor->cms is already set in module_init.

Fixed.

> The call to colord_update_output_from_device in colord_output_added
> should probably be done in the GLib thread so it won't block the
> compositor.

I spent a few hours late last night looking at what could be run in
different threads, but two things became clear.

* GLib really wants to return all signals (colord_device_changed_cb)
on the main thread, not on the thread that's running the loop.
* Although the two _sync() calls look scary, I acted on a hunch and
added a timer to see how long getting the profile really took: 7ms

I think for the sake of not over-complicating things with *hundreds*
of lines of extra code, for an event that might only happen once or
twice per day or perhaps never at all, blocking the compositor for 7ms
is just fine. Changing the screen calibration isn't something that
happens frequently at all.

I've attached v3 of the patchset, I hope this is okay.

Richard.

Attachment: 0001-Add-initial-color-management-framework-code.patch
Description: Binary data

Attachment: 0002-Add-a-colord-implementation-of-a-CMS-plugin-for-west.patch
Description: Binary data

_______________________________________________
wayland-devel mailing list
wayland-devel@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/wayland-devel

Reply via email to